Use semantic-release and commitizen to standardise pushes to the repo

mysql2 was launched and brings a boost in performance in interacting with mysql databases over mysql-node package.
See mysql2

Move the app to docker infrastructure.

We should refactor some file names, for example we don't need all files inside commons/utils to have the Util appended to their name, it can clearly be seen from the import that it's a util class.
The same goes for fileOperations, handlers and preprocessors.

add at least support for test and prod envs.

What database should we support?

To keep in line with the current node js versions, move the generated API code from Promises to Async / Await.

add boilerplate's for express server, config, controllers and services

When given a complete schema and an array of required entities, generaptr should be able to filter out unneeded models and related columns form schema.

References issue #5 in generaptr-cli

Maybe we can use something like faker.js to generate some dummy responses.

Document the purpose of the repository.

In the scope of this issue, we need to research how and if possible to read the "schema" of database based on the datasets in each collection. For example what we do for MySql right now, after some parsing looks somewhere on the lines of this.

• MongoDb
• RethinkDb
• CouchDb

generaptr should be able to read a valid raml and extract the api schema

Progress in #27-test-everything

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml
• The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

When the foreign key column name differs from the referenced table, generaptr detects the datatype wrong.

Examples:
user_id foreign key to users table results in a User datatype which is right
created_by foreign key to users table results in a Created_by datatype which is wrong, it should've been User

Progress:

• replicated issue
• solved mysql parsing schema
• solved raml parsing schema
• solved generating api which take in account alias names
• fix lint issues and tests

I think we should probably separate the logic in generaptr in a separate package, and the cli which will use the core generaptr in another, this way we will have a bit more separation, and would make the testing a lot easier.

@StefanBalea What do you think?

Research reading schema for other sql databases.

• Sqlite3
• Postgresql

Add some kind of static type checking on generaptr codebase either by moving to typescript or adding flow.

Research:

• Flow.js
• Typescript

We should support enum and datatypes especially if we want to support no-sql databases.

Mysql supports enum which look something like this
size ENUM('x-small', 'small', 'medium', 'large', 'x-large')
A list of previously defined items from which the field can have one as value.

https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md

Add infrastructure to test the api.

Since #40 we moved to typescript and in the rush of finishing that we added types for the commonly used data structures in the project such as DataType, Column, Table, Schema etc... I was wondering if we shouldn't move to a more OOP approach and declare those as models and in doing so we can move some of the logic from utils classes to the models itself.

I think it would simplify the overhead a bit when working with the handlers and processors and with the actual generation of the code.

Generate sequelize models and repositories based on the schema

As seen on Sequelize Docs, Sequelize supports PostgreSQL, MySQL, SQLite and MSSQL which would already cover a good part of the relational databases.

based on the data types and the examples created in #8 and #16 generate the actual api spec.