The document provides an overview of functional APIs using Absinthe GraphQL and the Elixir programming language, highlighting key concepts like Ecto, a data access library, and the benefits of GraphQL as an alternative to traditional REST APIs. It explains the structure of GraphQL schemas, types, and operations, as well as how to implement a GraphQL API for a contract list application using Absinthe and Phoenix. Additionally, it includes references to various resources for deeper learning and practical examples related to the setup and migration of apps from REST to GraphQL.

1. Functional APIs with
Absinthe GraphQL
Zvi Avraham
zvi@nivertech.com

2. $ whoami
zvi
● Distributed Systems
○ Realtime Dataflow clusters 6PT/day
○ Scalable Messaging (3M sessions/node)
○ NoSQL Databases
● Crypto
○ Blockchain & Smart Contracts
○ Cryptoeconomics
○ Token Engineering

3. Agenda
● briefly introduce GraphQL
● Introduce Elixir
● Introduce Ecto
● give overview of Absinthe toolkit
● show an example of implementing GraphQL
API for Contract List app using Absinthe &
Phoenix

4. Assumptions
● Reading basic Elixir code
○ Similar to Ruby
● Know at least one modern web framework
○ Rails, Django, etc.
● Basic intuitive understanding of GraphQL
○ JSON QBE (Query-by-Example)

5. Why GraphQL?
Let’s assume the boss told us to use it ;)

8. Front end Back end

9. Front end Back end

10. Front end Back end

11. Front end Back end

12. Front end Back end

13. GraphiQL query tool Back end

14. GraphiQL query tool Back end

15. Front end Back end
GraphQL
schema
Schema - a contract between Backend & Frontend

16. Front end Back end
GraphQL
schema
Schema - a contract between Backend & Frontend

17. GraphQL Schema
● Schema != Data Model
● It’s a Logical Data Model using graph paradigm
● Your Physical Data Model can be very different
○ Database (Relational, K/V, GraphDB, etc.)
○ Fetching data from external APIs
○ Computed on demand

18. In Schema we define:
● Types
● Operations:
○ Queries
○ Mutations
○ Subscriptions

19. =
or

20. Elixir
● Functional
● Concurrent
● Ruby-like syntax
● Compiled to Erlang bytecode
● Built on battle-proven BEAM VM

21. Elixir
● Dynamically typed
○ optional static type analyzer
● Pattern matching & guards
● Pipe operator “|>”
● Structs (like tagged maps)
● Hygienic macros
● No preprocessor like in Erlang
○ use attributes & macros instead

25. Intro to Ecto

26. Ecto is not an ORM, it’s a Data Access library
https://boylesoftware.com/blog/orm-must-go/

27. Ecto in a nutshell
● Repo
○ the repository of data storage. The Repo hides implementation details
from models. It can provide access to different data storages such as
databases or in-memory storages.
● Migrations
○ CREATE/ALTER/DROP TABLE/INDEX
● Schema
○ a mapping between a DB table and its columns with the Elixir struct
● Changeset
○ cast attributes value into correct types, add validation rules & constraints.
● Query
○ Internal DSL wrapper in Elixir around composable SQL queries.

32. Following slides are based on:
● Phoenix & Elm, a real use case (parts 1-6)
○ by Ricardo García Vega, @bigardone
○ http://codeloveandboards.com/blog/2017/02/02/phoenix-and-elm-a-real-use-case-pt-1/
○ https://github.com/bigardone/phoenix-and-elm
○ Live demo: https://phoenix-and-elm.herokuapp.com/
● Migrating a Phoenix & Elm app from REST to GraphQL
○ by Paul Fioravanti, @paulfioravanti
○ https://paulfioravanti.com/blog/2018/03/06/migrating-a-phoenix-and-elm-app-from-rest-to-graphql/
○ https://github.com/paulfioravanti/phoenix-and-elm - branch graphql

34. Phoenix Project Layout

41. Ecto adds :id field for primary key
field(:id, :integer)
Timestamp macro expands into 2
fields:
field(:inserted_at, :date)
field(:updated_at, :date)

45. The GraphQL toolkit for Elixir
https://absinthe-graphql.org/

46. Source: Craft GraphQL APIs in Elixir with Absinthe
https://pragprog.com/book/wwgraphql/craft-graphql-apis-in-elixir-with-absinthe

47. Source: Craft GraphQL APIs in Elixir with Absinthe
https://pragprog.com/book/wwgraphql/craft-graphql-apis-in-elixir-with-absinthe

48. Phoenix with Absinthe is simpler
We don’t need usual
Phoenix functionality:
● No controllers
● No views
● No templates
We only need to:
● Define schemas
● Define custom types
● Write resolvers

65. Ecto and Phoenix: Doing web with Elixir - Yurii Bodarev
https://www.slideshare.net/Elixir-Meetup/ecto-and-phoenix-doing-web-with-elixir-yurii-bodarev

75. Thank You! Any Questions?
zvi@nivertech.com

76. Slides, screenshots and code are based on:
● Phoenix & Elm, a real use case (parts 1-6)
○ by Ricardo García Vega, @bigardone
○ http://codeloveandboards.com/blog/2017/02/02/phoenix-and-elm-a-real-use-case-pt-1/
○ https://github.com/bigardone/phoenix-and-elm
○ Live demo: https://phoenix-and-elm.herokuapp.com/
● Migrating a Phoenix & Elm app from REST to GraphQL
○ by Paul Fioravanti, @paulfioravanti
○ https://paulfioravanti.com/blog/2018/03/06/migrating-a-phoenix-and-elm-app-from-rest-to-graphql/
○ https://github.com/paulfioravanti/phoenix-and-elm - branch graphql