Content Service should be the source of truth for content
It should depend Localization Module in a way, and the data coming from the DB or the Fluent Wrapper, should be encoded in a way that allows it to be translated from the localization module
Some rough ideas:
Store the content on something like Strapi or Sanity (most scalable)
Store the content statically on POEditor (scalable as well and easier, but 1 is better, yet)
Store the content hardcoded per module (less maintainable)
Store the content in a centralized Localization Module (more maintainable)
Note to self: 1 and 2 seems the same, only diff is POEditor is easier to deal with, and requires no-setup
Note to self: if we go with 2, would we also be able to go with 3, question is, do we need to break down the localization per module? the gains...? don't see any even if it was an enterprise level project
Note to self: I think 2 & 4 are the best way to go
Note to self: if we went with 2, would we be able to scale this into a separate BE?
Note to self: If the BE was concerned only for processing logic (which is what it is built for actually, then yes, it would only send data relevant to business logic, but content is out of the picture by far here, unless in Error Cases, which it may need to send the case, and the translated version from the Header sent to it by the client side
Result
Define POEditor project (already there)
Define Localization Module
Content should be the contactable wrapper for the Features, specifically, the UI part of it
Content may get data it needs from the reducer, but the actual formatting of the UI data should ideally be occurring when creating the ViewState struct (still need to learn more about this)
The gain:
If we were to go with 2, we make sure the content stays in the Client Side, without the need for BE, however, that also puts extra effort if we wanted to reuse the content across different platforms, however, is that a problem? i say no, the Localization Tool here is ideal because it automates the generation of the content, but the clients in any approach still need to attach this to their UI part, which is why the content is used in the UI level, not in Domain level
[ ] Move to Discussions (Under Decision Logs)
[ ] Add a Diagram to backup the Idea from a higher overview
Content Service should be the source of truth for content
It should depend Localization Module in a way, and the data coming from the DB or the Fluent Wrapper, should be encoded in a way that allows it to be translated from the localization module
Some rough ideas:
Result
The gain:
If we were to go with 2, we make sure the content stays in the Client Side, without the need for BE, however, that also puts extra effort if we wanted to reuse the content across different platforms, however, is that a problem? i say no, the Localization Tool here is ideal because it automates the generation of the content, but the clients in any approach still need to attach this to their UI part, which is why the content is used in the UI level, not in Domain level