Say I have the following interfaces/sections in my app:
presentation/marketing pages with the registration form, using simple Phoenix templates and controllers for those pages and the registration (no LiveView)
an admin backend using LiveView
All those different sections of my application use the same business logic/domain (which would be the foo folder alongside the foo_web folder).
At some point I just thought to create separate apps or dependencies, depending on the common business logic/domain code, but I’m not sure whether it’s a good idea. (I still think that having the marketing website separate in the future might be a good idea in order to separate the traffic of the registered users using the app with the traffic of the public website’s guests and bots by different deployment, but I probably think too prematurely).
As those sections of the website are separate and using different technologies, and in order to not have all this code mixed up together and clearly see which code belongs to which section of the app, is there any code organization technique I could use to group code together by section?
(I still think there might be some code shared such as the Endpoint and other connection configuration, not sure yet).
P.S. This kinds of separation is why I asked the following question in the forum, to avoid writing presentation and marketing pages in old school way, can’t we just mark a LiveView as InertView or dead view?!?:
I’ve found that an umbrella project works really well for this kind of setup. You’d end up with four directories in apps:
a domain (please think of a better name) that has Ecto etc machinery in it and starts a Repo
a marketing_web that has an Endpoint attached to (say) port 4000 and has a simple Router
an api_web that has an Endpoint attached to port 4100 and talks GraphQL
an admin_web that has an Endpoint attached to port 4200 and talks LiveView
The upside of this approach is that each individual *_web is simpler and can skip bits it doesn’t care about - for instance, api_web doesn’t need to start esbuild etc because it doesn’t have assets.
The downside is that network routing gets trickier since there are now three Endpoints on different ports. You can use something like main_proxy to do this inside of your application, or use an external load-balancer that takes care of the details. The last time I set one of these up, we had Nginx routing different subdomains to different ports so that admin.example.com went to admin_web while api.example.com went to api_web.