Skip to content
This repository has been archived by the owner on May 26, 2023. It is now read-only.

Alternative to graphql_ppx? #140

Open
2 of 5 tasks
swac opened this issue Sep 29, 2018 · 5 comments
Open
2 of 5 tasks

Alternative to graphql_ppx? #140

swac opened this issue Sep 29, 2018 · 5 comments
Labels
docs Focuses on documentation changes feature New addition or enhancement to existing solutions

Comments

@swac
Copy link

swac commented Sep 29, 2018

Issue Labels

  • has-reproduction
  • feature
  • docs
  • blocking
  • good first issue

It seems all of the existing examples and documentation suggest using graphql_ppx to parse queries and responses. graphql_ppx currently has significant limitations, such as not supporting interfaces and inline fragments, however. Is there any alternative to using graphql_ppx with Reason Apollo? If so, it would be great to have an example documented. If not, is there any workaround for querying a GraphQL API that uses interfaces?

@ghost ghost added docs Focuses on documentation changes feature New addition or enhancement to existing solutions labels Sep 29, 2018
@kgoggin
Copy link

kgoggin commented Oct 2, 2018

Yep, you can definitely use reason-apollo without graphql_ppx, though I agree it's not super obvious. Basically, if you're using graphql_ppx, it creates a module that conforms to the Config type defined here. So if you don't want to use graphql_ppx, you can just definite your own Config module with the query, type t, and parse function.

I wrote about why/how I'm doing Apollo in Reason without graphql_ppx. Essentially I define Reason types that align to all of my GraphQL types, and then a QueryRoot type that matches GraphQL's Query. Then all of my query config modules have type t = QueryRoot.t and parse is a set function that takes the JSON response from apollo and turns it into a QueryRoot.t. Mutations are a little different, but not to dissimilar.

I prefer this approach because I can reuse types everywhere, and because of the limitations you mentioned with graphql_ppx regarding interfaces and inline fragments. I've actually got all of my queries and mutations defined in .graphql files, which I also prefer because I can lint them!

Hope that's helpful. I'm unsure about the best way to document any of this in this repo because it's a pretty significant difference in the way you work with it.

@baransu
Copy link
Contributor

baransu commented Oct 2, 2018

Soon (I hope), graphql_ppx will have support for interfaces (not in 100% but for most of the use cases). Here you can check the PR: mhallin/graphql_ppx#56 And if you're interested in some functionality that's missing in graphql_ppx please create an issue or submit a PR 🙂

@Enalmada
Copy link
Contributor

Enalmada commented Oct 2, 2018

@kgoggin That is an amazing article....wow. Would you consider putting up a non graphql_ppx version of the swapi example with concepts in your article? I think that might give the community an appropriate place to watch/discuss the current state of things with issues/pull as things change. Plus, as a new user, being able to fire up a fully functional example and see all the setup details (linting, pattern matching, etc) is invaluable and helps get others on the bandwagon.

@swac
Copy link
Author

swac commented Oct 2, 2018

@baransu Thanks, I hadn't seen that! I actually checked the graphql_ppx repo before creating this issue and saw that there's already an issue regarding interface support: mhallin/graphql_ppx#47. I didn't want to create a redundant issue, so I filed this one.

@baransu
Copy link
Contributor

baransu commented Jan 10, 2019

@swac graphql_ppx starting from version 0.2.8 have interfaces support.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
docs Focuses on documentation changes feature New addition or enhancement to existing solutions
Projects
None yet
Development

No branches or pull requests

4 participants