I’m in the process of implementing a white-label application with the help of this guide (I’ve diverge somewhat with respect to handling of subdomain routing).
I want to implement some sort of nesting for contexts to separate the business logic in the same way that multi-tenancy isolates the data.
I’d appreciate some tips here. I plant to implement the business logic isolation after the multi-tenancy is implemented.
I have already implemented a router per-subdomain approach for routing, so each subdomain is going to have custom layouts, core-components, controllers, views, and components.
What rules am I breaking so far (with respect to best practices)?
How important are those rules for security, performance and extensibility?
How can I address potential security concerns?
What surprises may I encounter when nesting the contexts so as to organise and isolate distinguish business logic?
I’ve seen the mix phx.new apps/<app_name> approach here.
Does the approach I’m using offer limitations and obstacles overcome by the above approach? (btw I’m not requesting that one read the entire guide linked above, however, I would appreciate perusal of the section that shows use of mix phx.new within an existing project)
If you are implementing all of these things (and contexts) separately for each domain, can you explain which things are shared? My impression of “white-labeling” was that everything would be about the same, save for some (relatively) trivial branding changes.
Yes I understand this, and that’s part of what actually prompted me to ask this question.
While I’m referring to this as whitelabel, in a strict sense the only thing that is shared is the db, and the domain.
I’ve been thinking about how I might be able to have a fully whitelabeled service initially while still retaining the option to further customise to meet future needs.
On another note things like authorisation may not be necessary for some sites, so I’d also like to be able to turn some basic features off completely for some without needing to implement a custom distinct one for all the others.
I’m still not sure I fully understand what’s being shared. Are you sharing the database itself (i.e. one Postgres server), the data model (i.e. Ecto schemas/migrations), or the data in the database (the actual rows)?
If you apps are actually totally distinct from each other save for a few shared parts, consider creating separate apps and using a shared library for those parts. You could keep them in a monorepo or in separate repos.
Same for authorization: are you sharing the auth, or is it separate for each service?
For example, I plan to host multiple (completely distinct) apps, so I built a central “accounts” app and rolled my own OAuth server/client to authenticate between them. But in my case I know that I want future apps to be totally distinct down the road. I keep shared functionality (like the oauth client) in a separate library, which is shared amongst apps (as a Mix dep). I also keep shared (Phoenix) components in a separate library.
The severity of distinction depends of the extent of customisation.
I’m aiming for the support of basic to extensive customisation.
Even the authorisation would range from off, to basic, to extensive. The phoenix auth backbone would always be there for all levels save off, it’s just that oauth may also be added for more extensive customisations.
So it sounds like you have a “standard app”, but you want the ability to heavily customize the behavior?
I would probably either:
Keep a “standard implementation” and then fork off branches for each client, maintaining a set of patches for that specific client.
or
Maintain one version of the application, and add “customizable” functionality behind feature flags/configuration.
Either way this is of course not an easy job. If you want more advice from others you may want to provide more details about the app, as it’s hard for us to judge exactly what you’re doing and it could make a difference.
The app is for me, the developer, a productivity streamline for quickly deploying subdomianed websites on a main host.
For a given client what the app is will be more broad.
My question pertained to whether I would experience severe limitations using in the app and app_web directories to facilitate isolation of business logic and extensibility and security, vs the approach used in one of the guides cited, where app generation per client was done within the main project.
