Design pattern for multiple companies in AngularJS

Question

We are on the verge of launching v3 of our in-house product. v2 was written completely in AngularJS and V3 will be the same, but written completely in Typescript.

We have a few customers that have very specific needs for the product and each have their own version (hosted on our own platform), and have their own deployment. There are common shared parts which is the same for everybody.

At the moment everything is in 1 solution (Visual Studio) which we prefer due to ease of maintaining it, but it made a big mess of mixing of settings, company specific options etc. There are a lot of if-else statements in the controllers, directives and even views (still, all angularJS) to accompany for multiple companies.

Now in V3 we are rethinking this setup and want to become more flexible, every company will have its own controllers, directives and views, with the option of some parts being shared and using a service/data layer to handle common shared tasks.

Now I am thinking how can I make this manageable? At the moment we have 6 customers but this is expected to grow with 10-15 each year. I am afraid we will again end up with a big pile of files scattered through the project which makes it hard to maintain and test.

I want to avoid this and keep the project flexible and manageable.

Should I figure out a way to split every company in separate solutions with the common Javascript/Typescript files for app startup and routing in a common project? Maybe just have a single folder for every company with custom controllers, directives and views, but how would the routing be handled?

How do we approach managing enterprise apps with multiple companies?

PS. Our web application is angular because almost everything is client side, it has the ability to work 100% offline for longer periods of time, the backend side is not important for this problem.

Answer 1

If you realy, realy, realy need so many client-specific features, which I do not recommend at all, you should make your application highly modular. Every time a client-specific change is needed just create a new module instead of adding an if-else mess to existing modules. Make these modules as small as possible and use interfaces and patterns like dependency injection to try and keep this organized. Load the client version of a module where possible or fall back to the default.

NewsModule/NewsModule.js
NewsModule/ArticleHeader/ArticleHeader.js
NewsModule/ArticleHeader/ArticleHeader.ClientA.js
NewsModule/ArticleHeader/ArticleHeader.ClientC.js

An alternative method could be (and this is just a though, I'm not sure if it could work, and might anger the gods) to create a branch for each client. Always push from master (or dev, or whatever) to client, and never the other way around.

        / ClientA
master -- ClientB
        \ ClientC

Please keep in mind that, whatever solution you choose, this will never be easy to maintain. Bugfixes will be a pain. Continuous delivery will be a pain. Testing will be a pain. Etc.

Answer 2

In addition to the advice above, you might want to consider refactoring the parts of the application that are operating conditionally based on client to a higher level of abstraction.

Since you're using Typescript, simple polymorphism can help you abstract away the work to just an interface. Then you can let the client specific concrete implementations implement what work actually gets done.

https://en.wikipedia.org/wiki/Strategy_pattern

Answer 3

Perhaps it may make sense to factor everything into services first and then break down each of the company specific things into its own application. If memory serves me you can have multiple angular applications on a single page so it should be possible to set things up to route each of your clients to the right place.

I assume that you could then setup your grunt or gulp file with a kind of master task to handle building and running the tests for each project.