Phoenix GraphQL Tutorial with Absinthe

Phoenix Forum Chat / Discussions
,
1

I wrote up a little tutorial on setting up a GraphQL server in Phoenix with Absinthe. Here is a link https://ryanswapp.com/2016/11/29/phoenix-graphql-tutorial-with-absinthe/

This is a starting point that I plan to build on. I’ll hopefully have a post up explaining how I’ve done authentication with Absinthe and maybe move into channels and the frontend. Absinthe is great! If you haven’t given it a shot I recommend checking it out :slight_smile:

23 Likes
2

Thanks Ryan! Added to my reading list.

1 Like
3

I can’t keep on with the amount of resources people are publishing these days haha, thanks for the post Ryan, definitely looking forward to the rest.

1 Like
4

Forget the rest. just keep the graphql =P

5

It’s still a technology I’m interested in, however I’ve just get into the development of APIs so I don’t see when should I use GraphQL at the moment, but anyway, knowledge is always welcome :smile:

6

GraphQL could be considered a replacement for a REST API (or you could have both). REST API’s aren’t bad but they do have some shortcomings (forces you to make multiple calls to the server, returns more data than you need, etc…). GraphQL improves on some of those shortcomings and IMO makes developing an API significantly easier. It’s important to understand REST as it’s a very common API pattern but I think GraphQL is a better alternative.

So, to answer your question, unless you have a hard requirement for a REST API you could skip it altogether and just build a GraphQL API. It is a complete replacement.

2 Likes
7

In the rest APIs you get for instance a json response with some data, and then I can consume it with a front-end technology such as Angular, do I need to include extra packages on the front-end to make a request to a GraphQL API? Or it works with standard HTTP?

8

GraphQL also returns a json response. You will likely want to use a client library to send the GraphQL requests though (similar to how you’d use a HTTP client library). There are a few libraries out there at this point to help make sending requests easier (although it’s easy by itself since you just send a string representing your query). You could use Lokka, Apollo, and others. Lokka is pretty basic and is useful for sending queries. Apollo is more full featured and does caching, etc… Just search for GraphQL clients in whatever frontend tech you use and there’s likely to be quite a few.

3 Likes
9

Just finished trying it, great tutorial as always Ryan, looking forward for one about authentication :slight_smile:

1 Like
10

Good stuff!

1 Like
11

I went to your blog to check out the meteor/phoenix auth post and realized you just wrote a very similar post! haha guess it doesn’t hurt to have lots of info out there.

2 Likes
12

Would you mind explaining how could we query to this application like you do in your tutorial?

I thought the only difference would be author/user and that Ryan uses a database instead of hard-coded data, however the query:

export default graphql(gql`
  query posts {
    id
    title
    user {
      id
      name
    }
  }
`)(PostList);

This query doesn’t work either:

export default graphql(gql`
  query allPosts {
    posts {
      id
      title
      user {
        id
        name
      }
    }
  }
`)(PostList);

Both return the error “posts is undefined”.

Edit: the old trick of posting it to figure it out one minute later, Ryan uses “/api” to forward requests, you use “/graphql”, is it possible to change it?

13

In my post you can change your endpoint by setting up a networkInterface when you initiate your ApolloClient. Check out the Apollo docs for an example.

I think the “posts is undefined” error you’re seeing might be caused by not running Ryan’s migrations and seed script? Be sure to do mix ecto.migrate and then mix run priv/repo/seeds.exs before starting up your server.

I forked Ryan’s project and added the simple Apollo-based front-end from my post. You can also just look at the diff from the last commit to see all of the changes I made. Hopefully that makes things a little clearer.

14

Seems like by default, the apollo client makes the requests to “/graphql”, Ryan instead, set it to “/api”. that was all :smiley:

1 Like
15

Hey Ryan, great article!

I’m trying to hack together an Absinthe app (without Phoenix) and I was wondering how you would split the Schema (into multiple files) before it becomes to big.

I’m using an Electron based client, graphiql-app, because it allow me to set custom headers (e.g. for authentication)

16

Thanks! Good question… I was just thinking about this myself. I haven’t yet tried this out but I think it would work. You could do something like this:

# Another File
defmodule MyApp.Schema.Query.User do
  object :user_queries do 
    field :users, list_of(:user) do
      resolve &MyApp.UserResolver.all/2
    end

    field :user, type: :user do
      arg :id, non_null(:id)
      resolve &MyApp.UserResolver.find/2
    end
  end
end

# Schema file
defmodule MyApp.Schema do
  import_types MyApp.Schema.Query.User
  query do
    import_fields :user_queries
  end
end
1 Like
17

Thanks! Will test this out

18

great stuff man loved it. just a noob question . can we use phoenix template with graphql?

19

Hey there, this is a great question. Most of the stuff you see with GraphQL is using it to power an API. However we have an experimental project we hope to release very very soon that lets you use graphql to power totally ordinary Phoenix views.

3 Likes
20

can’t wait to see it man. and i wish i can contribute as well