In case I need to build a JSON API is Phoenix overkill? I don’t quite like the way Phoenix is structured, it remembers me a lot Rails, and given the fact that I just need to expose an JSON API, is Phoenix overkill? Or let me put better, do you see any limitations on using Plug and a router directly?
Phoenix is using Plug. If you’re okay with hooking up everything yourself, there’s no problem just going with Plug, and Cowboy/Bandit directly.
I would not do it, and most people would not do it too probably, because it may prove to be extra work nobody wants to do, and end result being inferior to what Phoenix provides out of the box anyway, but people have free will and if - for example - it’s a learning exercise - go for it!
4 Likes
It’s so interesting how on the one hand people ask for more and more structure guidance within phoenix and then on the other hand it’s held against it.
There’s two parts to the structure discussion. There’s your business logic, where phoenix really doesn’t care what you do. And there’s the my_app_web layer, where again phoenix doesn’t care, but I’d argue conventions are useful for the next person and having worked on other phoenix projects might give you a leg up. Ultimately you can setup your files in whatever structure you want still.
Even though a JSON api won’t necessarily use all the features of phoenix I still think there are a few very useful ones, which would be missing in a bare bandit/plug setup, like the code reloader, features of the router/endpoint and their testing helpers, all the url handling/generation stuff phoenix provides, the error page, …
10 Likes
Usually I would reach for phoenix, but on occasion I have used bandit/plug for simple cases. For example I have an application and want to just expose 1-2 endpoints (like a health check or something of that sort.) I would find it overkill to pull phoenix deps in just for that, but if I am building something and expect to add more routes, I would just start with phoenix. You could generate the project without many of the other things you dont need, see JSON and APIs — Phoenix v1.8.1
You change the file structure any way you see fit. You have 99% freedom. Very little in Phoenix firmly expects this or that in that particular file (if any at all; now I can’t remember).
Phoenix or any framework is an overkill if you have like 2-10 endpoints and you don’t expect the app to change or expand anytime soon, or ever. As @tomkonidas said, if you expect expansion, go for Phoenix. Otherwise you can do fine with just Plug. I’ve done it successfully. It’s a little extra work but at small scales it does not matter and yeah, much less dependencies (though how much is that a true objective positive remains a forever open question).
1 Like
Use Phoenix. Maybe you get some overhead but also a lot less to plump yourself.
And this is the only thing I ever used a bare server app for.
- It was a single need_update? endpoint
- which was missing features (e.g. request validation ) on purpose.
- It only responded with a http status code, stripped from all optional (but common and advised) headers to save bandwidth.
- no logging, minimizing IO
Most time of development was spend at research to minimize the payload.
Ask yourself: What makes you the most productive? A custom solution with no guidance (for you and your fellow (future) devs) or a fleshed out framework with guides all over the place? Quite sure Phoenix is the answer.
Well in this case I am not sure Elixir, or any dynamic language, is a good idea at all.
Just use https://gofiber.io/, you can make an “app” with 3 endpoints literally in 15 minutes. Single binary, cross-compilation supported out of the box, faster than Elixir too (if that even matters for these bare apps).
Does it come with ETS and supervisors? Also much easier to be able to use Cachex.
So maybe that other option is even faster but the load test failed too make impact. In the end the load testing company i worked for (so could go full scale for free) ran out of agents. And we ran tests for (inter)national voting events so it was not a small scale (virtual) server park.
Now I think of it, initially there was confusion if the test was pointing at the right IP, as I was looking at the load charts for CPU and memory and they did not seem to respond to the ramp up phase 
Productivity wise, I think the Elixir app nailed it and as it passed the test with flying colors…
1 Like
I don’t think we are talking micro apps here anymore then.
An entire phoenix application can fit into a single file with roughly 60 lines of code, including dependencies, router, etc.
Like… how much smaller do you want it?
I will post a code snippet when I’m on my computer.
4 Likes
There is this one too
10 Likes
check out ash; it’s another dependency and it brings a lot to the table, but imho it has everything you actually need to expose some APIs
2 Likes
@pmjoe I’ve had similar feelings, and have used Plug plus a helper file to render JSON responses (i.e. json_ok(conn, data) and friends). It feels similar to the Cuba microframework, which I loved using in my Ruby days.
I don’t see it as overkill, when generating a new phoenix app you can drop gettext, any UI thing, any mailer thing and have just a plain http server.
a plain plug router lack a bunch of helpers that the phoenix router have to make it easy to create common restful endpoints(resources and scope being available makes a big difference). also afaik OpenAPISpex only works with phoenix, if your app grows too much it becomes terrible to maintain a big plug router.
A long time ago I worked with an api centric library called maru, but i belive it’s not actively maintained now. It kinda takes a lot from the ruby grape.
1 Like
is Phoenix overkill?
I believe that question is a result of carrying misconceptions from other languages or frameworks which oftentimes add code bloat and performance penalty. Phoenix is not like that. E.g. in Ruby world, you often see discussion about choosing Rails (heavyweight but complete) vs Sinatra (lightweight, requiring more from the user, but not carrying over bloat).
This dichotomy does not exist in Phoenix. The next sentence is a little stretch, but it should give a nice intuition. In the sense of lightness Plug might be comparable to Sinatra. Now, imagine if Rails was just a generator for a full blown app that glues some Sinatra configs together. Then you could use the quick start convention and remove all the unnecessary stuff.
That is exactly how Phoenix works. It is a layer on top of Plug with conventions and configurations. Even better, you don’t need to start with full Phoenix and remove stuff, the mix phx.new task allows specifying –-no-assets –-no-html –-no-live and you are ready to go.
So, in the end, use Phoenix. It is not like Rails which would pull a lot of unnecessary things. Phoenix can be as lean as you need it while benefitting from easy to follow conventions. It is even fine to use Phoenix to server static content with -–no-ecto.
5 Likes
I use Phoenix + Ash that is a perfect couple. Just declarative then get almost APIs That I needed.
In my case, I use Phoenix in my some projects just for transportation throw Phoenix channel before that I have used for JSON API. Phoenix still benefit for me like authentication, verification and encoding/decoding between JSON and Elixir structures.
3 Likes
