chuck
Missed Opportunity: Phoenix needs a guide for creating REST APIs
Let me start by stating an assumption: Phoenix is a great approach to building REST APIs. There are many reasons for this, but I will assume that those on the forum understand why this is so.
Now assume that a team that needs to create a new REST API has heard about the performance and reliability characteristics of Elixir, and after a little research they come upon Phoenix as an implementation candidate.
Being new to Phoenix, where do they start their research on evaluating Phoenix as a candidate? They will start with the Phoenix guides of course. Sadly, they don’t get very far until they wrongly conclude that Phoenix isn’t what they are looking for. They will conclude that Phoenix’s primary use case is developing monolithic web applications using server rendered HTML. I am sure this has happened because that is what happened to our team. The person charged with evaluating Elixir/Phoenix reported to the team that Phoenix didn’t seem like a good fit, roughly stating the conclusion just described.
Luckily, another person on the team was really impressed with Elixir in general and so chose to do his own evaluation of Phoenix. Again, this person started with the Phoenix guides and again found that it wasn’t a great place to start if one is only interested in using Phoenix to build REST APIs. Our team doesn’t care much about GUIs. We develop REST APIs that are consumable by other teams that build mobile and desktop clients.
So this person resorted to googling for help and found a variety of helpful articles. However, the articles did have some problems. They were often out-of-date and/or incomplete. But he slogged through it. He read through the articles and the Phoenix guides. He also did a lot more googling for additional helpful articles.
The good news is that we have chosen to develop some new REST APIs using Phoenix. The bad news is that had it not been for our stubborn team member we would not have chosen Phoenix or for that matter, Elixir.
There are literally thousands of API teams out there that would be thrilled with the performance, reliability and the pure coding enjoyment of Phoenix/Elixir. If the Phoenix team were to write a guide for this Phoenix use case, I am sure that many of them would choose Phoenix.
Marked As Solved
chrismccord
We do have a section about rendering JSON for apis in the guides:
https://hexdocs.pm/phoenix/views.html#rendering-json
If someone would like to expand on this and/or make it more discoverable, we would love a guide contribution. Thanks!
Also Liked
chuck
Respectfully, I don’t think that Chris’ post is a solution to the thread. Imagine yourself in the position of being completely new to Phoenix and possibly Elixir. Perhaps you have no experience with rails either. Their goal is to learn Phoenix with the express purpose of evaluating it for REST API development. If you proceed through the Phoenix docs or through the “Programming Phoenix” book, there are brief mentions of API creation, but those mentions are obviously far overshadowed by the main theme of the documentation - building self contained web apps with server rendered html.
I’ve heard it dismissively said that Phoenix produced JSON APIs are trivial and are merely JSON views or something to that effect. And perhaps the development of JSON APIs are very easy compared to developing a self contained web apps. All the better. But people that say this already have a very complete understanding of Phoenix. It’s entirely possible that someone new to Phoenix has no real concept of Phoenix endpoints, controllers, views, routers, templates, etc. To tell them that Phoenix API development consists merely of JSON views is meaningless.
My point is simply this. I think if there were an officially supported Phoenix guide for developing REST/JSON APIs, Phoenix’s user base would be increased and this would be a good thing for Phoenix and Elixir.
keathley
At my job we only use phoenix for JSON apis (no html rendering or templates or anything like that). I could totally see the benefit of providing some guides specifically for that. As written the guides are geared to showing all the things that phoenix provides. REST Apis are discussed in the guides IIRC. But having them be their own section seems like it might not be a bad thing. I feel pretty confident that if someone wanted to do that work the phoenix team would be happy to accept it.
kokolegorille
The first hit for a google search on phoenix api is a good api tuto, covering testing as well…
… and Phoenix 1.4
https://lobotuerto.com/blog/building-a-json-api-in-elixir-with-phoenix/
Popular in Discussions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Real-time error tracking, performance insights, and observability for devs.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"