Ladder99/ladder99

Re-design `ladder99`

Opened this issue · 1 comments

tukusejssirs commented

Note: This issue is a meta-issue. In future, we will move some tasks to sub-issues to deal with individual tasks in detail. Over the time, the meta-issue will contain all tasks (steps) that need to be done in order to accomplish the re-design. Some parts (tasks) of this issue could be removed from it or moved to the backlog.

All decisions and new informations should be added to this issue (either the description should be updated or a new comment created).

Proposed design

TODO: Add the v2 diagram.

Ideas and potential tasks

  • We want to use Benthos in middleware parts of the app that does not contain user-facing config.

    • @MRIIOT will pursue this path and see how it could be used.

  • We’ll use Nest for all needed apps/libs (API gateway, microservices, libraries, CLI app, …) except for those that will use Benthos?

    • I could help with this. Of course, the actual design of Nest apps/libs depends on how we want the app to work.

  • We need to decide what part(s) of l99 we want to put into microservices.

    • In order to make the microservices scalable, it must not depend on the order the data is being processed, because the data could be processed by any microservice instance. That is the reason we need a central cache storage (e.g. Redis) where we can simply update the data used at runtime.
    • A microservice creation and maintenance comes at a cost, thus we should create only as many microservices as we actually need.
    • If we need to use a microservice, we need to decide what transport (TCP, MQTT, …) to use to communicate with them.
    • Each microservice needs at least the following functions to be run via the microservice API:
      • start(): start monitoring of machine(s) provided as a parameter OR whatever the microservice should do on its own;
      • stop(): stop monitoring of machine(s) provided as a parameter OR whatever the microservice should do on its own;
      • exit(): cleanly exit the microservice;
      • init(): [optional] if we need to initialise a microservice before starting what it needs to do on its own;
    • It would be awesome if we could start the microservice itself (if it isn’t running), however, for now I see only option: use docker start.
    • We could use a microservice per monitoring feature/scope, like:
      • machine power-on/reachability monitoring:
        • ping the IP address(es) that are associated with a particular machine, including IP addresses of the machine, PLCs, Sharcs and other sensors used by the particular machine;
      • FOCAS/MTConnect/etc data (a microservice per input data type):
      • good/bad/failed parts count;
      • any other data to monitor.

  • We also need to define what (gateway) API calls we need to create.

    • Here is a REST API proposal, although we could use GraphQL instead, for which the REST API could be quite simply adapted [some data might not be (yet) available in l99, thus it needs to be modified a bit]:

      API proposal

      • /api (global l99 prefix):

        • /app (DB schema: TODO):
          • PUT /exit: cleanly exit all microservices and the gateway;
          • GET /version: get l99 version;
          • GET /uptime: [optional] get app (gateway) uptime;
          • ??? /test: ??? Swagger;
          • GET /backup: backup l99 config and optionally CS data;
          • POST /restore: restore l99 config and optionally CS data;
        • /server (optional; server administration/configuration):
          • PUT /power-off: power the server off (execute PUT /api/app/exit first);
          • PUT /reboot: reboot the server (execute PUT /api/app/exit first);
          • GET /uptime: get server uptime;
          • GET /restart-log: get server restart log;
        • /user (DB schema: user; user administration routes):
          • GET: get one/many/all user(s);
          • POST: create one/many user(s);
          • PATCH: update one user;
          • DELETE: delete one/many user(s) (actually, just ‘archive’/disable the user);
          • /:user:
            • GET: get a user;
            • POST: create a user;
            • PATCH: update a user;
            • DELETE: delete a user (actually, just ‘archive’/disable the user);
          • /current:
            • GET: get currently signed in user;
            • PATCH: update currently signed in user;
        • GET /power-on/test test if an IP address or a domain is reachable (consider finding a better route path);
        • /machine (DB schema: m${machine}; machine administration and data retrieval routes):
          • GET: get one/many/all machine(s);
          • POST: create one/many machine(s);
          • PATCH: update one machine;
          • DELETE: delete one/many machine (actually, consider just ‘archiving’/disabling the machine);
          • /:machine:
            • GET: get a machine;
            • POST: create a machine;
            • PATCH: update a machine;
            • DELETE: delete a machine (actually, consider just ‘archiving’/disabling the machine);
            • /monitoring:
              • PUT /start: start machine monitoring (all enabled features that are are not yet started);
              • PUT /stop: stop machine monitoring (all features that are are not yet stopped);
            • /maintenance (machine maintenance data):
              • PUT /init: initialise the feature for a machine;
              • GET: get (historical) data of the feature for a machine;
              • POST: create some new data of the feature for a machine;
            • /power-on [machine (and its sensors) power-on monitoring data]:
              • PUT /init: initialise the feature for a machine;
              • PUT /start: start monitoring of the feature for a machine;
              • PUT /stop: stop monitoring of the feature for a machine;
              • GET: get (historical) data of the feature for a machine;
            • /state:
              • PUT /init: initialise the feature for a machine;
              • PUT /start: start monitoring of the feature for a machine;
              • PUT /stop: stop monitoring of the feature for a machine;
              • GET: get (historical) data of the feature for a machine;
            • /production:
              • PUT /init: initialise the feature for a machine;
              • PUT /start: start monitoring of the feature for a machine;
              • PUT /stop: stop monitoring of the feature for a machine;
              • GET: get (historical) data of the feature for a machine:
            • /alarm:
              • PUT /init: initialise the feature for a machine;
              • PUT /start: start monitoring of the feature for a machine;
              • PUT /stop: stop monitoring of the feature for a machine;
              • GET: get (historical) data of the feature for a machine.

  • We need to exactly define what config is user-facing and what is not.

  • Most of the configuration should have (reasonable) defaults, thus it could be omited/skipped by user during configuration.

  • The user should be to define global machine config that would be inherited by the machine.

  • The user should be able to override the global config per machine.

  • Do you have any other tasks that need to be done in order to change the design? You can update the issue by yourself after I create it.

  • We should add user authentication, authorisation and session management.

    • Tasks

    TODO

    bburns commented

    See also #190