Phoenix GraphQL Tutorial with Absinthe: Add CRUD Using Mutations

Phoenix Forum Chat / Discussions
, , ,
1

I wrote up the second post in a series I’m doing on using Phoenix and Absinthe to build GraphQL API’s. In this post I cover adding CRUD functionality with mutations. Please let me know if you have any questions. Happy to help in any way that I can!

https://ryanswapp.com/2016/12/03/phoenix-graphql-tutorial-with-phoenix-add-crud-using-mutations/

15 Likes
2

You’re my hero for making these!

5 Likes
3

Haha I’m glad you approve! Thanks for the library! You and Bruce are doing great work.

2 Likes
4

You sir are my Savior, thank you so much, I’ll read it when I get home.

1 Like
5

Great, loved the first. Doing it now. Thanks very much!

1 Like
6

Nice post! I was wondering though: do you ever played with the idea @chrismccord mentioned on 2015’s ElixirConf Keynote? More specifically what he talks between 25th and 27th minutes, the idea of using a Phoenix.View with a GraphQL as the data layer.

1 Like
7

We have an experimental library that does exactly this. Let me see if we can carve out some time this week and get a beta released.

4 Likes
8

Nice! :slight_smile:

Once you get it released, let me know here, I’ll probably test it on the product I’m working on. :slight_smile:

9

Just finished reading it, thank you once again @ryanswapp :smile:

1 Like
10

Can’t express how much i want this! :heart_eyes:

11

We’ll get this out soon. We actually have it driving the Phoenix CRUD scaffolding with very minimal edits (including queries and mutations). Just some work around serialization (eg, views probably don’t want serialized time structs they then have to deserialize) and some utilities for error feedback before we push this out there.

Here’s a sneak peek of working code. Note the 3-arity actions; Absinthe processes input using the associated document, hands off result to action for response. It is pretty cool to have your Absinthe schema handle the complexities of input validation and database operations and just focus on what to show them!

  @graphql """
  mutation ($id: ID!, $user: InputUser!) {
    user: update_user(id: $id, input: $user) { ... UserFields }
  }
  """
  # Note: The "UserFields" fragment used above is defined by the View, as
  #       it's a view concern.
  def update(conn, %{user: user}, []) do
    conn
    |> put_flash(:info, "User updated successfully.")
    |> redirect(to: user_path(conn, :show, user))
  end
  def update(conn, %{user: user}, _errors) do
    conn
    |> put_flash(:error, "An error occurred.")
    |> redirect(to: user_path(conn, :edit, user))
  end
10 Likes
13

Any updates? I couldn’t find anything about this on GitHub

1 Like
14

Unfortunately this fell behind some other features. I’ll report back here when I have a better idea of when we can get it out there – I’ll try to at least get some code up people can play with, even if it’s not released on Hex.

3 Likes
15

This would be great! Looking at this discussion, quite some people are building core, web and api applications, but using this it might be possible to have the api as the core and use it on the server in web :slight_smile:

1 Like