4 ms·

Without doubt, GraphQL is the next technologo I will learn. The idea is so brillant compared to REST. If you are convinced by SQL and in general by Domain Speci

Without doubt, GraphQL is the next technologo I will learn. The idea is so brillant compared to REST. If you are convinced by SQL and in general by Domain Specific Languages, I think you should give GraphQL a try.

tostitos1979 9y ago
I'm intrigued ... can you elaborate on the wow factor beyond REST that you see in GraphQL? When I looked at it in the past, it seems to make sense for things that could be represented by graph (e.g. FB's social graph), and graphql allowed you to run complex operations in the backend without fetching each individual node on the client. I clearly missed something?
- lolive 9y ago
  And if you can also elaborate on why SPARQL and RDF were a major failure, and how GraphQL is different/better?
  - amirouche 9y ago
    > it seems to make sense for things that could be represented by graph False, even if there is graph in its name it's not restricted to graph, and that what is great about it compared to things like RDF and SPARQL. Backend data can be stored in key/value store, document, files, RDBMS or whatever. And you will still be able to make it work. AFAIK you write a "translation" layer that interprets a pseudo-JSON file into your data. AFAIK GraphQL is not good at querying recursive datastructure, it's better at "neighborhood" kind of query, so you can traverse Foreign Keys, but not "indefinitely". > graphql allowed you to run complex operations in the backend without fetching each individual node on the client. Yes. > I clearly missed something? IDK. For me, GraphQL basically it's an RPC interface particularly suited at "reading" data. > And if you can also elaborate on why SPARQL and RDF were a major failure, and how GraphQL is different/better? GraphQL is not tied to particular data layout. I don't know much of SPARQL and RDF actually and don't know why they failed. I am just guessing. That said, GraphQL it "just" another query language, it's "just" another DSL targeted at querying datastructures. As something that was thought a long time, focused to solve a particular issue.
    - scottmf 9y ago
      > AFAIK GraphQL is not good at querying recursive datastructure, it's better at "neighborhood" kind of query, so you can traverse Foreign Keys, but not "indefinitely". That isn't true. You can request data in any shape you want and could theoretically traverse through child nodes indefinitely. We have many queries which go 5-6 levels deep.
      - lolive 9y ago
        How do you deal with IDs misalignment between data sources?
        scottmf 9y ago
        Could you clarify what you mean? Got an example?
        lolive 9y ago
        Let's say you want to query Wikipedia for village descriptions, and get a map of matched villages from openstreetmap. Would it be a use case where GraphQL could help? Then it would need a "translation" layer for both systems. And joins between datasets would be based (for example) on the couple "country+postalCode". Is it a possible use case of GraphQL?
        scottmf 9y ago
        Could you show me a quick example of what a request and response would look like with REST? I'm still not quite sure what you mean.
    - lolive 9y ago
      Ok. And the join strategy (i.e IDs alignment) between data sources is defined (declaratively? Programmatically?) in the "translation" layer. Sounds very interesting. I still think the URIs of the semantic web are a better idea, but given the fact that nobody (re)uses them, then why not a "translation" layer.
- arstin 9y ago
  This frontend code. const ProfileImage = ({ user }) => <img src={user.avatarUrl} alt={user.name} />; const query = gql`{ user(id: 3) { name avatarUrl } }` export const ProfileImageWithData = graphql(query)(ProfileImage); You can ask for data in the structure the UI expects and only get exactly that data, letting the GQL client handle batching network requests for needs distributed across the whole app, caching, UI updating, etc under the hood. Also does a great job of decoupling product and data management code.
X86BSD 9y ago
I'm encouraged to hear your opinion on it. A friend of mine who turned me on to elixir is a fan of GraphQL as well. So you have pushed me to spend the day reading up on it and experimenting with it. Thank you.
transcranial 9y ago
GraphQL has been a breath of fresh air -- you can tell a lot of thought went into its design and implementation.
krono 9y ago
Great resource for anyone wanting to learn more: https://www.howtographql.com/ https://www.howtographql.com/
thisisforyou 9y ago
I built a GraphQL API earlier this year. The learning curve can be a little awkward coming from REST, but once you get the hang of it GraphQL is super fun. Can't recommend it enough. Enjoy!
sp527 9y ago
By what factor does using GraphQL accelerate development time?
- FullMtlAlcoholc 9y ago
  I couldn't put a number on it, but it greatly accelerates development on the front-end. The API call gets you back all the data you need, only the data you need, in the format or structure that you need. If there were GraphQL for Spotify's API and you wanted an artist's discography, you don't have to make multiple calls to endpoints and work through huge objects where 90-95% of the data is not needed. For the front-end, it's a no-brainer. I've read that it is a bit more involved on the server-side but Apollo seems to be making great tooling for it.
