Domain event emitter V2 #134
Conversation
| payload: z.optional(z.object({})).describe('event payload based on type'), | ||
| }) | ||
|
|
||
| export const EXTENDED_MESSAGE_SCHEMA = BASE_MESSAGE_SCHEMA.extend({ |
There was a problem hiding this comment.
this is the most important part to review and criticize
There was a problem hiding this comment.
Shouldn't the specific schema extension be part of apps using the library? I understand we want to use this schema but not sure if having it as part of the library is a good idea.
Also, if we want to add/modify a property we will need to release a new version (which is a potential cause of major releases) or create our extension so having our extension from the beginning could be beneficial.
What do you think?
Btw, no strong opinion from my side, I am also fine keeping it here but just raising the topic in case it can be useful
There was a problem hiding this comment.
Shouldn't the specific schema extension be part of apps using the library?
Yes, definitely. Which is why there is an optional extended schema for those who want a reasonable default (e. g. us), but the library itself doesn't rely on it and supports having your own.
If we ever decide to change it, I would expect we would be adding it as a separate schema, e. g. EXTENDED_MESSAGE_SCHEMA_V2, so that those who are happy with the original one, can keep using it.
There was a problem hiding this comment.
Yeah, the point was that I am not sure if the library should just define the minimum it needs to work and be open to extensions (it is already) without providing things the users can define based on their use cases, and are potential points of change. Also, to avoid having EXTENDED_MESSAGE_SCHEMA_V{{N}} schemas for backward compatibility.
I think in our case, I would suggest going with creating our own extension (could be MY_SCHEMA = EXTENDED_MESSAGE_SCHEMA) to have flexibility and not have to modify the library to just modify the schema
But as I mentioned, I am not sure if this concern is valid or if it is stupid, so if you think it is fine, I am also fine and please feel free to resolve this thread if it is the case
There was a problem hiding this comment.
I think in our case, I would suggest going with creating our own extension (could be MY_SCHEMA = EXTENDED_MESSAGE_SCHEMA) to have flexibility and not have to modify the library to just modify the schema (same problem we have with WS rooms, where to add a room we need a new library version)
Very fair point. But also for standartization sake I would like to have one single place where our common schema is defined, so that each service doesn't have to do it over and over again. It doesn't have to be this library, though, we could put it e. g. in shared-ts-libs as a part of events-common.
I would still provide EXTENDED_MESSAGE_SCHEMA as an opinionated starting point for people/teams who might benefit from it, but won't couple to it anywhere in message-queue-toolkit itself.
I agree that when we need to adjust our schema, we should be able to do it outside of message-queue-toolkit.
No description provided.