6 ms·

GraphQL Tooling, Today and Tomorrow [video]

115 points by sgrove 7y ago

nitinreddy88 7y ago
We are in the process of debating ODATA Api vs GraphQL for data analytics. Anyone with extensive experience can share some light/guide us.
- _92eu 7y ago
  With HTTP2, it's now almost always better to go with a RESTful API, especially if you need to do heavy calculations and display dashboards with a lot of data. You will be able to fine tune your cache settings and monitor the performance of your endpoints (https://medium.com/@__xuorig__/why-graphql-performance-monitoring-is-hard-41381bc7c44d https://medium.com/@__xuorig__/why-graphql-performance-monit...) You will be able to fetch resources in parallel and start displaying data faster (GraphQL Apollo is also able to do some king of streaming, but it relies heavily on non-standard network hacks). You will be able to use Vulcain (https://vulcain.rocks/ https://vulcain.rocks/) which will allow you to fetch your whole resource graph at once using HTTP2 Server Push. The only reason you may choose GraphQL is if you need to go fast and want to profit from the DX of the awesome React libraries available such as Relay or Apollo.
  - deleted 7y ago
    [deleted]
  - strken 7y ago
    This is misleading and parts of it aren't true. Comparing GraphQL to REST is apples to oranges and misses most of the advantages. GraphQL is a way to dynamically generate API endpoints[0] from A) a schema describing a graph, B) a query describing the endpoint, and C) functions which fetch objects from the graph defined in A. Why would this be useful? Can't you just write endpoints or use a single RESTful endpoint per model? Well, on some large projects, you have a very large number of endpoints supporting a slightly different set of views that are all based on the same data, and most of those endpoints load more data than they need. GraphQL allows you to replace an entire suite of presentation layers with a declarative schema that's smaller and more easily reasoned about, and which only loads what you actually need. You also get some other things for free - n+1 queries happen within the data centre and are therefore faster, you can avoid opening a lot of HTTP1 connections, etc. - but these things are only side benefits. The core benefit is making your big procedural presentation layer smaller and more declarative. [0] This is not strictly true, a GraphQL query isn't an endpoint, but for me they occupy the same conceptual space.
    - deckard1 7y ago
      > Comparing GraphQL to REST is apples to oranges Just because you say that, doesn't make it true. > most of those endpoints load more data than they need GraphQL proponents seem to forget query parameters exist. It has never been the case that REST has to return more than you need. Never. Not now, not ten years ago. Why people keep repeating this obviously false claim is bizarre. The hoops you have to jump through to get GraphQL efficient as off-the-shelf REST are rather insane. Caching, both client and server side, have to be entirely reinvented. What Apollo does may be open source but it's also proprietary. And at this point, a single corporation controls the entire stack. Without Apollo, GraphQL is a terrible joke.
      - strken 7y ago
        > GraphQL proponents seem to forget query parameters exist. It has never been the case that REST has to return more than you need. Never. Not now, not ten years ago. Why people keep repeating this obviously false claim is bizarre. You need to use something that does the same thing as GraphQL, e.g. allows you to define a graph of relationships and then query them, and can have many of the same tradeoffs, e.g. not being cacheable or not allowing you to stream the result. If you like the other thing better than GraphQL (I've used https://jsonapi.org/ https://jsonapi.org/ and https://loopback.io/ https://loopback.io/, among others), by all means use it. This is what I mean when I say comparing GraphQL to REST is apples to oranges. REST is general and broad and GraphQL is narrow and specific, so the comparison isn't meaningful unless we start talking about specific libraries, frameworks, specs, or patterns that use REST to do the same thing GraphQL does.
        digitaltrees 7y ago
        Check out Graphiti.dev it shows how a few common sense conventions in REST give most or all the power of GraphQL. I think the phrase “comparing apples to oranges” is a bit misleading in this context because it is normally used to imply that such comparison is impossible or not useful (i.e. a fruitless exercise, sorry, I couldn’t help it). But here there is a lot to compare. REST is built with the basic infrastructure of the web in mind so massive amounts of infrastructure like caching, error messaging do need to be rebuilt. GraphQL has some real benefits so a comprehensive comparison is worth it. Ultimately both are an api design to facilitate getting data. It’s sort of like comparing Postgres to MongoDB. Yes there are major differences but the expected use is to store data. Comparing is crucial. Either way. Have fun building cool stuff.
- rojobuffalo 7y ago
  Prisma provides a really solid approach for a GraphQL project. https://www.prisma.io/features/graphql-api/ https://www.prisma.io/features/graphql-api/ . Graphile(https://www.graphile.org/ https://www.graphile.org/) is another really nice library for a more advanced approach. IMO the big pay-off of a GraphQL service is the clarity of how the frontend describes data dependencies. To capture that full benefit, you've gotta go with Relay. Facebook designed Relay and GraphQL in tandem to work nicely together. Apollo and Redux are mediocre, but people argue they have a "more approachable learning curve".
- sgrove 7y ago
  One example that's fun is being able to bring in the data to e.g. Excel - here's an example of a proof of concept we did to give an idea of what's possible with GraphQL https://youtu.be/IHPaDvXQWyA https://youtu.be/IHPaDvXQWyA Building that kind of tooling ad-hoc is going to be so difficult. I suspect that GraphQL is just in the early days of building this tooling, and everyone will be able to re-use it without additional work on their own part. (it's also in the linked talk at 33m22)
