Phoenix as a backend for Apollo Client


I’ve recently started writing a series of posts on setting up a GraphQL backend in Phoenix. I figured I’d share them here for those that may be interested in alternative backends that can be consumed with Apollo Client. You could probably follow along even if you’ve never used Elixir or Phoenix since I walk through setting everything up.

First post: Setting up the API and learning to query it with GraphiQL

Second post: Adding CRUD functionality with mutations

Third post: Adding authentication

Right now the team behind the Absinthe GraphQL library is getting ready to release a library that will work with Phoenix generators. So, adding a GraphQL resource would be as simple as running something like:

$ mix phoenix.gen.graphql User users name:string email:string password:string

How’s that for no boilerplate! Exciting stuff.

In the future I’ll be writing a post on consuming the GraphQL API I build in the posts with Apollo Client. I’m happy to answer any questions that you have if you’re interested in looking into Elixir or Phoenix. Right now is a great time to jump in.


Every time I look at Elixir / Phoenix, I want to jump, but I’m concerned with how long it’ll take to get up to speed vs my comfort with Node.

Three questions.

  1. I’m creating a multi-tenant SaaS application. I’m in love with Meteor accounts and the roles package, and adapting them to a multi-tenant application doesn’t seem too daunting. I forgot the Elixir account module(s), but is the experience a lot different from Meteor?

  2. Phoenix, ecto, channels, and Postgres seem very coupled. How hard is it to bring another database into the fold? I’ve just fallen in love, for better or worse, with Neo4j. How complicated is the transition?

  3. What is the road map, if any, to interface Phoenix channels and Apollo subscriptions (or any other real time push to an Apollo client)

I realize each question could get its own novel. A cursory few sentences would be really helpful. Obviously, the benefits of building a multi tenant SaaS application on Phoenix are gigantic. I’m deathly afraid that the corresponding developer overhead won’t be worth the advantage.

  1. Elixir doesn’t really have a de facto accounts type module. TBH - I kinda like it that way. I always roll my own since what I’m after varies from app to app. It’s super easy to do authentication in elixir with either a JWT API type setup or your typical Railsy server rendered setup. I’d recommend reading Programming Elixir by Dave Thomas and then Programming Phoenix by the core team. They cover auth and you’d be able to get up to speed quickly.

  2. Actually, the only two of the bunch that are coupled are Phoenix and channels since channels is a part of the framework. One thing that newcomers often have to wrap their head around is the idea of OTP applications. In Elixir/Erlang, you create an application that runs on the Erlang VM. The application has a supervision tree that manages other supervisors and individual processes (this is where all the concurrency and fault tolerance comes from). Phoenix or Ecto are just modules that you add to the supervision tree of an application. This won’t make any sense until you’ve played with OTP and understand the significance of it so I’d recommend reading the books I mentioned above and you’ll get a better idea of what I’m talking about. With regard to how easy it is to use Neo4j I’m not entirely sure. I’ve never used it myself and haven’t looked to see if there is a driver. A quick search took me here which may be a good place to start. Postgres, along with MySQL, Mongo, MsSql, and friends are the officially supported databases of Ecto. This just means that there are packages for integrating a driver with Ecto so that you can use Ecto’s querying and migration features. Ecto also has the ability to define schemas and changesets that can be used regardless of whether your database integrates with Ecto (you can think of this as like Simple Schema). I’ve used this with RethinkDB for data validation and mutations. RethinkDB Elixir has fully implemented the ReQL query language so I wouldn’t use Ecto to query the database anyways (it’s really only good for relational databases). Any database that has a driver (or ODBC, HTTP) can work well with Phoenix and Ecto.

  3. I use the Absinthe elixir module for graphql API’s. I know the team behind it is working on an official strategy for integrating subscriptions with channels but it’s not out yet. Apollo is already setup to handle polling so if you need real time features you’re already good to go.

Don’t be afraid to learn something new! Elixir is a functional language, and as a result, learning it will change the way you think about programming (for the better IMO). I don’t consider myself to be particularly intelligent and I was able to pick up Elixir really fast. All it takes is a weekend with the books I mentioned and you’ll be up to speed in no time!


Great post, thank you for your insight and time!

I have both books. In fact, I’ve had both books for many months along with a Stephen Grider Udemy course. I also attend the local Elixir Meetup (meeting tomorrow on Absinthe).

I’m not sure how to learn it. In fact, your post was the first time I’ve seen “do x and y and you’ll be mostly there.” There’s a swirling debate about what you need to know. Do you need to know Erlang? How much OTP do you need? (At our local meet up, a javascripter turned Elixir guy said that he planned to spend a year learning OTP because its footprint is so vast, and you needed to learn that first)

I feel like after a year of learning and using Node, I still have no idea what I’m doing. (My results suggest otherwise, but I’m sure you can sympathize with the sentiment) But your post gave me the kick I need to devote a few days to really trying it. I’ll report back!


Learning is an interesting concept. Somethings are intuitive and somethings require banging our head against a wall for a year(s) until it clicks. The latter certainly describes my experience with learning to program haha. I don’t know what it was about Elixir though, it seemed to click pretty quickly for me. Have you read through those books yet? I’d also suggest reading Elixir in Action if you haven’t already. That is the book that helped me the most in understanding OTP.

Here’s my take on it. Don’t worry about OTP at first. Read Programming Elixir to get familiar with the syntax and then do some exercises. Once you feel like you can solve problems with Elixir it would probably be good for your motivation to actually build something. I think this is where Programming Phoenix comes in. It will show you how to actually do something useful with what you’ve just been learning. After that, I’d play around with building little Phoenix apps so you get comfortable with the API’s. By this point you’ll already have unknowingly used OTP a ton and when you go back to read Elixir in Action you’ll have some context that will help you pick it up fast. Elixir in Action feels like an intermediate version of Programming Elixir. It’s perfect for helping you to understand a lot of the deeper concepts. Then, you can move on to the heavy hitters like the designing Erlang systems book (haven’t read it but I hear its awesome). Lastly, don’t worry about learning Erlang. Erlang has the same semantics as Elixir but with a different syntax. Once you learn one its just a matter of translating to the other syntax.

If you have questions I’m happy to help! I’m generally always around in the Elixir slack room so feel free to shoot me a message.