Proposal: Use a fixed service id when running with mesg-core service dev

[ilgooz]

Problem

Change of service id after each source code change in a service causes us to manually update service id in our application which seems time consuming to me during active development.

Proposal

Use a fixed service id while using mesg-core service test.

Implementation

• We can pass a flag that contains a unique id issued by user e.g.: mesg-core service test --id [a-unique-name]. If the id is not unique, mesg-core should reply with an error.
  or
• We can introduce a field named id in the root of mesg.yml which is configurable by user and also mseg-core service init can automatically generate a uuid and set as the value of id.

If this proposal survives, I'd be glad to make a PR.

[antho1404]

We had a good discussion thinking about your proposal, the idea of an ID in the service file can be really good. The actual ID that we use right now is the hash of the service. We could have a real ID and call the hash simply hash and let the user access its service either with the ID (and will have the latest version of the service) or the hash and will have the exact version.

This update have few consequences:

• we need to add an id to the mesg.yml (optional like that it doesn't break existing services)
• we need to be able to find a service in the database based on its hash and as fallback the ID defined in the service
• Update the API to resolve every ServiceID parameters based on the ID or the hash
• Need to update few commands from the CLI:
  • List should group the services based on the ID (and maybe display the list of "versions")
  • Delete should be able to delete either an ID (with all the hashes) or a specific hash

Right now all services are stored in a key value database in the package database/service with the following structure:
Key: Hash of the service
Value: serialization of the service (doesn't contains the hash)

If we add a resolution for ID we need to add another system with the ID and the list of hashes for this ID:
Key: ID (as defined in the mesg.yml file)
Value: Array of services hashes deployed, the first one is the latest deployment so it's easy to get the latest version and we don't necessary care about the old ones.

---

Some other ideas we were thinking about

Alias file

Have a manifest file that contains a map with the name of the service and its ID

It would be a file in the ~/.mesg folder like a aliases.json or yml with the following format

{
   "service-alias-1": "xxx",
   "service-alias-2": "yyy",
}

And the js lib (or other libs) will directly resolve either the the ID or the alias based on the alias file.

Env variable

Another solution is to export an env variable when a new service is deployed/tested. The con is, when working with different terminal it could be complicated for the user to have to export all the env variables.

---

Do you have any feedbacks on that ?

[NicolasMahe]

This will be a very big PR!
@ilgooz, we can work all together on this one ;)

[ilgooz]

moved to https://forum.mesg.com/t/fixed-service-id-name-service-update-create-feature

[ilgooz]

@antho1404 please confirm and close this issue in favor of forum proposal.