nailer 7y ago
As a JS/TypeScript dev: just give me typing, DB schema, and an API in one place. Currently we have TypeORM, which does typing and DB schema but requires you to make a separate API. And we have Prisma, which is a DB schema and API, but still requires you to maintain types.
- hjanssen 7y ago
  The successor of Prisma, Prisma2 [0] does aim to solve the typing issue. It generates a fully typed JS/TS client that you can then use e.g. with autocompletion in VS Code. It is currently in preview, but they aim to release the first "stable" version in Q1 of this year, so pretty soon. You can check the current status at [1]. However, you can try it out right now by installing the preview version via npm. I am currently playing around with it and although it has some rough edges in corner cases, for 99% of my use cases it was a breeze to work with. Particulary the integration with nexus via the nexus-prisma plugin [2] is plain awesome, i have never had a fully functional graphql endpoint standing in a timeframe of 1 hour. I am using it in conjunction with NextJS and the resulting developer experience is great, i cant recommend enough to try it out (I am not affiliated with prisma labs, just a happy user) [0] https://github.com/prisma/prisma2 https://github.com/prisma/prisma2 [1] https://www.notion.so/Is-Prisma-2-Ready-8b3fba3eaf5b4bf3ab7102fd94f56148 https://www.notion.so/Is-Prisma-2-Ready-8b3fba3eaf5b4bf3ab71... [2] https://github.com/graphql-nexus/nexus-prisma https://github.com/graphql-nexus/nexus-prisma
  - nikolasburk 7y ago
    Nikolas from the Prisma team here, thanks a lot for the shoutout! For people who want to learn more about using Prisma together with Nexus (which enables exposing DB models via GraphQL), I also recommend checking the next iteration of Nexus that we're currently working on (which will turn into a fully-fledged GraphQL application framework with TypeScript as a first-class citizen): https://nexus-future.now.sh/#/ https://nexus-future.now.sh/#/ Let me know if you have any questions!
- protonimitate 7y ago
  Curious, what do you do to maintain types? You can hack together a script or client to pull graphql schema from an endpoint and generate types using Apollos code gen (similar to [0]). [0] - https://medium.com/open-graphql/automatically-generate-typescript-definitions-for-graphql-queries-with-apollo-codegen-e73eae72b561 https://medium.com/open-graphql/automatically-generate-types...
dominotw 7y ago
when i make a graphql request in chrome request is an unformatted string. Is there an extension someone would recommend that would make it easy to spot server interactions in a formatted way.
- striking 7y ago
  https://chrome.google.com/webstore/detail/graphql-network/igbmhmnkobkjalekgiehijefpkdemocm https://chrome.google.com/webstore/detail/graphql-network/ig...
