Not readily available, but I would argue that it wouldn’t be a useful comparison for your workload as you’ll always be using cowboy for the application requests so it’s only static assets that nginx will be serving by itself. The rest of the time (during the requests you care about more) it’ll be a reverse proxy adding a miniscule amount of latency to the Cowboy + Elixir response time.
Cowboy is used to proxy every request to applications deployed on Heroku, and previously (I’m unsure if it still is) was used to serve GitHub pages, so that’s some anecdotal evidence about performance. If you are concerned about performance the area to focus on will be you’re application and your database queries rather then the web server when using Phoenix+Cowboy.
This will install nginx in Front of your app. The Erlang VM will be supervised as systemd service.
For your setup (two apps under one umbrella) I’d simply create two backends in nginx and route either a different (sub-)domain for admin/frontend or just rewrite paths.
Yes it would be very simpler if I can serve the admin app through the front app, but unfortunately each web app has its own endpoint. In Phoenix.Routerforward/4 docs I just read :
Note, however, that we don’t advise forwarding to another endpoint. The reason is that plugs defined by your app and the forwarded endpoint would be invoked twice, which may lead to errors.
In my former Phoenix project, I kept admin and front apps in the same web app, but I found the project folder structure a bit overloaded.
Separating them in two different apps makes me feel a lot more comfortable. I am even able to easily build completely different assets structures with webpack config.
You may need to move some plugs around depending on your setup but it’s less work than deploying both, and you can write a unit test for the mounted routes to ensure its all working as intended
I am no deployment master, by no means, but I never found necessary using any platform specific tools for deployment. For all my deployment tasks git was always good enough. Bonus is whatever language or framework you ever want to try you will never need to learn another deployment tool (which is almost never simple to use).
There’s another video on YT that gives an overview of how it works.
If you go the route @shanesveller suggested of just running Cowboy without Nginx, then you might want to take a look at this Stack Overflow answer, so you can run it from ports 80 and 443.
Also, Digital Ocean has a number of excellent guides that may be just what you’re looking for!
I think my problem is that I still do not quite understand some features of Phoenix components.
Thanks to your suggestion, I just made some search on how not to mount a Phoenix endpoint and I found this blog post that gives me a lot of details on one easy way to implement Routing in Phoenix Umbrella Apps.
it’s a bit outdated, but I should be able to adapt it to Phoenix 1.4 projects.
To quickly sum up the post, I will add a third minimal Phoenix app (proxy_app) to the umbrella project. That app will be the main point of contact to the outside world (or one of the existing app could also play this role as you suggested).
Since this app will be the actual web server, we should disable the server setting in the other two:
