WIP: Basic servant like api #2
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* documentation on valid response * instance for "leaf" API * tests & exports
Although I prefer something separate from Servant terminology, while I'm figuring out how to get this to compile, it's useful to have one fewer mental transformation to make.
GraphQL spec provides a limited range of things it can be. This is now encoded in `Response`. Doing this makes it obvious that the return value of the top-level process cannot be the same as that of the individual "handlers". It also makes it obvious that we're allowing non-leaf nodes to be queried, which is against the spec.
Merged
jml
force-pushed
the
basic-servant-like-api
branch
from
999f199 to
e669d1c
Compare
kquick
added a commit
to kquick/graphql-api
that referenced
this pull request
Oct 8, 2019
Prior to this change, the graphql-api internals could generate errors but the user-supplied Handler could not. This adds the ability for the user-supplied Handler to also return an error. 1. Added a HandlerError constructor to the ResolverError to represent errors generated by the handler. 2. Updated the resolve to return a 'HandlerResult a' which is now a typedef for 'Either Text a'. This could not be done as a 'Union' type because the 'Left err' value should have a different effect on the results (null in 'data' and adding to 'errors'). 3. Updated all the HasResolver class instances for the change in haskell-graphql#2. 4. Added 'returns' and 'handlerError' convenience functions for handlers to abstract the internals of the success/failure implementation. 5. Enhanced the tests (particularly ResolverSpec) for testing the generation of success and error results for different handler types. This change is *not* backward compatible---and cannot be because the handlers now need the ability to signal errors. However, all existing handlers which perforce return successful values can be updated rather simply using the new 'returns' helper for each handler field instead of the previous 'pure' function: miniCat name = pure (pure name :<> pure 32) becomes: miniCat name = pure (returns name :<> returns 32) And: handler :: Handler IO Query handler = pure $ \fooId -> do foo <- lookupFoo fooId -- note that fmap maps over the Maybe, so we still need -- have to wrap the result in a pure. sequence $ fmap (pure . viewFoo) foo becomes: handler :: Handler IO Query handler = pure $ \fooId -> do foo <- lookupFoo fooId returns $ viewFoo <$> foo The current reported package version of 0.3.0 should be changed to at least 0.4.0 to indicate a breaking, non-backward-compatible change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Am pressed for time right now. Look at comments & commit messages for commentary.
Essentially, this explores a Servant-like API, realises that we need to have some basic structure around:
There are also some gestures to the type-level API / Schema description, but my own explorations have led me to favour this outside-in approach. We'll need all of the stuff above regardless of how user application code decides to actually handle queries, and figuring them out can make the type-level Servant-like parts easier to reason about.
Thus, I'm trying hard to get the types right, because a lot of stuff follows from that. Not saying that the ones I have here are correct as they stand, but rather that I've put a lot of thought into them and am keen to keep working on them.
Tests were surprisingly useful to add.
This change is