- BatFastard 9y ago
  4.3875321
zimablue 9y ago
I was really not sold by GraphQL, I'm totally down to not use REST as I think that's daft but GraphQL seems to be less powerful than SQL and only really useful if the thing you're querying really is a graph, and not lots of rows of relational data. I do work with data all the time so it's not actually that useful, I wish someone would invent something similar but with a more logical foundation (joins and aggregations and stuff, not only through ugly plugins). Maybe like datalog although I never learned that enough to find the payoffs.
- sixdimensional 9y ago
  Personally, I believe that someone needs to build some kind of a scalable, security-hardened SQL interface that can be queried directly from the browser using actual SQL. Part of that need involves federated data from multiple services/data sources. We already have a query language that can even handle nested values (see ISO SQL:2016 standard), why not just adapt it for use in the browser?
  - zimablue 9y ago
    I don't really like SQL either, it's hard to generate and doesn't support any abstractions, it might be an OK target format for some amazing query generator.
scottmf 9y ago
I'm genuinely surprised by the number of people on HN who seem to know very little about what has been safe to call the successor to REST for quite some time. Forgive me if this sounds hyperbolic, but unless you have unusual or strict requirements, building a new app in 2017 REST-first is most likely a terrible mistake. Let me clear up some misconceptions I see in almost every HN comment thread on GraphQL: 1. GraphQL isn't more suited to Graph databases. Your data sources can be a mix of relational DB, NoSQL, key value, a REST API, or anything else. 2. n+1 has always been a solved problem in GraphQL thanks to DataLoader[1], a query batching utility which coalesces calls to your data sources from different parts of your app, specifically to avoid n+1. 3. It's unquestionably production-ready, battle-tested, has a real spec and official reference implementation, and it's probably the safest bet you can make at this moment in an industry as fickle as this. With GraphQL you simply write your schema, define types and relationships, and you’re then able to request data in almost any shape you wish, with very little extra work. This is invaluable during development. If you have a list of recent comments with author names, and later decide to show an avatar alongside the name, you don’t need to write any extra code on the server. You add an extra line to your query (or component’s fragment) on the client. The same goes for any field, any relationship, no matter how complex the resulting shape. If you wanted a comment author’s follower’s comments’ likeCounts, you still don’t need to write another line of server code. This makes it stupidly simple to rapidly prototype new features, try out new layouts, and means you can share a single API endpoint between mobile apps and desktop site without sending useless data to one or both. There have been many occasions when we simply wouldn't have had the time to implement a feature correctly with REST, particularly when we might not even know what data we'll want until we begin developing the feature and get a feel for how it works. It doesn't just save server dev time either. On the client side there are libraries like Apollo[2] and Relay which take care of fetching data, caching, normalization, and you should almost certainly use one (I recommend Apollo) unless you have a good reason not to. Writing fetch calls and managing your store manually is just going to be a huge waste of time. And the spec is more than queries and mutations. It's subscriptions, live queries, and more [3]. Real-time data is a first-class citizen of GraphQL, and the two most popular front-end libraries have official implementations of subscriptions (with live queries in progress). GraphQL is elegant, has a well-designed official spec, great DX and just plain makes sense. But it's really something you need to try out for yourself (preferably on a real project) to see just how great it is. If you’re planning to build something new with REST, seriously, reconsider. There's a slightly higher upfront cost to using GraphQL (particularly if you're new to it), but once you settle into it you'll be glad you did. Useful tools and resources: - GraphiQL[4] - an incredibly useful tool for running queries on your GraphQL API - Graph.cool[5] - BaaS for quickly prototyping a GraphQL API - Apollo Launchpad[6] - Try out GraphQL server code in your browser [1] https://github.com/facebook/dataloader https://github.com/facebook/dataloader [2] https://github.com/apollographql/apollo-client https://github.com/apollographql/apollo-client [3] https://dev-blog.apollodata.com/new-features-in-graphql-batch-defer-stream-live-and-subscribe-7585d0c28b07 https://dev-blog.apollodata.com/new-features-in-graphql-batc... [4] https://github.com/graphql/graphiql https://github.com/graphql/graphiql [5] https://www.graph.cool https://www.graph.cool [6] http://launchpad.graphql.com http://launchpad.graphql.com

tostitos1979 9y ago

I'm intrigued ... can you elaborate on the wow factor beyond REST that you see in GraphQL? When I looked at it in the past, it seems to make sense for things that could be represented by graph (e.g. FB's social graph), and graphql allowed you to run complex operations in the backend without fetching each individual node on the client. I clearly missed something?

