thojanssens1
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:)
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #elixirconf-us
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
cmo
Folders.
It doesn’t really matter where the file is. Create a directory structure under
webthat makes sense to you, e.g one for marketing, one for admin, one for API.derpycoder
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
--webflag with a module name, for example:Which would generate the LiveViews in
lib/app_web/live/sales/user_live/, namespacedAppWeb.Sales.UserLiveinstead ofAppWeb.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?!?:
al2o3cr
I’ve found that an umbrella project works really well for this kind of setup. You’d end up with four directories in
apps:domain(please think of a better name) that has Ecto etc machinery in it and starts a Repomarketing_webthat has an Endpoint attached to (say) port 4000 and has a simple Routerapi_webthat has an Endpoint attached to port 4100 and talks GraphQLadmin_webthat has an Endpoint attached to port 4200 and talks LiveViewThe upside of this approach is that each individual
*_webis simpler and can skip bits it doesn’t care about - for instance,api_webdoesn’t need to startesbuildetc 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_proxyto 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 thatadmin.example.comwent toadmin_webwhileapi.example.comwent toapi_web.