discussion
Would you recommend this product?
Jon
This looks pretty cool - congrats on launching it! 🎉
As someone using GraphQL pretty heavily, I'd love to pick your brain a bit to get your opinion on a few things. Hope you don't mind, and just FYI this isn't meant to belittle the tech or anything like that - I'm genuinely trying to understand the use cases for GraphQL better since I frequently get asked about it but don't use it myself right now 😀
1. What problems do you feel it solves over say a traditional REST API endpoint? Traditionally the ones I hear are (a) limits JSON payload, (b) allows for nested resources (eg get a blog post AND its comments in a single query), (c) allows you to support multiple API clients that may need or expect different data (basically the FB use case w/ their mobile apps), and (d) frontend can be developed independently of backend because they don't have to wait on backend engineers to update API endpoints with additional data (or add new endpoints).
(a) especially makes sense if you are working with customers who have limited connectivity or have relatively low data caps (eg FB users in Africa), but I think for most of us that isn't the case. Have you seen any particularly large perf boosts coming from this in practice outside of areas like this?
(b) can be done with a traditional REST API. eg Stripe has done this for a long time - see https://stripe.com/docs/api#expa.... Are there specific situations that you find a REST API falls short and GraphQL is preferable? I'm guessing there may be some and I'm just ignorant to them.
(c) seems situational. For someone like FB where they have users who inevitably will be on various versions of iOS and Android this makes complete sense, but I suspect that most apps don't have this issue nearly as much. Are there situations outside of apps with heavy mobile usage where you see multiple API versions needing supported?
(d) has its merits, but one concern I would have is that if you let any data free by default it could lead to data leaking you weren't intending to make available in the API. Any suggestions for devs new to GraphQL to avoid issues like this?
2. Have you noticed any performance differences in terms of query time? It seems that letting users somewhat arbitrarily come up with queries could lead to some expensive queries you weren't expecting and could lead to some interesting denial of service attack vectors.
3. Are you (or anyone you know of) using GraphQL as a drop-in replacement for a customer-facing API? If so, how has that process gone? Are users generally picking it up as quickly as they do a REST API, or is that process a little trickier? I suspect more education, better tooling, and API libraries/SDKs would help on that front too.
Thanks, and again congrats on launching!
ps - sorry its so long 😱
Tanmai Gopal
Maker
@joncalhoun Very valid questions! And all of what you say is correct.
GraphQL is very nascent and implementing graphql servers is also not as easy as implementing REST-ish APIs so a thorough cost-benefit analysis is important before you use it.
Before I continue though, I'd like to mention that Hasura supports both JSON and GraphQL for querying :)
I think one of the key benefits of GraphQL that always gets missed out is the fact that GraphQL forces the backend to publish a GraphQL schema that the frontend uses. This means that there is a formal (but flexible) contract.
This means that you can validate your APIs (graphql queries) whenever you work on the frontend, and this means that you can do codegen and actually create a typed SDK for Android/iOS which means fewer errors in production and hence improved speed and quality of work.
From my point of view, this is the key benefit of graphql. The kind of querying you want to do with graphql can also be achieved with a JSON query language, but then you would not get all the tooling around graphql to do validation (for Javascript type clients) and codegen (for typed Java/Swift type clients)!
If you take a step back, gRPC also solves a similar problem. gRPC is based on top of HTTP/2 like how graphQL is based on top of HTTP. gRPC is more popular for backend because it forces API creators to publish a gRPC spec that API consumers can use to do validation/codegen easily. gRPC is more popular for chatty APIs and shifts the mental model towards function calls. Whereas graphql is more popular for data querying on the frontend and shifts the mental model towards a schema.
There is another benefit of graphql especially when used with react. It "cleans up" a lot of your react code when every UI component declaratively specifies it's data requirements as a graphql query instead of making an API call.
For war-stories I think one of the best places to chat with people is on the reactiflux discord (head to the #graphql channel)! I'm sure there will lots of folks who can give you real-world examples and quantify tangible improvements for all the points you mentioned above.
Reg. adoption I think the community is still very nascent but github moving to graphql and observing the adoption of that API will help get an answer to your third question.
Jon
@coco_d Awesome, thanks for the response!
As someone who has written code to generate SDKs (typed ones in Java even) I can totally appreciate the schema benefit but hadn't really thought about it that way. Are you aware of any tools out there that do this pretty reliable now?
And to be clear - I think both GraphQL and gRPC are great and have their place. I mostly ask these questions to improve my understanding, as I get a lot of beginner programmers reaching out (I teach Go w/ screencasts, courses, blog, etc) asking me about using GraphQL instead of a REST API, and I always want to make sure I understand both technologies before giving any advice.
It sounds like we are close to the same page - GraphQL is great, but isn't as easy to implement as a REST-ish API, so it might not be the best place for someone who has never created an API at all to start. I typically suggest building it as a boring REST API then once you understand what you are doing you can opt to build the GraphQL version without being overloaded by too much new stuff at once.
Unrelated Q - any plans to try this out on other databases like CockroachDB?
Tanmai Gopal
Maker
@joncalhoun No problem!
So on the javascript side of things there's an eslint plugin that will help you validate your graphql queries during your build process: https://github.com/apollographql...
Apollo has a lot of graphql clients and the one for Android comes with codegen too: https://github.com/apollographql...
I agree with your point. Writing a simple HTTP API with JSON is definitely the best place to start. Building a graphql backend is still something I would hesitate in recommending at this point because it's not trivial at all. A common approach is to aggregate several API calls into a graphql schema but that should be done carefully because you can't just aggregate multiple API calls into one in case the API calls have side-effects or "writes" that need failure handling. But the tooling is getting better every day and as stable patterns emerge, I'm sure developers will be able to transition from HTTP/JSON/REST to GraphQL easily.
And yes, we want to gradually extend support to other databases at Hasura. Currently, our implementation is quite tied into Postgres because we leverage some interesting performance hacks to make our GraphQL APIs "blazing fast" ;)
Do take it for a spin! I think it's a great place to just try GraphQL out. We have a built-in query explorer that helps you go from tables to graphq APIs. It would take you less than a few minutes and I'd really appreciate your thoughts on the Developer Experience given your background!
Rajoshi GhoshCo-founder, Hasura
Maker
Hi everyone!
Thank you Kevin for hunting us!
When we first started writing the data APIs, GraphQL had just come out and was pretty rough around the edges.
We love how the tooling and community around GraphQL have matured over time. Today we are very excited about announcing GraphQL support to our data APIs!
The idea is that you create tables on Postgres, define permissions and they can be automatically queried and manipulated over a GraphQL interface.
Try it out and let us know what you think!
Sungho YahngLearnObit
Can you compare this with the prisma cloud? What's different?
Tanmai Gopal
Maker
@new_user_d823b27662 I think the key differences from the user point of view are:
1. No need to write or knowledge of creating a graphql schema required
2. Row and column level access control with authorization baked in for common providers and extensible for custom auth providers
3. Highly optimised, e.g: complex GraphQL queries with nesting fetching data from across multiple tables with relationships are 1 SQL query and not the naive (n+1) queries
4. Use a UI to build your schema, get database migrations with ability to version control automatically
EDIT: forgot to add
5. Powerful query syntax for almost all query operators + and/or queries.
Riccardo Giorato
I love the speed and the power of Hasura! Building a backend is finally fast and won't require you spending weeks to create just a few endpoints.
The foundation of Hasura is also really solid thanks to the Postgres SQL database that acts as the data source component. It makes really easy to integrate other simple custom Graphql endpoints made for example with serverless functions.
Share