lolive 9y ago
And if you can also elaborate on why SPARQL and RDF were a major failure, and how GraphQL is different/better?
- amirouche 9y ago
  > it seems to make sense for things that could be represented by graph False, even if there is graph in its name it's not restricted to graph, and that what is great about it compared to things like RDF and SPARQL. Backend data can be stored in key/value store, document, files, RDBMS or whatever. And you will still be able to make it work. AFAIK you write a "translation" layer that interprets a pseudo-JSON file into your data. AFAIK GraphQL is not good at querying recursive datastructure, it's better at "neighborhood" kind of query, so you can traverse Foreign Keys, but not "indefinitely". > graphql allowed you to run complex operations in the backend without fetching each individual node on the client. Yes. > I clearly missed something? IDK. For me, GraphQL basically it's an RPC interface particularly suited at "reading" data. > And if you can also elaborate on why SPARQL and RDF were a major failure, and how GraphQL is different/better? GraphQL is not tied to particular data layout. I don't know much of SPARQL and RDF actually and don't know why they failed. I am just guessing. That said, GraphQL it "just" another query language, it's "just" another DSL targeted at querying datastructures. As something that was thought a long time, focused to solve a particular issue.
  - scottmf 9y ago
    > AFAIK GraphQL is not good at querying recursive datastructure, it's better at "neighborhood" kind of query, so you can traverse Foreign Keys, but not "indefinitely". That isn't true. You can request data in any shape you want and could theoretically traverse through child nodes indefinitely. We have many queries which go 5-6 levels deep.
    - lolive 9y ago
      How do you deal with IDs misalignment between data sources?
      - scottmf 9y ago
        Could you clarify what you mean? Got an example?
        lolive 9y ago
        Let's say you want to query Wikipedia for village descriptions, and get a map of matched villages from openstreetmap. Would it be a use case where GraphQL could help? Then it would need a "translation" layer for both systems. And joins between datasets would be based (for example) on the couple "country+postalCode". Is it a possible use case of GraphQL?
        scottmf 9y ago
        Could you show me a quick example of what a request and response would look like with REST? I'm still not quite sure what you mean.
  - lolive 9y ago
    Ok. And the join strategy (i.e IDs alignment) between data sources is defined (declaratively? Programmatically?) in the "translation" layer. Sounds very interesting. I still think the URIs of the semantic web are a better idea, but given the fact that nobody (re)uses them, then why not a "translation" layer.
arstin 9y ago
This frontend code. const ProfileImage = ({ user }) => <img src={user.avatarUrl} alt={user.name} />; const query = gql`{ user(id: 3) { name avatarUrl } }` export const ProfileImageWithData = graphql(query)(ProfileImage); You can ask for data in the structure the UI expects and only get exactly that data, letting the GQL client handle batching network requests for needs distributed across the whole app, caching, UI updating, etc under the hood. Also does a great job of decoupling product and data management code.

X86BSD 9y ago

I'm encouraged to hear your opinion on it. A friend of mine who turned me on to elixir is a fan of GraphQL as well. So you have pushed me to spend the day reading up on it and experimenting with it. Thank you.

transcranial 9y ago

GraphQL has been a breath of fresh air -- you can tell a lot of thought went into its design and implementation.

krono 9y ago

Great resource for anyone wanting to learn more: https://www.howtographql.com/ https://www.howtographql.com/

thisisforyou 9y ago

I built a GraphQL API earlier this year. The learning curve can be a little awkward coming from REST, but once you get the hang of it GraphQL is super fun. Can't recommend it enough. Enjoy!

sp527 9y ago

By what factor does using GraphQL accelerate development time?

FullMtlAlcoholc 9y ago
I couldn't put a number on it, but it greatly accelerates development on the front-end. The API call gets you back all the data you need, only the data you need, in the format or structure that you need. If there were GraphQL for Spotify's API and you wanted an artist's discography, you don't have to make multiple calls to endpoints and work through huge objects where 90-95% of the data is not needed. For the front-end, it's a no-brainer. I've read that it is a bit more involved on the server-side but Apollo seems to be making great tooling for it.
BatFastard 9y ago
4.3875321

