I'm a big fan of React but it took me a year after its introduction for me to get it and like it. What particularly did the trick for me was one of Pete Hunt's talks he gave a year after release acknowledging the confusion and explaining the reasoning for React rather than just the technology itself.<p>I feel like GraphQL can be something great and the pain points they identify with typical APIs are stuff I've felt but GraphQL just feels incomplete to me. I feel they're focusing too much on what GraphQL looks like on the client-side and not enough what it looks like on the server-side. The biggest question I have is what's going to process the GraphQL query on the server to fetch the data from the actual datastore? What does that look like when working with typical datastore such as a SQL-based database? The closest thing I've seen that answered that question was this blog post[0] which doesn't look very appealing if that's what the server-side implementation is going to look like. The blog post's implementation looks like a more complicated version of my own APIs which are usually a series of custom endpoints based on my client's needs. I don't see the big deal right now. Maybe next year...<p>[0] <a href="https://medium.com/@clayallsopp/your-first-graphql-server-3c766ab4f0a2" rel="nofollow">https://medium.com/@clayallsopp/your-first-graphql-server-3c...</a>
Details about the backend are often vague or missing in every article that covers GraphQL that I've read so far.<p>Where are guidelines to implement it?
How do we make our existing business code integrate with it?
How do we make sure a client cannot access data from another client?
Does it work well or at all with relational databases?<p>Is the backend a second-class citizen in this approach?
This does not explain how the client-side cache is kept up-to-date. Cache invalidation matters. You want instantaneous updates on the client if the data has been updated on the server.
E.g. What if the like count has been updated?<p>Curious what solutions GraphQL offers for this. If it doesn't solve this itself, then what do GraphQL apps do today to solve this?
We're building a single page app with all the rendering done on the client(clichéd, yeah) and a RESTish Dropwizard API server<p>We have a page which requires integrating data from 12 different REST APIs. Making 12 HTTP requests takes a lot of time. So the obvious solution is to merge the APIs on the server and make a 'business' API specific to that page.<p>But we did not want to repeat all the merging logic on the server during launch.<p>To alleviate the problem, I created a dependency graph/DAG for all the 12 APIs and fired HTTP requests concurrently at each level instead of using 12 promises which increased performance significantly.<p>Does GraphQL support such use-cases?
All the examples I've seen so far have a "hardcoded" schema expressed in code. Besides code generation, is there some way to express a schema in another format?<p>Is anyone working on a way to define dynamic schemas? For example, a user defined schema rather than a developer defined schema.<p>What I'd really like to see is a tool/library/framework to create a graphQL schema, store it in a database along with the data, and efficiently query the whole assembly. I'm thinking of something like Semantic Mediawiki that isn't terribad. :)
I'm writing a series on learning GraphQL here, if anybody is interested:<p><a href="https://github.com/mugli/learning-graphql" rel="nofollow">https://github.com/mugli/learning-graphql</a>
Too invasive. GraphQL actually needs to be implemented on the server, which is a no go for me. The client should not dictate what the server api should look like. I understand it works for Facebook and it's fine, however this thing is so hyped right now developers are jumping into this and promoting this without actually talking about the drawbacks of this tech. And POST requests everywhere? excuse me but it throws away any "natural" http caching.<p>To me it is another example of something that may benefit a project that has 500 million daily users , that is useless for 99% of projects out there, yet is advertised as a silver bullet that will make a poorly optimized app magically scale.