What is benefit of having multiple phoenix endpoints

I know that we can have multiple endpoint, but what is it actually for. I mean real world use-case.


You mean like Phoenix endpoints?

There are multiple advantages. You can start admin panel on one port, and the rest of site on another. You can prepare new version of your front-end and run it in parallel to old one. You can split up your apps into smaller chunks. Not sure if that answers your questions…


Read about umbrella’s, have a look at the links jlevy sent here Umbrella with 2 phoenix apps, how to forward request from 1 to 2 and vice versa

Yes, I mean phoenix endpoints. I haven’t notice that , sorry.

I have read that, also great article :). But you mention in that post endpoint forwarding is not advisable. So I’m curious what is the good usecase of phoenix multiple endpoints.

I used that approach once to restrict the access to the admin site. Two endpoints means that two sites listen on different ports, so you can control the port accessibility. In my case, the port of the main site was accessible from the outside, while the admin site port was not. Thus, the only people who could have accessed the admin site were the ones who had SSH access to the server.


That comment in the docs confused me, and others also. See this excerpt from http://slack.elixirhq.com/phoenix/2015-12-30/

chrismccord 14:16:53 UTC
hubert.lepicki: you can forward to your admin plug/router, `forward "/admin", AdminApp.Router`
chrismccord 14:17:14 UTC
then the forwarder router is served by its endpoint, which is the only webserver running
chrismccord 14:17:26 UTC
the rest is plain old modules
henrik 14:23:11 UTC
sashaafm: http://toolbox.elixir.pm/#p-43
hubert.lepicki 14:25:41 UTC
chrismccord 14:26:05 UTC
forwarding to another **endpoint**
hubert.lepicki 14:26:06 UTC
> 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.
chrismccord 14:26:13 UTC
but you can forward to another router

In general about the use case for splitting your application into phoenix + regular apps:
it can serve separation of concerns, as Wojtek Mach says: “break up this system into a collection of smaller applications, each of which has a well defined boundary, domain model, set of responsibilities, and can be worked on independently” (https://speakerdeck.com/wojtekmach/building-an-umbrella-project).
Some more: http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-microservices/ , paragraph “Breaking monolithic applications”

How do you go about restricting access to a certain port by SSH?

By asking the endpoint to only accept connections from localhost on that port, and then using SSH port forwarding to make a port on your development machine exit from your app server’s localhost.


I know it’s a old post, but I think is worth mentioning this real world use case of using Multiple Endpoints in Phoenix.

In this post I want to show how to add another endpoint in Phoenix Framework, that is going to listen on a different port. I found out that this topic is not well described in the internet. In our case, this endpoint will be serving a very simple API returning status of the app. The following instructions work with Phoenix version 1.3.2

A separate endpoint gives extra security

The first question that comes to mind is “why?”. Why do we need to have a service on a separate port or even on a separate network interface? The biggest advantage and the most important one is security. By port/interface separation we can easily protect our service from unwanted traffic. For example: Our load balancer is connected to port 80 where we expose public API however, in our app and we want to expose private diagnostic API on port 8080 as well - by doing it public traffic can only hit our public API(80). We get pretty good protection of diagnostic API without authentication and authorization - of course we may still want to do that - to restrict access, even to traffic from our private network. Thanks to the separation some of it can be achieved on the firewall/routing level. Apart from that there are many examples, why it makes sense: admin interface, node stats page, health check and more.

Looks like the link is dead, but the waybackmachine as a copy of it

1 Like