This page serves as a documentation on what the service registry does and how it works.

Design

Purpose

1. Provide authentication keys for microservices (as opposed to user-based authentication keys)
   1. This allows microservices to communicate between each other without the approval of a user (action). This is useful (needed) for things such as cron tasks.
2. Categorize microservices together
   1. Provides ways to register and query as such a category
      1. This allows things such as front-ends to know which services are available and only show those in the user interface. TODO discuss this
      2. In the case of the application microservice, this allows for several microservice of the category "application" to be grouped together and used interchangeably for the same thing within oms-events
      3. In the case of the notification pipeline, we will also have several microservices of the category "notification" which either send notifications via mail or push or smoke signals or whatever
3. Query for frontend modules/pages
   1. Each microservice can register modules/pages/whatever-we-call-them to be displayed additionally in the menu bar and also be loaded upon frontend load. The registry gathers these by a registered getModules.json (the path to this file is set with a label, see "Use"
   2. Currently it uses a hack to register these pages to the core
   3. In the future it might take over the modules functionality from the core, doing effectively the same thing TODO discuss this

Use

You can add different labels on a container that the registry will read and that can be queried through the api

{success: 1, data: <extra information>}

Code

API

Questions

I (Derk Snijders) read Micro service - communication, went through the code and looked at the API, yet still had some questions. Answering these should provide solid documentation as to how to use the registry.

• Why seperate authentication for microservices and users?
  • I would propose splitting Users and Members. This way you can have Members being a User, but also services being a User and do all authentication for Users the same.
  • Answer Nico: I love that idea, this would solve it in a more elegant fashion!
• Doesn't docker already offer the ability to categorize services using labels?
  • Still might need someway to query this, but...
    
  • Answer Nico: Still needs some way to query it. Effectively the registry does query docker for it and then provides a nicer interface. But we could also rationalize it away and maybe provide a code snippet which queries docker and parses the response but somehow having a small service for it feels nicer.
• Doesn't traefik already gives you the ability to query services using categories?
  • Isn't this feature taken directly from the traefik website what we need? '* Round Robin, rebalancer load-balancers'
  • Answer Nico: The loadbalancing only happens for instances of the same service, traefik has no notion of category in our sense where different services provide somewhat same functionalities. 
• What are categories?
  • Are multiple instances of the same service (image) a category? Or are multiple services that do approximately the same, but not exactly, a category?
    • I believe Traefik (or even docker?) can handle the first case, I do not see the use case / priority of the second case.
      
    • Answer Nico: The second case, for examples see Purpose -> 2.a.ii. and 2.a.iii. above
• Isn't it solely up to the frontend to decide which pages to show? (since we dropped the concept of modules)
  • Meaning integration with the service registry for backend-only services would solely be for authentication?
  • Answer Nico: We should rediscuss this, I had some insights when splitting off the frontend.