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.

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.
• Doesn't docker already offer the ability to categorize services using labels?
  • Still might need someway to query this, but....
• 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'
• 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.
• 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?