| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This adds general API documentation, a tutorial and error handling.
|
|
|
|
|
|
|
|
Now there is one `Resolver` type and the `Output` and `Scalar` types
have been removed. This should be closer to the final Schema definition
API.
|
|
Aside of making the definition of Schemas easier, it takes care of
issues like nested aliases which previously wasn't possible. The naming
of the DSL functions is still provisional.
|
|
|
|
The correspondent end-to-end test has been ported. The variable
definition still needs to be checked.
|
|
The `Schema` has been overhauled to make `Output` monomorphic.
Traversing the `GraphQL` document is handled implicitly while defining
the `Schema`.
The 4th end-to-end test from `graphql-js` has been ported.
|
|
The third end-to-end test from graphql-js was implemented.
|
|
This allows schema definitions with side-effects for any type with a
Monadic/Alternative implementation like IO for example.
|
|
|
|
The first end-to-end test taken from `graphql-js` passes but this still
needs to be extended to support more general cases.
- `Data.GraphQL.Schema` has been heavily modified to support the
execution model. More drastic changes are expected in this module.
- When defining a `Schema` ordinary functions taking fields as input are
being used instead of maps. This makes the implementation of `execute`
easier, and, arguably, makes `Schema` definitions more *Haskellish*.
- Drop explicit `unordered-containers` dependency. `Aeson.Value`s and
field functions should be good enough for now.
|
|
`execute` still needs to be implemented.
|
|
This includes simplications to the Schema data types.
|
|
|
