chuck

chuck

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.

Showing Posts 1 to 10

adrianrl

adrianrl

You have the book Craft GraphQL APIs in Elixir with Absinthe, it uses Absinthe (a GraphQL implementation for Elixir), which is an interesting alternative to REST for creating modern APIs.

In the end, if you know MVC, then you’re good to build an API, APIs are just MVC without the view part.

chuck

chuck OP

We are looking carefully at GraphQL. It seems to be gaining steam. However, our GUI teams are sticking to REST for the time being. That is what they know and are comfortable with. We’ll be in the REST API business for quite a while I think.

keathley

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.

12
Post #3
kokolegorille

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/

11
Post #4
LostKobrakai

LostKobrakai

So I’m not doing a lot of api stuff, but the only thing different for an api is how data is rendered. The guides about the view layer in elixir has a section on rendering JSON. What else would there be needed for a REST api? I’ve also just looked at a handful of documentations for other frameworks and non of those explicitly detailed REST apis, but rather the higher level concepts by which they operate.

chuck

chuck OP

This, actually, might be the best resource out there. At one point, it was out of date, but it looks like it has recently been updated. Don’t miss my point though. I’m not saying there isn’t suitable documentation out there. It is spread throughout the guides and present in the various tutorials that can be found via google. What I’m saying is if there was a good guide present in the guides, there would be a lot more people getting interested in Phoenix for API-only development. Being a recent and enthusiastic Phoenix adoptee, I would like that.

10
Post #6
abtrapp

abtrapp

As I’m pretty new to Elixir/Phoenix my thoughts:

  1. After making the decision to start with Phoenix and Elixir https://phoenixframework.org/ is the starting point for most people.

  2. Prominent placement on the side “get up and running” → like RoR, not bad for people coming from RoR to see that both frameworks have a lot in common, for other people: Phoenix is easy.

  3. Title of the link: “Build APIs, HTML 5 apps & more” - perfect (especially in this order) - here is my personal BUT…: going to the same page (getting started). When you are looking at the guides there it is about the main concepts like “adding pages” (2nd guide), … - I would go from the prominent main link to a very simple page with “see some basic examples of: REST API, GrapyQL API, web app with server rendered pages, the beauty of long running requests, channels, …” and probably ask some people with the best tutorials if we can put the links in there (or write some according to wishes from the core team & community). a) not all people are googling, some actually like following the links and b) not all tutorials you find are up to date or good. So for me it’s easy now to find a good tutorial, but if you begin and are running in an outdated one that definitively gives you a much harder start.

  4. Apart from that: google, books and especially the community are great, imho nothing to change here :slight_smile:

Short summary of my opinion:

  • Starting page: " Productive. Reliable. Fast." - great
  • Prominent link title: " Build APIs, HTML 5 apps & more" - perfect
  • would opt for a page that shows some quick examples that prove the claims
  • Rest: perfect as it is

Ideally the small examples show some highlights of Elixir because I think most of the people coming here are new to both, the language and the framework. Can we deliver a 30m to 4 hours example for the real world cases with the wow effect that we all got after some hours to days of googling where we hide small gems (not RoR ones) that make the daily life so much easier?

massimo

massimo

The view still exists, it just renders the output in a different format (XML, json, text, …)

It’s as simple as

defmodule MyApp.Router do
  use MyApp, :router

  scope "/api", MyApp do
    pipe_through(:api)

    resources "/items", Api.ItemController
  end
end

defmodule MyApp.Api.ItemController do
  use MyApp, :controller

  def index(conn, params) do
    items = Context.list_items(params)
    render(conn, "index.json", items: items)
  end
end

defmodule MyApp.Api.ItemView do
  def render("index.json", assigns) do
    assigns.items
  end
end
darkmarmot

darkmarmot

Going to chime in to say that the lack of direct API demos was a major irk for me when beginning with Phoenix. Also, there’s a strong bias towards tutorials assuming familiarity with Ruby on Rails – which, coming from other tech, was not a straight forward or happy feeling.

I’ve really enjoyed Elixir for everything except the web stuff.

11
Post #9
dom

dom

I’ve never really understood the utility of dispatching on a string (“index.json”) in the views when building REST APIs. What’s the advantage over directly calling a function like this?

defmodule MyApp.Api.ItemController do
  use MyApp, :controller
  alias MyApp.Api.ItemView

  def search(conn, params) do
    items = Context.list_items(params)
    ItemView.render_many(items)
  end
end

defmodule MyApp.Api.ItemView do
  def render_many(items) do
    items # or whatever logic
  end
end

Where Next? Top

Trending in Discussions Top

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 94592 917
New
cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
heathen
Quite interesting article Google brought me. Didn’t find any mentions about it here. What do you think in general? Would you use togethe...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
AstonJ
Since we have deprecated our Erlang sections (as we have dedicated Erlang Forums now) let’s add this thread for those who’d like to post ...
New
maennchen
:warning: Security advisory: Decimal DoS vulnerability A vulnerability has been published for decimal where very large exponents can cau...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews