Learn GraphQL with GitHub(github.com)
github.com
Learn GraphQL with GitHub
https://github.com/blog/2412-learn-graphql-with-github
39 comments
I've created a really basic server + client tutorial here:
https://github.com/theogravity/graphql-apollo-server-client-...
I actually have stopped using Apollo on the server side (outside of the middleware) to build the GraphQL definitions.
I use the vanilla graphql-js lib instead with the join-monster library for queries + batching + paging and objection.js for modeling + mutations.
join-monster is built for using your database with graphql (I use postgres). Objection.js is great for mutations because of its insertGraph / upsertGraph functionality, where you can feed in your entire mutation input as a nested structure and it will perform the right insertion queries to multiple tables based on your objection.js models that you've defined.
I've learned much more since then (eg authorization / authentication / mutations / implementing paging via relay connections) that I'll probably start up another project in the future talking about how to build a full-scale GraphQL server.
https://github.com/theogravity/graphql-apollo-server-client-...
I actually have stopped using Apollo on the server side (outside of the middleware) to build the GraphQL definitions.
I use the vanilla graphql-js lib instead with the join-monster library for queries + batching + paging and objection.js for modeling + mutations.
join-monster is built for using your database with graphql (I use postgres). Objection.js is great for mutations because of its insertGraph / upsertGraph functionality, where you can feed in your entire mutation input as a nested structure and it will perform the right insertion queries to multiple tables based on your objection.js models that you've defined.
I've learned much more since then (eg authorization / authentication / mutations / implementing paging via relay connections) that I'll probably start up another project in the future talking about how to build a full-scale GraphQL server.
To get started and understand how to build a GraphQL server, here's a nice video: Zero to GraphQL in 30 Minutes [0].
[0] https://www.youtube.com/watch?v=UBGzsb2UkeY
[0] https://www.youtube.com/watch?v=UBGzsb2UkeY
Huge thanks to the GitHub team for putting together this webcast!
For everybody interested who already wants to get familiar with GraphQL, check out this getting started tutorial for GraphQL: https://www.howtographql.com/
For everybody interested who already wants to get familiar with GraphQL, check out this getting started tutorial for GraphQL: https://www.howtographql.com/
Is that 10 PDT or 10 PST? Trying to convert but confused...
What is the purpose of webcasts? Why not just post a video? I presume it's not interactive Q&A -- too many people would be watching.
If anyone is interested in jumping straight in to GraphQL, I recommend graph.cool. It was posted a while back when the service was first released. Their free developer tier is awesome, and their project tier is completely reasonable.
There is also the graph.cool slack channel if you're looking for an active GraphQL community. You can usually find someone to help you out with questions there.
Any way to watch this without signing up or registering for anything?
I'd just like to download the video directly, if at all possible.
I'd just like to download the video directly, if at all possible.
They put up recordings later, hosted on Vimeo; for example:
https://resources.github.com/webcasts/GitHub-communicating-w...
With some digging you can get an MP4.
https://resources.github.com/webcasts/GitHub-communicating-w...
With some digging you can get an MP4.
Probably not, my tip is to sign up, but then wait for the recording to be available (they usually are), once a recording is posted you can see where did they post it to and then download.
I do this from time to time
To all considering using graphql, let me tell you something that was unclear to me when I first tried it:
If you plan to use it with a schemaless (nosql/graph) backend, graphql will force you to write a schema for it. If you can't (due to dynamic data), you will just end up forcing graphql treat your data as json-blobs with no schema.
Graphql turns into a json-blob transmitter with no benefits.
Also, if you have deeply nested/recursive data structures, the client performing the query needs to know just how deep it should query. This can lead to ridiculous queries if you're running on a graph db where the client doesn't know how many vertices it should traverse.
REST is a better fit if the above is true for you.
To anyone put off by this comment: don't be. With all due respect the parent commenter has misunderstood how to shape their API responses.
GraphQL excels at nested data structures. When you have infinitely recursive child nodes of the same type (like ancestors in a family tree) the GraphQL list type should be used.
GraphQL excels at nested data structures. When you have infinitely recursive child nodes of the same type (like ancestors in a family tree) the GraphQL list type should be used.
To help solve the nested/recursive query problem, Facebook created dataloader: https://github.com/facebook/dataloader There's graphql integration info on the blog: http://graphql.org/blog/rest-api-graphql-wrapper/#taming-pat...
I probably was a bit unclear.
Lets say I've got a family tree stored in a db that goes back 1000 years.
Through graphql I want to find my first ancestor following all mothers backwards. The query would be:
Of course it's possible to create a new graphql endpoint for this type of query, but then we've just recreated REST in graphql.
Through graphql I want to find my first ancestor following all mothers backwards. The query would be:
query familyTree {
name,
mother {
name,
mother {
..and so on for an unknown number of nestings
}
}
}
Of course it's possible to create a new graphql endpoint for this type of query, but then we've just recreated REST in graphql.
Hmm, you're not quite thinking in GraphQL properly. That isn't how your schema should be designed.
Your mother field should resolve to a Person type, with a mother and/or ancestors field, which would be a graphql list type of the Person type.
Something like this:
Your mother field should resolve to a Person type, with a mother and/or ancestors field, which would be a graphql list type of the Person type.
Something like this:
Person {
mother: Person
femaleAncestors: [Person]
}Yeah ideally ancestors would be a `connection`/`edge` with filters:
``` Person { ancestors(gender: Female, orderby: [AGE], first: 10) { node { name } } } ```
``` Person { ancestors(gender: Female, orderby: [AGE], first: 10) { node { name } } } ```
Absolutely. Personally I haven't made much use of NoSQL, I'm sure there are plenty of use cases, but for ancestry I would still use a relational db.
I do see how nested objects might look like a perfect fit for this, since families are literally "nested objects". Perhaps there are plenty of advantages to using NoSQL and shaping the data this way... but the thought of creating an API With that structure is terrifying to me, haha.
Question to OP: are you using this structure for a live api/website I can take a look at? Does each node have an absolute ID? Do you normalize your data? Maybe I'm thinking too much in relational terms here? I'm genuinely curious about this.
I do see how nested objects might look like a perfect fit for this, since families are literally "nested objects". Perhaps there are plenty of advantages to using NoSQL and shaping the data this way... but the thought of creating an API With that structure is terrifying to me, haha.
Question to OP: are you using this structure for a live api/website I can take a look at? Does each node have an absolute ID? Do you normalize your data? Maybe I'm thinking too much in relational terms here? I'm genuinely curious about this.
[deleted]
For the recursive issue we have a directive that lets us specify a recurse level. The server validates that with a maximum value.
As for schema-less we generate a scheme that includes all types and fields but we filter out any non-available ones (according to user with) each time an introspection query is issued.
As for schema-less we generate a scheme that includes all types and fields but we filter out any non-available ones (according to user with) each time an introspection query is issued.
I believe that Falcor's JSON Graph[1] supports recursion rather well.
[1]: https://netflix.github.io/falcor/documentation/jsongraph.htm...
[1]: https://netflix.github.io/falcor/documentation/jsongraph.htm...
[deleted]
[deleted]
Yet another tutorial about using a GraphQL client. It's nice but I think the hard part is implementing a GraphQL server. Are there any examples of a full blown GraphQL server, interpreting complex queries as SQL/NoSQL queries in a performant way?
> Are there any examples of a full blown GraphQL server
Sure! But here's the thing to know: the meat of a GraphQL server is in the schema. Every server implementation you see will have you define a schema, and then will execute queries against it. I would do the setup for the implementation in the language of your choice (instructions for which is usually listed in the README of the git repo), and then take a look at example schema, the most famous of which is the Star Wars schema:
For JS: https://github.com/jahewson/graphql-starwars
For Python (Graphene): https://github.com/graphql-python/graphene/tree/master/examp...
> interpreting complex queries as SQL/NoSQL queries in a performant way
Something which is often confusing is that GraphQL is completely database agnostic. However you were fetching data from your database of choice before, you will continue to do. GraphQL has you define types (i.e. a user type, a blog post type, etc.), and then you tell it how to fetch that data. It could be a library for SQL, NoSQL, or even another API.
Sure! But here's the thing to know: the meat of a GraphQL server is in the schema. Every server implementation you see will have you define a schema, and then will execute queries against it. I would do the setup for the implementation in the language of your choice (instructions for which is usually listed in the README of the git repo), and then take a look at example schema, the most famous of which is the Star Wars schema:
For JS: https://github.com/jahewson/graphql-starwars
For Python (Graphene): https://github.com/graphql-python/graphene/tree/master/examp...
> interpreting complex queries as SQL/NoSQL queries in a performant way
Something which is often confusing is that GraphQL is completely database agnostic. However you were fetching data from your database of choice before, you will continue to do. GraphQL has you define types (i.e. a user type, a blog post type, etc.), and then you tell it how to fetch that data. It could be a library for SQL, NoSQL, or even another API.
Question, how well do GraphQL APIs compose?
For example, imagine I define my GraphQL schema which is pretty similar to another GraphQL schema (of a remote API server).
Could I implement my GraphQL server's resolvers in such a way that they simply rewrite/reinterpret the incoming query by forwarding the (modified) query to the target remote GraphQL server? Or will it be very inefficient and very hard to write this kind of GraphQL-schema-to-similar-GraphQL-schema adapter?
To compare REST, one can imagine (a part of) your REST API being similar to another external REST API. It's relatively straightforward to have your HTTP handlers map to remote REST API endpoints and make the neccessary conversions. (Assuming your REST endpoints map relatively 1:1 to the other API's REST endpoints).
Hopefully my question makes sense...
For example, imagine I define my GraphQL schema which is pretty similar to another GraphQL schema (of a remote API server).
Could I implement my GraphQL server's resolvers in such a way that they simply rewrite/reinterpret the incoming query by forwarding the (modified) query to the target remote GraphQL server? Or will it be very inefficient and very hard to write this kind of GraphQL-schema-to-similar-GraphQL-schema adapter?
To compare REST, one can imagine (a part of) your REST API being similar to another external REST API. It's relatively straightforward to have your HTTP handlers map to remote REST API endpoints and make the neccessary conversions. (Assuming your REST endpoints map relatively 1:1 to the other API's REST endpoints).
Hopefully my question makes sense...
I'm still fairly new to GraphQL, so take this with a grain of salt, but it's my understanding that a idiomatic GraphQL server would implement a single purpose resolver function for _every single field_ in the schema, and these field resolvers would then compose together to resolve larger query fragments. Often a request caching & batching layer like Facebook's own DataLoader library is necessary to make data fetching efficient and performant under this model: http://graphql.org/learn/best-practices/#server-side-batchin...
So in other words, for parts of your schema that are similar to each other, you'd simply include and compose together the relevant resolver functions for the fields they share. The conceptual model is similar to reducer composition in Redux, where top-level reducers (analogous to the root query resolver in GraphQL) can delegate to child reducers each responsible for only a part of the application state (or child resolvers each responsible for resolving a single fragment of the whole query), and this delegation can continue to arbitrary depths.
EDIT: I see your question is actually about composing with third party GraphQL APIs, so I haven't really answered it. GraphQL resolvers are just functions that return data. So you can certainly just implement an async resolver that forwards the received GraphQL query to a remote API of interest, and take the response returned and merge/override it with additional data to form the response to your own query.
So in other words, for parts of your schema that are similar to each other, you'd simply include and compose together the relevant resolver functions for the fields they share. The conceptual model is similar to reducer composition in Redux, where top-level reducers (analogous to the root query resolver in GraphQL) can delegate to child reducers each responsible for only a part of the application state (or child resolvers each responsible for resolving a single fragment of the whole query), and this delegation can continue to arbitrary depths.
EDIT: I see your question is actually about composing with third party GraphQL APIs, so I haven't really answered it. GraphQL resolvers are just functions that return data. So you can certainly just implement an async resolver that forwards the received GraphQL query to a remote API of interest, and take the response returned and merge/override it with additional data to form the response to your own query.
Depending on what you're looking for, it might not be straightforward with the normal high level utilities, but most libraries also provide lower level functions for parsing and such.
If you just want to grab an object for a certain edge than that's easy. Routing the entire query differently based on something at the root would also be easy, but routing it based on something deeply nested might be trickier, but still not too tricky.
If you just want to grab an object for a certain edge than that's easy. Routing the entire query differently based on something at the root would also be easy, but routing it based on something deeply nested might be trickier, but still not too tricky.
There's PostGraphQL, which serves a PostgreSQL database as a GraphQL schema: https://github.com/postgraphql/postgraphql
I used the server tutorials in howtographql.com, they were very informative.
Scroll down to the hands on tutorials, the ones on the right are server-side tutorials. I still recommend you read through the beginner material as well!
https://www.howtographql.com/
Scroll down to the hands on tutorials, the ones on the right are server-side tutorials. I still recommend you read through the beginner material as well!
https://www.howtographql.com/
Seconded - Tons of GraphQL + Apollo Client tutorials out there but not much on the server. I've been using Graph.cool which does the work for me but if I have to make a server it'll be a lot harder.
The necessary bits are there in .NET for F#; possibly also C# 7:
https://news.ycombinator.com/item?id=14896809
This all could make it very easy to write a GraphQL server backed by Rezoom + Rezoom.SQL.
https://github.com/rspeele/Rezoom
https://github.com/rspeele/Rezoom.SQL
--
If there are any other resources I'm not aware of, please let me know!
https://news.ycombinator.com/item?id=14896809
This all could make it very easy to write a GraphQL server backed by Rezoom + Rezoom.SQL.
https://github.com/rspeele/Rezoom
https://github.com/rspeele/Rezoom.SQL
--
If there are any other resources I'm not aware of, please let me know!
I created a boilerplate example that uses Hapi, Apollo Server, Knex (SQLite) & Webpack to give you an idea on how to get started. Apollo Server makes it easy for you understand how to write a GraphQL server by breaking it down into typeDefs and resolvers, that are needed to create your schema.
https://github.com/abesamiskevin/hapi-graphql
https://github.com/abesamiskevin/hapi-graphql
Check out the guide on Absinthe, which is an elixir library.
Here's one using Neo4j (graph databse): https://neo4j.com/developer/graphql/
If there are any, they were born of pure confusion of what graphql is/supposed to be
[1] https://developer.github.com/v4/
[2] https://github.com/google/go-github/issues/646
[3] https://github.com/shurcooL/githubql