21–30 of 47 posts
I love the ability to browse introspection via playground most of all.
My two annoyances right now are: lack of input unions and lack of recursive fetching for tree/node based resources
This looks like an effort to bring to REST APIs some of the benefits GraphQL offers, mainly by adding extensive conventions on top of traditional HTTP endpoints. Comes with an implementation in Ruby. The idea has some merit. That said, I am not sure I have spotted the discoverability features equivalent to what’s possible in GraphQL world with a GraphiQL console.
I must admit the main thing that puts me off GraphQL is that it's not built on JSON. Maybe that's silly, but it just seems like a move away from what we know and love. Also the graphql tools seem to be based around the idea of a fixd schema, and I'm looking for something a little more flexible.
I for one do not like json, the only formats I can think of that I like less are xml and yaml. I'd prefer a protocol with a binary implementation, it must support comments, I like type annotations, and a schema language would be great.
I've been working with Amazon's ion lately and I've enjoyed it. It has text and binary representations, fields have types (in binary), it can be represented as json (you lose annotations)
Earlier quoted context omitted.
it is unlikely that all the data sources you will be querying now are directly available in an SQL database.
For sure they are not available in a /rest or GraphQL engine neither. SQL should be only the syntax used to communicate with the backend, the real implementation would be in whatever make sense.
Earlier quoted context omitted.
I must admit the main thing that puts me off GraphQL is that it's not built on JSON. Maybe that's silly, but it just seems like a move away from what we know and love. Also the graphql tools seem to be based around the idea of a fixd schema, and I'm looking for something a little more flexible.
> move away from what we know and love I didn't get the memo where we decided that we love JSON.
Earlier quoted context omitted.
For sure they are not available in a /rest or GraphQL engine neither. SQL should be only the syntax used to communicate with the backend, the real implementation would be in whatever make sense.
That would require you to map the SQL to something else which would then map back to SQL or mongo or w/e. For example if you're trying to join data from multiple microservices you can't execute the join because most microservices setups are not going to allow joins. The joins would have to be mapped to service to service calls and at this point you're just rebuilding an orchestration layer which has already been solv…
Sorry but I don't buy this reason. Especially not to the question: "Why we don't use SQL as a query language?" especially because REST was around way earlier than GraphQL.
Your reasoning could be great to answer the question: "Why we like GraphQL where there are a lot of microservices?"
BTW, there is nothing inherent in the language in itself, if each microservices would be speaking SQL, you would simply need to optmize your SQL query, decompose your optimized SQL query creating simpler queries one for each microservice, send each of those queries to the relative microservices, compute back the final result.
If you replace "microservices" with "table" here you get the standard way an SQL engine works :)
Please, it is not that I am against GraphQL, but it honestly seems like some engineer at facebook was annoyed by SQL, and decide to re-invent it. And that we are all following him or she just because they worked at facebook, which seems unwise.
Maybe the use of types? But what is the difference between a type and something that belong to a table?
Anyway, I am looking now at [GraphQL: The Documentary (Official Release)][1]
[1]: https://www.youtube.com/watch?v=783ccP__No8&feature=youtu.be
Without remarking on the substance of this post, I just wanted to say I enjoyed the writing style and the design of this post tremendously. I was actually quite surprised by how much I enjoyed it haha.
Without remarking on the substance of this post, I just wanted to say I enjoyed the writing style and the design of this post tremendously. I was actually quite surprised by how much I enjoyed it haha.
On the other hand, I'm on the other side on this. I kept thinking, "get to the point, what are you trying to say?"
Earlier quoted context omitted.
That would require you to map the SQL to something else which would then map back to SQL or mongo or w/e. For example if you're trying to join data from multiple microservices you can't execute the join because most microservices setups are not going to allow joins. The joins would have to be mapped to service to service calls and at this point you're just rebuilding an orchestration layer which has already been solv…
So we invented a query language (GraphQL) to solve an orchestration problem? Sorry but I don't buy this reason. Especially not to the question: "Why we don't use SQL as a query language?" especially because REST was around way earlier than GraphQL. Your reasoning could be great to answer the question: "Why we like GraphQL where there are a lot of microservices?" BTW, there is nothing inherent in the language in itsel…
Exactly. I came here to say the same thing. This seems like an attempt to justify the existence of a thing after-the-fact. And it's a reason which isn't even the stated reason of the project itself!