How can I better split the code in the _web folder by interface/technology?

Questions / Help
,
1

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)

  • a GraphQL interface, using resolvers and schema (serving a JavaScript SPA)

  • 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).

Any advice is appreciated:)

2

Folders.

It doesn’t really matter where the file is. Create a directory structure under web that makes sense to you, e.g one for marketing, one for admin, one for API.

2 Likes
3

Yup there is a way to namespace your logic:

Excerpt:

By default, the LiveView modules will be namespaced by the web module. You can customize the web module namespace by passing the --web flag with a module name, for example:

mix phx.gen.live Accounts User users --web Sales

Which would generate the LiveViews in lib/app_web/live/sales/user_live/, namespaced AppWeb.Sales.UserLive instead of AppWeb.UserLive.

See: Web Namespace

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?!?:

1 Like
4

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.

1 Like