I tried to follow this blog to build a multi-tenant Phoenix application, but failed at the 2d part, - controllers and views are structured in a different way in Phoenix > 1.7 (the blog used the 1.6 version).
I also took a look at another approach using the existing library (Triplex) but a bit hesitating as its last release is dated of May 2019.
So the questions I have are as follows:
are there any other alternatives to the existing libraries?
is it possible to adapt the solution used in the above blog to the latest Phoenix file structure?
Sorry this is not directly Phoenix as you asked, but assuming you’re also using Ecto it might be interesting to mention these guides about multi-tenancy enforced at the DB layer:
@sabiwara Yep, definitely, it would be wiser to mention it as well. In this case, it will be an additional question about how to structure and organize controllers, templates, etc. in a multi-tenant Phoenix application using Ecto.
Triplex is just a thin wrapper around Ecto’s migration utilities. We use and continue to use it in production successfully. There’s not a lot of releases because there’s just…not that much for it to do. The heavy lifting is all done in Ecto. Triplex just subs in schema prefixes
I built and am currently maintaining a multi-tenant application using postgres schemas and I am not sure I understand this question. I didn’t see a reason to modify any part of the standard Phoenix code organization conventions. I didn’t even bother with Triplex because running migrations in each tenant is pretty trivial. Basically the multi tenant specific part of the application is just a Plug that sets the tenant on the request from the subdomain, and a utility for feeding that into Ecto queries.
Just took a very cursory look but it seems that choice is due to the “white label” aspect of the service, so there is a “general view” and a “tenant view” that they wanted to separate. In my app there is no “general view” but there is an admin context that only staff has access to, within each tenant, so there is a similar, but not identical, divide in the contexts.
But again, that is not really specific to multi tenant applications. Whatever features your app offers are likely to impact how exactly you divide up contexts. If my app had no such admin view it would not have any divide at all related to the tenants (but I would expect generally there would be some similar requirement, at least to manage the currently active tenants).
Thanks a lot for your time. In my case, the idea would be to offer a kind of SaaS application and provide separate subdomains for every client (like in the 1st example) or like Heroku does when you create a new application on their platform. I mean that the application should be exactly the same except for the access URL for every client: like
This doesn’t sound right to me. Since all clients are enrolled in the same service they will be using the same app, you wouldn’t want to hard code the tenant names into the contexts to separate at the tenant level (if I am right that is what you are implying, apologies if I misunderstand). The “tenant” is really just a bit of metadata about the user that is currently logged in.
In my app there are some differences between what features different tenants have access to, but that is handled with a feature flag that is persisted in the tenant record (along with billing info, name, etc). If the differences in what the tenants actually see are too complex to handle with feature flags, I would argue that you have more than one application.