swyx 7y ago
great talk! :)

115 points by sgrove 7y ago

We are in the process of debating ODATA Api vs GraphQL for data analytics. Anyone with extensive experience can share some light/guide us.

_92eu 7y ago
With HTTP2, it's now almost always better to go with a RESTful API, especially if you need to do heavy calculations and display dashboards with a lot of data. You will be able to fine tune your cache settings and monitor the performance of your endpoints (https://medium.com/@__xuorig__/why-graphql-performance-monitoring-is-hard-41381bc7c44d https://medium.com/@__xuorig__/why-graphql-performance-monit...) You will be able to fetch resources in parallel and start displaying data faster (GraphQL Apollo is also able to do some king of streaming, but it relies heavily on non-standard network hacks). You will be able to use Vulcain (https://vulcain.rocks/ https://vulcain.rocks/) which will allow you to fetch your whole resource graph at once using HTTP2 Server Push. The only reason you may choose GraphQL is if you need to go fast and want to profit from the DX of the awesome React libraries available such as Relay or Apollo.
- deleted 7y ago
  [deleted]
- strken 7y ago
  This is misleading and parts of it aren't true. Comparing GraphQL to REST is apples to oranges and misses most of the advantages. GraphQL is a way to dynamically generate API endpoints[0] from A) a schema describing a graph, B) a query describing the endpoint, and C) functions which fetch objects from the graph defined in A. Why would this be useful? Can't you just write endpoints or use a single RESTful endpoint per model? Well, on some large projects, you have a very large number of endpoints supporting a slightly different set of views that are all based on the same data, and most of those endpoints load more data than they need. GraphQL allows you to replace an entire suite of presentation layers with a declarative schema that's smaller and more easily reasoned about, and which only loads what you actually need. You also get some other things for free - n+1 queries happen within the data centre and are therefore faster, you can avoid opening a lot of HTTP1 connections, etc. - but these things are only side benefits. The core benefit is making your big procedural presentation layer smaller and more declarative. [0] This is not strictly true, a GraphQL query isn't an endpoint, but for me they occupy the same conceptual space.
  - deckard1 7y ago
    > Comparing GraphQL to REST is apples to oranges Just because you say that, doesn't make it true. > most of those endpoints load more data than they need GraphQL proponents seem to forget query parameters exist. It has never been the case that REST has to return more than you need. Never. Not now, not ten years ago. Why people keep repeating this obviously false claim is bizarre. The hoops you have to jump through to get GraphQL efficient as off-the-shelf REST are rather insane. Caching, both client and server side, have to be entirely reinvented. What Apollo does may be open source but it's also proprietary. And at this point, a single corporation controls the entire stack. Without Apollo, GraphQL is a terrible joke.
    - strken 7y ago
      > GraphQL proponents seem to forget query parameters exist. It has never been the case that REST has to return more than you need. Never. Not now, not ten years ago. Why people keep repeating this obviously false claim is bizarre. You need to use something that does the same thing as GraphQL, e.g. allows you to define a graph of relationships and then query them, and can have many of the same tradeoffs, e.g. not being cacheable or not allowing you to stream the result. If you like the other thing better than GraphQL (I've used https://jsonapi.org/ https://jsonapi.org/ and https://loopback.io/ https://loopback.io/, among others), by all means use it. This is what I mean when I say comparing GraphQL to REST is apples to oranges. REST is general and broad and GraphQL is narrow and specific, so the comparison isn't meaningful unless we start talking about specific libraries, frameworks, specs, or patterns that use REST to do the same thing GraphQL does.
      - digitaltrees 7y ago
        Check out Graphiti.dev it shows how a few common sense conventions in REST give most or all the power of GraphQL. I think the phrase “comparing apples to oranges” is a bit misleading in this context because it is normally used to imply that such comparison is impossible or not useful (i.e. a fruitless exercise, sorry, I couldn’t help it). But here there is a lot to compare. REST is built with the basic infrastructure of the web in mind so massive amounts of infrastructure like caching, error messaging do need to be rebuilt. GraphQL has some real benefits so a comprehensive comparison is worth it. Ultimately both are an api design to facilitate getting data. It’s sort of like comparing Postgres to MongoDB. Yes there are major differences but the expected use is to store data. Comparing is crucial. Either way. Have fun building cool stuff.
rojobuffalo 7y ago
Prisma provides a really solid approach for a GraphQL project. https://www.prisma.io/features/graphql-api/ https://www.prisma.io/features/graphql-api/ . Graphile(https://www.graphile.org/ https://www.graphile.org/) is another really nice library for a more advanced approach. IMO the big pay-off of a GraphQL service is the clarity of how the frontend describes data dependencies. To capture that full benefit, you've gotta go with Relay. Facebook designed Relay and GraphQL in tandem to work nicely together. Apollo and Redux are mediocre, but people argue they have a "more approachable learning curve".
sgrove 7y ago
One example that's fun is being able to bring in the data to e.g. Excel - here's an example of a proof of concept we did to give an idea of what's possible with GraphQL https://youtu.be/IHPaDvXQWyA https://youtu.be/IHPaDvXQWyA Building that kind of tooling ad-hoc is going to be so difficult. I suspect that GraphQL is just in the early days of building this tooling, and everyone will be able to re-use it without additional work on their own part. (it's also in the linked talk at 33m22)

