|
3 | 3 | [](https://circleci.com/gh/jml/graphql-api)
|
4 | 4 | [](http://haskell-graphql-api.readthedocs.io/en/latest/?badge=latest)
|
5 | 5 |
|
6 |
| -Sketch of GraphQL stuff |
| 6 | +`graphql-api` helps you implement a robust [GraphQL](http://graphql.org/) API in Haskell. By the time a query makes it to your handler you are dealing with strong, static types that make sense for your problem domain. All your handlers are normal Haskell functions because we derive their type signature from the schema. If you have used [servant](http://haskell-servant.readthedocs.io/en/stable/), this will sound familiar. |
7 | 7 |
|
8 |
| -## What it is |
| 8 | +The library provides type combinators to create a GraphQL schema, and functions to parse and evaluate queries against the schema. |
9 | 9 |
|
10 |
| -Aim is to be [servant](http://haskell-servant.readthedocs.io/) for GraphQL. |
| 10 | +You can find the latest release on [hackage](https://hackage.haskell.org/package/graphql-api). |
11 | 11 |
|
12 |
| -To do this, we're going to need: |
| 12 | +We implement the [GraphQL specification](https://facebook.github.io/graphql/) as best as we can in Haskell. We figure they know what they're doing. Even if an alternative API or behaviour looks nicer, we will defer to the spec. |
13 | 13 |
|
14 |
| -* Type-level definition of queries and schemas |
15 |
| -* Evaluation of GraphQL queries (and mutations) according to those types. |
| 14 | +## Example |
16 | 15 |
|
17 |
| -We can build off the |
18 |
| -existing [graphql](http://hackage.haskell.org/package/graphql) library for |
19 |
| -parsing & representing queries. |
| 16 | +Say we have a simple GraphQL schema like: |
20 | 17 |
|
21 |
| -## Why you might want it |
| 18 | +```graphql |
| 19 | +type Hello { |
| 20 | + greeting(who: String!): String! |
| 21 | +} |
| 22 | +``` |
22 | 23 |
|
23 |
| -Right now, you don't. We're working on it. Please feel free to contribute by |
24 |
| -filing issues & submitting PRs. |
| 24 | +which defines a single top-level type `Hello` which contains a single field, `greeting`, that takes a single, required argument `who`. |
| 25 | + |
| 26 | +We can define this schema in Haskell and implement a simple handler like so: |
| 27 | + |
| 28 | +```haskell |
| 29 | +{-# LANGUAGE OverloadedStrings #-} |
| 30 | +{-# LANGUAGE TypeApplications #-} |
| 31 | +{-# LANGUAGE TypeOperators #-} |
| 32 | + |
| 33 | +import Data.Text (Text) |
| 34 | +import Data.Monoid ((<>)) |
| 35 | + |
| 36 | +import GraphQL |
| 37 | +import GraphQL.API |
| 38 | +import GraphQL.Resolver (Handler) |
| 39 | + |
| 40 | +type Hello = Object "Hello" '[] |
| 41 | + '[ Argument "who" Text :> Field "greeting" Text ] |
| 42 | + |
| 43 | +hello :: Handler IO Hello |
| 44 | +hello = pure (\who -> pure ("Hello " <> who)) |
| 45 | + |
| 46 | +run :: Text -> IO Response |
| 47 | +run = interpretAnonymousQuery @Hello hello |
| 48 | +``` |
| 49 | + |
| 50 | +We require GHC 8.0.2 or later for features like the `@Hello` type application, and for certain bug fixes. |
| 51 | + |
| 52 | +With the code above we can now run a query: |
| 53 | + |
| 54 | +```haskell |
| 55 | +run "{ greeting(who: \"mort\") }" |
| 56 | +``` |
| 57 | + |
| 58 | +Which will produce the following GraphQL response: |
| 59 | + |
| 60 | +```json |
| 61 | +{ |
| 62 | + data: { |
| 63 | + greeting: "Hello mort" |
| 64 | + } |
| 65 | +} |
| 66 | +``` |
| 67 | + |
| 68 | +## Status |
| 69 | + |
| 70 | +Our current goal is to gather feedback. We have learned a lot about GraphQL in the course of making this library, but we don't know what a good GraphQL library looks like in Haskell. Please [let us know](https://github.com/jml/graphql-api/issues/new) what you think. We won't mind if you file a bug telling us how good the library is. |
| 71 | + |
| 72 | +Because we're still learning, we make **no** guarantees about API stability, or anything at all really. |
| 73 | + |
| 74 | +We are tracking open problems, missing features & wishlist items in [GitHub's issue tracker](https://github.com/jml/graphql-api/issues). |
| 75 | + |
| 76 | +## Roadmap |
| 77 | + |
| 78 | +* Near future: |
| 79 | + - Better error messages (this is really important to us) |
| 80 | + - Full support for recursive data types |
| 81 | + - Close off lose ends in current implementation & gather feedback |
| 82 | +* Medium future: |
| 83 | + - Full schema validation |
| 84 | + - Schema introspection |
| 85 | + - Stabilize public API |
| 86 | +* Long term: |
| 87 | + - Derive client implementations from types |
| 88 | + - Allow users to implement their own type combinators |
25 | 89 |
|
26 | 90 | ## References
|
27 | 91 |
|
|
0 commit comments