Skip to content

Commit 8575d54

Browse files
authored
Merge pull request #88 from jml/readme
Draft readme.
2 parents dfcd95a + 87b19b5 commit 8575d54

File tree

1 file changed

+76
-12
lines changed

1 file changed

+76
-12
lines changed

README.md

+76-12
Original file line numberDiff line numberDiff line change
@@ -3,25 +3,89 @@
33
[![CircleCI](https://circleci.com/gh/jml/graphql-api.svg?style=shield)](https://circleci.com/gh/jml/graphql-api)
44
[![Documentation Status](https://readthedocs.org/projects/haskell-graphql-api/badge/?version=latest)](http://haskell-graphql-api.readthedocs.io/en/latest/?badge=latest)
55

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.
77

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.
99

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).
1111

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.
1313

14-
* Type-level definition of queries and schemas
15-
* Evaluation of GraphQL queries (and mutations) according to those types.
14+
## Example
1615

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:
2017

21-
## Why you might want it
18+
```graphql
19+
type Hello {
20+
greeting(who: String!): String!
21+
}
22+
```
2223

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
2589

2690
## References
2791

0 commit comments

Comments
 (0)