nailer 7y ago

As a JS/TypeScript dev: just give me typing, DB schema, and an API in one place. Currently we have TypeORM, which does typing and DB schema but requires you to make a separate API. And we have Prisma, which is a DB schema and API, but still requires you to maintain types.

hjanssen 7y ago
The successor of Prisma, Prisma2 [0] does aim to solve the typing issue. It generates a fully typed JS/TS client that you can then use e.g. with autocompletion in VS Code. It is currently in preview, but they aim to release the first "stable" version in Q1 of this year, so pretty soon. You can check the current status at [1]. However, you can try it out right now by installing the preview version via npm. I am currently playing around with it and although it has some rough edges in corner cases, for 99% of my use cases it was a breeze to work with. Particulary the integration with nexus via the nexus-prisma plugin [2] is plain awesome, i have never had a fully functional graphql endpoint standing in a timeframe of 1 hour. I am using it in conjunction with NextJS and the resulting developer experience is great, i cant recommend enough to try it out (I am not affiliated with prisma labs, just a happy user) [0] https://github.com/prisma/prisma2 https://github.com/prisma/prisma2 [1] https://www.notion.so/Is-Prisma-2-Ready-8b3fba3eaf5b4bf3ab7102fd94f56148 https://www.notion.so/Is-Prisma-2-Ready-8b3fba3eaf5b4bf3ab71... [2] https://github.com/graphql-nexus/nexus-prisma https://github.com/graphql-nexus/nexus-prisma
- nikolasburk 7y ago
  Nikolas from the Prisma team here, thanks a lot for the shoutout! For people who want to learn more about using Prisma together with Nexus (which enables exposing DB models via GraphQL), I also recommend checking the next iteration of Nexus that we're currently working on (which will turn into a fully-fledged GraphQL application framework with TypeScript as a first-class citizen): https://nexus-future.now.sh/#/ https://nexus-future.now.sh/#/ Let me know if you have any questions!
protonimitate 7y ago
Curious, what do you do to maintain types? You can hack together a script or client to pull graphql schema from an endpoint and generate types using Apollos code gen (similar to [0]). [0] - https://medium.com/open-graphql/automatically-generate-typescript-definitions-for-graphql-queries-with-apollo-codegen-e73eae72b561 https://medium.com/open-graphql/automatically-generate-types...

dominotw 7y ago

when i make a graphql request in chrome request is an unformatted string. Is there an extension someone would recommend that would make it easy to spot server interactions in a formatted way.

striking 7y ago
https://chrome.google.com/webstore/detail/graphql-network/igbmhmnkobkjalekgiehijefpkdemocm https://chrome.google.com/webstore/detail/graphql-network/ig...

swyx 7y ago

great talk! :)