open-index/open-npm huggingface dataset:
npm package: @ords/core
Description: Microservice architecture with service proposals in nodejs and typescript
Author: Rune k. Rasmussen
Latest version: 0.16.3

This project builds a modular microservice architecture in typescript.

UNDER DEVELOPMENT! - Needs a repository with an example implementation, some of the links are not working yet!

# Gitter Channel
[Chat in Gitter](https://gitter.im/GallVp/chiroit-backend?utm_source=share-link&utm_medium=link&utm_campaign=share-link)

# Architecture
Illustrated in the figure below is a database (module) microservice who registers at the server *ServiceRegistry*. A *connector* module recives and requests and sends back responses to a client where a *map* maps the request to a specfic microservice such as the *database* microservice. Eventually *resolvers* is gonna be added to the *ServiceRegistry* so that microservices can be resolved with other than local methods etc webhooks.

![drawioArchitecture](https://github.com/ords/ords-core/blob/master/assets/architecture.png)

# Using this module
This module exists on npm. To use it run:

```
npm install @ords/core --save
```

The module includes *ShortenAct* the purpose of this is to simplify calls made to the *ServiceRegistry*.

# Global dependencies
- nodejs
- typescript
- typings
- mocha

# Getting started
Initially install dependencies by running:
```
npm run build-env
```
Whenever you have made changes you can run the following command
```
npm run build-depoly
```
## Scripts
In order to test the project you can now run:
```
npm test
```
To clean the project do:
```
npm run clean
```

# Contribution
Contributions can be made to either modules (microservices), maps or this repo. Module and maps contribution is managed in [http://github.com/medsolve/ords-modules](http://github.com/medsolve/ords-modules) and [http://github.com/medsolve/ords-maps](http://github.com/medsolve/ords-maps) resspectivly.

Core modules implements proposals from the *proposals* directory. Essentially all kinds of modules can be delivered but modules following the *proposals* will be entirely interopable. Below are general rules for code contribution:

- Use camleCase instead of underscore for namespace, variables and functions
- constants CAPITALIZED
- Interfaces, Abstract, Classes, Types all with conventional naming starting with a capital letter
- Document your code with comments
- Write at least unit tests
- Follow established directory structure

Variables or anything named with a *_* prefix is usually instanciated automaticly somewhere in the core a module and should therefore not be manipulated. An example is the _meta property that is attacted to the *Request* as a microservices is carried out.

# Versioning
We use schemantic versioning. We do no introduce backwards compatible breakable code without upgrading the software version to a major release.

# Todo
* More documentation
* Better tests
* Update website for project
* Example implemetation
npm package: @ords/maps
Description: Maps for ords-core microservices
Author: Rune k. Rasmussen
Latest version: 0.9.4

This project contains core maps for [ords-core](https://github.com/MedSolve/ords-core)

# Gitter Channel
[Chat in Gitter](https://gitter.im/GallVp/chiroit-backend?utm_source=share-link&utm_medium=link&utm_campaign=share-link)

# Using this module
This module exists on npm. To use it run:

```
npm install @ords/modules --save
```

# Global dependencies
- nodejs
- typescript
- typings
- mocha

# Getting started
Initially install dependencies by running:
```
npm run build-env
```
Whenever you have made changes you can run the following command
```
npm run build-depoly
```
## Scripts
In order to test the project you can now run:
```
npm test
```
To clean the project do:
```
npm run clean
```

# Contribution
Below are some general rules of code:

- Use camleCase instead of underscore
- Document your code with comments
- Write at least unit tests
- Follow established directory structure

All maps from microservices to connector should be named acording to what connector they belong to. Please see the names of already implemented maps and follow that naming.

# Versioning
We use schemantic versioning. Do no introduce backwards compatible breakable code without upgrading the software version to a major release.
npm package: @ords/modules
Description: Modules for ords-core microservices based upon proposals
Author: Rune k. Rasmussen
Latest version: 0.16.9

This project contains core modules for [ords-core](https://github.com/MedSolve/ords-core)

# Gitter Channel
[Chat in Gitter](https://gitter.im/GallVp/chiroit-backend?utm_source=share-link&utm_medium=link&utm_campaign=share-link)

# Using this module
This module exists on npm. To use it run:

```
npm install @ords/modules --save
typings install npm:@ords/modules --save
```

# Contents of the module
This contains mutliple modules for each proposal set by ORDS, this also include example maps!

# Global dependencies
- nodejs
- typescript
- typings
- mocha

# Getting started
Initially install dependencies by running:
```
npm run build-env
```
Whenever you have made changes you can run the following command
```
npm run build-depoly
```
## Scripts
In order to test the project you can now run:
```
npm test
```
To clean the project do:
```
npm run clean
```

# Contribution
Modules can be created seperatly from this core project. These core modules in thie repo implements proposals from the *proposals* directory in [ords-core](https://github.com/MedSolve/ords-core). Essentially all kinds of modules can be created, but modules following the *proposals* will be more interopable. Below are some general rules of code:

- Use camleCase instead of underscore
- Document your code with comments
- Write at least unit tests
- Follow established directory structure

Ideas for naming to and directory structure to keep consistensy *modules/:type/:type.:custom.ts* where type is the type of module and custom can be everything. A mongodb db will be *modules/database/database.mongo.ts* with the class name being *DatabaseMongo*.

# Versioning
We use schemantic versioning. Do no introduce backwards compatible breakable code without upgrading the software version to a major release.
npm package: @ords/obj-schema
Description: Perform schema validation in typescript
Author: Rune k. Rasmussen
Latest version: 1.2.3

This project lets you create schemas for your objects and validate a given dataset against that schema

# Using this module
This module exists on npm. To use it run:

```
npm install @ords/obj-schema --save
```

The different erros can be found in:

```typescript
import {errors}            from    '@ords/obj-schema';
```

Check our tests for expected behavior of this module.

# Examples

```typescript
import {setType, lib}            from    '@ords/obj-schema';

// boolean type
let bool: lib.SingleElementDefinition {
    valueset: { true: true, false: false }, // values allowed
    numValues: 1,                           // required number of values
    maxNumValues: 1                         // maximum number of values
}

// custom type
let myCustom: lib.SingleElementDefinition {
    numValues: 2,                          // required minium one
    maxNumValues: 3                        // maximum length leave empty of unlimited
    customValidator: (data: any) => {
        
            // this validator just lets everything pass
            return data;
        }
}

let CustomGoat = {
    cool: setType(bool)
    coolAndFunny: setType(myCustom)
}

// works with true or 'true' output = true
let schema = setType(bool);
schema.validate('true')

// works with true or 'true' output = ['true', 'true']
let schema = setType(myCustom);
schema.validate(['true', 'true'])

// disables strictmode and thereby required minima is ignored
let schema = setType(bool);
schema.validate(['true'],false)

// this works
let schema = setType(CustomGoat);
schema.validate({coolAndFunny: ['true', 'true'], cool: ['true']})

// this doesnt work
let schema = setType(CustomGoat);
schema.validate({keyDoNotExist: ['true', 'true'], cool: ['true']})

```


# Global dependencies
- nodejs
- typescript
- typings
- mocha

# Getting started
Initially install dependencies by running:
```
npm run build-env
```
Whenever you have made changes you can run the following command
```
npm run build-depoly
```
## Scripts
In order to test the project you can now run:
```
npm test
```
To clean the project do:
```
npm run clean
```

# Contribution
Modules can be created seperatly from this core project. These core modules in thie repo implements proposals from the *proposals* directory in [ords-core](https://github.com/MedSolve/ords-core). Essentially all kinds of modules can be created, but modules following the *proposals* will be more interopable. Below are some general rules of code:

- Use camleCase instead of underscore
- Document your code with comments
- Write at least unit tests
- Follow established directory structure

Ideas for naming to and directory structure to keep consistensy *modules/:type/:type.:custom.ts* where type is the type of module and custom can be everything. A mongodb db will be *modules/database/database.mongo.ts* with the class name being *DatabaseMongo*.

# Versioning
We use schemantic versioning. Do no introduce backwards compatible breakable code without upgrading the software version to a major release.