You can achieve that by simply passing a flag to phx.new:

mix phx.new --umbrella my_app

And then if you need an app that doesn’t talk to the database:

cd my_app/apps
mix new some_api_client

Those capabilities have been there since v1.3. It is not a default but it is definitely promoted as part of Phoenix as a first class concept.

There have been plenty of discussions on why it isn’t the default so maybe someone can post a link to those (in a nutshell, dropping users into an umbrella project without any context may confuse more than help). We also plan to explore and discuss it in the upcoming Phoenix v1.4 book update too.

There is native support in erlang. Here’s a good tutorial. http://rny.io/elixir/phoenix/ldap/2016/09/20/ldap-authenication-with-phoenix.html

Thank you, this is just what I need to start, as most tutorials are focusing on full stack.

You’re planning to use JWT, but do you have any recommendation for LDAP bindings for elixir?

Maybe because being web means it speaks HTTP?
Just think about it for a minute, I think you’ll find it makes sense.

No I am not being pedantic with the name choosen for the Module if that is what you are referring to.

because they are two separate concerns. An API can be used by a mobile app, a web app, an IOT device, another micro-service, etc.

As I said in the because bit an api can be consumed by many different clients, thus my concern is about separation of concerns and software architecture.

The tutorial seems to be based on the Phoenix structure that mixes endpoints for a web app with REST API api can be consumed by many different clients, thus my concern is about separation of concerns and software architecture.

The tutorial seems to be based on the Phoenix structure that mixes endpoints for a web app with REST API endpoints… by their docs it seems that way, both api and web endpoints under same folder lib/myapp_web. Am I misunderstanding something?

Keeping all this endpoints mixed is contra-productive in the long run for a software you release in production… I learned this lesson in the hard-way and now that I separate them is much more easy to maintain, add new features, less prone to bugs and more easy to onboard junior developers. Can take you more hours to develop but saves lots of hours more in the long run.

Now for a pet project is fine to have all mixed once they are normally to throw away once you are done with learning some features you are interest in. For a prototype I would not recommend to mix the endpoints, once they tend to end-up in production.

This is my point of view based on my experience… You may have another view and I love to discuss them, because we always learn something new