I’m writing an umbrella application that currently has three apps:
- myapp_app (Phoenix, has the frontoffice code, without server)
- myapp_admin (Phoenix, has the backoffice code, without server)
- myapp_web (Phoenix, uses above apps’ routers in a “single server”)
The question I’ve is where should I put authentication stuff (Guardian-related) in the above apps or if I should create a new one solely for that matter… They run all on the same “Phoenix server”.
Thank you in advance for any input.
If You are using Phoenix 1.3.0-rc, You will generate a structure like this
where my_app will contains db layer, and web as the interface.
I do not see why You are using 3 phoenix apps, 2 without servers, because You could simply create Elixir project with mix new, that should be enough to decouple backoffice/frontoffice code.
And now You would put guardian in the my_app_web.
Maybe You don’t use the same version, or maybe You really need 3 Phoenix apps. So maybe my post is out of topic.
But that would be the way I’ll go with your description.
Thanks for the reply @kokolegorille! I didn’t explained myself clearly, sorry.
I’m indeed using Phoenix@1.3.0-rc and the structure is actual like:
my_app is DB layer and some business logic,
my_app_admin is backoffice interface code,
my_app_app is frontoffice interface code and
my_app_web uses both admin and app routers and serves them. The last three are “phoenix apps”, created with
mix phx.new.web task.
I could have them all running on different ports, but I didn’t wanted that behavior and instead I wanted them to run on same port (or better saying server…) but on different paths (backoffice on “/admin” and frontoffice on “/”).
That’s why the code is separated like that and
my_app_web will serve both
And now the question comes… Given that structure, what’s the best place for authentication code reside? Or should I create another app, let’s say
my_app_auth (with authentication code), and serve it like the others within
I know this may seem a little bit confusing and my description of the problem may not help much… But what I tried to achieve with this was code separation between both interfaces (frontoffice and backoffice), to better organize the code and remove entropy, to avoid a monolithic code base.