Ask HN: Forking our app a lot, and it sucks. Is this new approach any good? | Hacker News Reader

Ask HN: Forking our app a lot, and it sucks. Is this new approach any good?

2 pointsabhishekchalla4 comments

We built an app, and fork it each time we have a new client to make a new deployment. Each deployment is slightly different as clients want customizations. This slows us down, adds maintenance cost and we want all deps to run from same codebase.

To achieve this we are building a plugin system - All functionality of our system is divided into various (interdependent) plugins - Each plugin contains a set of actions (functions invoked by a service with an actor in context) along with some helper resources like input validators, access control validators etc. - These plugins are defined as a JSON schema (with proper input and return types for all functions) which is used to derive types and boilerplate code for the devs to continue writing the business logic in.

Through this system, SDKs in different languages will be built that can then be used by our applications

Our problem is that we have never seen this implemented before. Do you have any ideas, notes, on our approach. Or links on how other people solved this problem?

At a previous company, we had a feature flag/config system where each client (tenant / org / account) had a JSON blob associated with it. The JSON turned on various features and provided any feature-specific configuration data. Some features were pretty simple and were literally just a bool. Others required a dozen lines of JSON. Clients never saw this stuff. It was done by the engineers during onboarding. It was a pretty complex B2B SaaS product and "onboarding" could take several days of back-and-forth with the client. It was also not a true plugin system, more of a monolith. The entire code base was shared across all the tenants.

Either path seems like a maintenance nightmare. Are the client requested customizations primarily chrome/look & feel or functional changes to the product? Are these customizations features that could or should be merged back into the mainline product? If the underlying app or plugins change who pays for validating the changed code in re-deployments and fixing any problems caused by the updated code?

Look at techniques such as Dependency Injection, and Feature Flags. Each deployment should only be a different configuration of Feature Flags. Otherwise, you're overcomplicating things.

Agree. The problem with forking or having separate long running branches for each customer is that you end up maintaining n slightly different mutations of the same system. X got a fix for a recurring issue, the fix has been copypasted or cherry-picked to Y. Y got a different feature . Z didn't get the previous patch because this customer does not really use the given feature. Another developer finds a new, common problem and now, he must create 3 different fixes in 3, slightly different systems.

Managing feature flags are not always easy, but creates significantly less maintenance overhead than managing multiple mostly similar, but different codebases.

Reply on news.ycombinator.com