I just discovered LoopBack 4 - how does it compare to Phoenix?

I’ve been trying to identify the backend technology that I will use for an Angular 6 port of my Meteor application. One of my candidates is an API only Phoenix application. I started this, but got stalled not finding “API only” specific documentation. There are a number of tutorials out there but they are either out-of-date or too simplistic or both. I keep hoping that a API-only Phoenix guide will appear.

Just today I discovered LoopBack and in particular LoopBack 4 (http://v4.loopback.io). It reminds me a little of Phoenix stripped of all the frontend stuff. Are there any Phoenix experts out there who have looked at LoopBack 4 and who would care to venture a comparison and/or opinion?


API only Phoenix is fairly easy to achieve. Just mix phx.new --no-brunch --no-html. It will create a new phoenix project without all of the frontend stuff. If you want to see what additional flags the phoenix generator can take, just run mix phx.new and it will print out a helpfile explaining all of the different flags.


There are also some blog posts about building an API with Phoenix…

Loopback 4 seems to be node.js, You might find some familiarity with Meteor and JS world. Probably easier to use, but I doubt it can be more performant than Phoenix API.


The first link looks pretty good. I hadn’t managed to find that one. I’ll go through it. Thanks.

The second link is out of date.

Correct. LoopBack 4 is Node based.

I agree - the Phoenix approach is probably going to be more performant. I wonder how it compares functionality wise though.

I have sufficient skill in both Elixir and JS, so Elixir isn’t an issue. I don’t know Phoenix yet but am willing to learn it to get superior performance and reliability.

They both support Rest and GraphQL API. I suppose they have the same functionalities.

I would consider using Absinthe/GraphQL, as it is really nice to build API with.

If You know Elixir, then You it’s easy to get started with Phoenix. If You select Rest API, I would recommend to use fallback controller.

1 Like

We’ve been building an API in Elixir and found that, while Phoenix is great, it didn’t add anything to our project.

I’ve extracted the webserver and router part that we use in our API if you want to take a look https://github.com/hl/bean

Phoenix brings websocket and channels support, if You don’t need them, You might as well use Cowboy.


I agree – but at this point in my career I prefer apps I can quickly inspect and reverse-engineer, contrasted to super-optimized custom app that somebody managed to squeeze in only 2-3 files.

IMO the API-only mode of Phoenix generates pretty minimal projects and the structure is pretty self-evident. But maybe we need an even more minimal mode – like Ruby’s Sinatra framework (often cited as an alternative to Rails for API-only or in general small / rarely-developed projects). Like, have only lib/router.ex, lib/otp.ex and lib/endpoints.ex files?

(The latter will just be a module with functions like YourApp.users_index or YourApp.sitemap or YourApp.faq)

If you want even more minimal, you may as well just go with plug.

Yeah, I think there’s a market for such minimal app generators. Programmers like me really want to only have 4-5 files in new projects and understand the very real value they bring to the table from the get go.

I love Elixir and won’t back away from it professionally even if that decision costs me some pretty hard times – due to me insisting on finding very particular Elixir jobs – but I find myself wondering lately how can the number of files in new projects be drastically reduced. Still no solid ideas.

After some spending a little time looking at both these, here are some tentative impressions in no particular order:

  1. Loopback 4 is much more similar to Phoenix than Loopback 3. All subsequent references are to Loopback 4.
  2. Loopback focuses purely on API creation. It is very well documented and supported.
  3. Phoenix has very good support for API only development.
  4. The main Phoenix focus is on creating web applications including both the front and back ends.
  5. Although Phoenix can be used for API creation, this use case isn’t well documented. Users will need to look for relevant tutorials. Unfortunately, since Phoenix is constantly evolving, tutorials tend to become out-of-date.
  6. Phoenix API tutorials will never provide all of the necessary detail. Users will need to go through the official documentation to become sufficiently knowledgeable. This will require sifting through non-relevant front end related material.
  7. A Phoenix guide dedicated to API only backends might attract a sizable new user community due to the performance advantages of Phoenix/Elixir/Erlang.
1 Like

I don’t understand what’s confusing about API development, you set up your routes, you return JSON. Where do you see the difficulties for beginners? Is it that people assume they need special views to render JSON??? Something else???

1 Like

I think your input is typical of a person that is already familiar with Phoenix and possibly even Rails.

But say that a person is starting from scratch. He knows nothing about Phoenix (or Rails) and he starts looking at the guides starting at the beginning.

Up and Running

Almost every person on this forum is fluent with another language because it’s very rare to start with Elixir. You mentionned Angular6, so I suppose You might know Javascript.

The problem would be the same if You use node… You would have to learn what is REST, what is MVC,Token, how to secure your endpoint etc.

You assume too much. I am quite familiar with REST, MVC, etc. LoopBack 4 actually is a Node based framework and even has the concept of controllers. What is doesn’t have is any concept or mention of client side development. All of the documentation is relevant only to developing REST APIs.

Don’t get me wrong. I am not advocating for LoopBack or anything else over Phoenix. I am a huge and early advocate of first Erlang and now Elixir. I am attracted to Phoenix because I am very aware of Erlang’s/Elixir’s performance characteristics.

I firmly believe that the adoption rate of Phoenix for API development could be significant expanded if it was promoted as such and relevant documentation became available.