Best Approach for Client-Specific Features?

[undone scarab]

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?

[remote timber]

Post created!

🔎 This post has been indexed in our web forum and will be seen by search engines so other users can find it outside Discord

🕵️ Your user profile is private by default and won't be visible to users outside Discord, if you want to be visible in the web forum you can add the "Public Profile" role in id:customize

✅ You can mark a message as the answer for your post with Right click -> Apps -> Mark Solution
(if you don't see the option, try refreshing Discord with Ctrl + R)

[elfin leaf]

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.

[undone scarab]

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

Its very path based rather than particular features on a component or something like that

[elfin leaf]

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.

[undone scarab]

Yeah i thinking in pushing a turborepo with microfrontends for this, gonna give it a try 🙂 Thanks