Best Approach for Client-Specific Features?
Answered
Tommy posted this in #help-forum
TommyOP
Hey everyone! 👋
Looking for some advice here! 🙂
We have a GitHub repo where each client gets their own app running on Cloud Run. However, some clients only need specific features (e.g., /feature-1, /feature-2). What would be the best approach to handle this? Would microfrontends be a good fit, or is there a better way?
Looking for some advice here! 🙂
We have a GitHub repo where each client gets their own app running on Cloud Run. However, some clients only need specific features (e.g., /feature-1, /feature-2). What would be the best approach to handle this? Would microfrontends be a good fit, or is there a better way?
Answered by Roseate Spoonbill
In those cases microfrontends do sound like more fitting solutions (Next calls that Multi-Zone deployment). If the logic inside doesn't have to share too much of code with the main app, or you can use monorepo for main and sub-apps, it should fit well.
5 Replies
Roseate Spoonbill
It depends on the scale of those features and how they influence data sources (e.g. database). The way I prefer to do it is to build all in the main branch, and enable disable via feature flags (instance-level, or account-level). In my previous and current jobs we used to do it with separate branches, but it became update hell long-term.
Apart from feature flags, if this happens a lot, I'd implement some kind of plugin abstraction. This is what happened in my current job - we took time and designed event-based plugin system, which is registered on project level. With that, we can write dedicated plugins with features for our clients, without having to rebuild the app. Only from time to time we extend the events by new one or add some data to existing events.
Personally, I haven't tried microfrontends, but that's mainly because client-specific changes were interconnected with existing features and we'd have to clone existing microparts with the same features only to override small things in the behaviour.
Apart from feature flags, if this happens a lot, I'd implement some kind of plugin abstraction. This is what happened in my current job - we took time and designed event-based plugin system, which is registered on project level. With that, we can write dedicated plugins with features for our clients, without having to rebuild the app. Only from time to time we extend the events by new one or add some data to existing events.
Personally, I haven't tried microfrontends, but that's mainly because client-specific changes were interconnected with existing features and we'd have to clone existing microparts with the same features only to override small things in the behaviour.
TommyOP
The database is external since we are using fastapi backend and we use react-query to access it, a feature for is essentially a route with components that have access to the API, example:
- /knowledge-managment
- components - tables etc
- api
- /knowledge-managment
- components - tables etc
- api
Its very path based rather than particular features on a component or something like that
Roseate Spoonbill
In those cases microfrontends do sound like more fitting solutions (Next calls that Multi-Zone deployment). If the logic inside doesn't have to share too much of code with the main app, or you can use monorepo for main and sub-apps, it should fit well.
Answer
TommyOP
Yeah i thinking in pushing a turborepo with microfrontends for this, gonna give it a try 🙂 Thanks