Home

This is the documentation about Flux2-server project which is the server side of our internal communication system used for the Gala UTT.

Flux2-server is a restful API that let client access and manipulate data. All endpoints can be used with both http or websocket, however with the websocket API, you can subscribe to creation/modifications/deletion on a model and live update the client according to database update.

Documentations

There is two documentations available for this project

• User documentation: Use the API from a client
• Dev documentation: Code on this project

History of this version

This documentation is about the next branch of Flux2-server. This version has been created after the first use of Flux2 (Gala 2017) to do big changes and cleaning without worrying of breaking the (nearly) stable version.

• Removing sails.js and waterline: Sails.js was really nice to save time in the beggining of the project because it does a lot of things for us. Saddly the future of sails.js is not safe, it's already old in the world of js: No es6 classes, no promises, no arrow function. We can still uses thoses features in our code, but it create a code where some part work with callback and other with promises which ugly. Same about waterline (ORM of sails.js) but we also had some tricky situations: We didn't manage to do a (OR) AND (OR) condition because it create a condition object like this {or:, or:}, but the secound or erase the first.

• Moving from mongo to sql: We were just using mongo as a classic sql db, all collection were strictly defined by models and we prefear it this way because it seems more stable and expected. Moving to SQL mean we can more easily use relations features like cascading delete in relations. Furthermore, future administrator of this project may less know about mongo than us, and mysql is way more easy to inspect and fix because most of people already played with a phpmyadmin, but not with mongo-express and mongo syntax. We choosed to use Sequelize as SQL ORM.

• Final big modification was the factorisation of a lot of code to ModelController and BaseModel. We can do that now, because we already made most of the expected features on the API, so we know better how to merge code and avoid redoundancy errors. It was really hard in the precedent version to keep the permission code up to date between all spaces (controller actions and webscoket events).