zimablue 9y ago

I was really not sold by GraphQL, I'm totally down to not use REST as I think that's daft but GraphQL seems to be less powerful than SQL and only really useful if the thing you're querying really is a graph, and not lots of rows of relational data. I do work with data all the time so it's not actually that useful, I wish someone would invent something similar but with a more logical foundation (joins and aggregations and stuff, not only through ugly plugins). Maybe like datalog although I never learned that enough to find the payoffs.

sixdimensional 9y ago
Personally, I believe that someone needs to build some kind of a scalable, security-hardened SQL interface that can be queried directly from the browser using actual SQL. Part of that need involves federated data from multiple services/data sources. We already have a query language that can even handle nested values (see ISO SQL:2016 standard), why not just adapt it for use in the browser?
- zimablue 9y ago
  I don't really like SQL either, it's hard to generate and doesn't support any abstractions, it might be an OK target format for some amazing query generator.

scottmf 9y ago

I'm genuinely surprised by the number of people on HN who seem to know very little about what has been safe to call the successor to REST for quite some time. Forgive me if this sounds hyperbolic, but unless you have unusual or strict requirements, building a new app in 2017 REST-first is most likely a terrible mistake. Let me clear up some misconceptions I see in almost every HN comment thread on GraphQL: 1. GraphQL isn't more suited to Graph databases. Your data sources can be a mix of relational DB, NoSQL, key value, a REST API, or anything else. 2. n+1 has always been a solved problem in GraphQL thanks to DataLoader[1], a query batching utility which coalesces calls to your data sources from different parts of your app, specifically to avoid n+1. 3. It's unquestionably production-ready, battle-tested, has a real spec and official reference implementation, and it's probably the safest bet you can make at this moment in an industry as fickle as this. With GraphQL you simply write your schema, define types and relationships, and you’re then able to request data in almost any shape you wish, with very little extra work. This is invaluable during development. If you have a list of recent comments with author names, and later decide to show an avatar alongside the name, you don’t need to write any extra code on the server. You add an extra line to your query (or component’s fragment) on the client. The same goes for any field, any relationship, no matter how complex the resulting shape. If you wanted a comment author’s follower’s comments’ likeCounts, you still don’t need to write another line of server code. This makes it stupidly simple to rapidly prototype new features, try out new layouts, and means you can share a single API endpoint between mobile apps and desktop site without sending useless data to one or both. There have been many occasions when we simply wouldn't have had the time to implement a feature correctly with REST, particularly when we might not even know what data we'll want until we begin developing the feature and get a feel for how it works. It doesn't just save server dev time either. On the client side there are libraries like Apollo[2] and Relay which take care of fetching data, caching, normalization, and you should almost certainly use one (I recommend Apollo) unless you have a good reason not to. Writing fetch calls and managing your store manually is just going to be a huge waste of time. And the spec is more than queries and mutations. It's subscriptions, live queries, and more [3]. Real-time data is a first-class citizen of GraphQL, and the two most popular front-end libraries have official implementations of subscriptions (with live queries in progress). GraphQL is elegant, has a well-designed official spec, great DX and just plain makes sense. But it's really something you need to try out for yourself (preferably on a real project) to see just how great it is. If you’re planning to build something new with REST, seriously, reconsider. There's a slightly higher upfront cost to using GraphQL (particularly if you're new to it), but once you settle into it you'll be glad you did. Useful tools and resources: - GraphiQL[4] - an incredibly useful tool for running queries on your GraphQL API - Graph.cool[5] - BaaS for quickly prototyping a GraphQL API - Apollo Launchpad[6] - Try out GraphQL server code in your browser [1] https://github.com/facebook/dataloader https://github.com/facebook/dataloader [2] https://github.com/apollographql/apollo-client https://github.com/apollographql/apollo-client [3] https://dev-blog.apollodata.com/new-features-in-graphql-batch-defer-stream-live-and-subscribe-7585d0c28b07 https://dev-blog.apollodata.com/new-features-in-graphql-batc... [4] https://github.com/graphql/graphiql https://github.com/graphql/graphiql [5] https://www.graph.cool https://www.graph.cool [6] http://launchpad.graphql.com http://launchpad.graphql.com