Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We should resist attempts to turn technology choices into religious devotions. Here's an example of a project that brings some of the most significant benefits of GraphQL to an established, mature framework for building REST APIs:

https://github.com/yezyilomo/django-restql

It's tempting to think your new paradigm/framework/whatever is so groundbreaking, so purely beneficial, that it warrants asking people to demolish everything and start over. Those kinds of breakthroughs have happened and will continue to happen, but the signal/noise ratio, especially in the world of Web Development, is incredibly low.



(Author here) Couldn't agree more on not turning technology choices into religious devotions.

It is of course completely possible for you to build a query language from grounds up. django-restql seems to be doing this. Sparse fieldsets and Netflix Falcor other alternatives I've heard of. GraphQL however has good tooling and if you do see the need for a query language on top of your APIs using it is a good choice IMO.

GraphQL does not necessarily mean you have to throw away your existing backend and rebuild from scratch either. It's perfectly fine to use GraphQL as an additional API endpoint alongside existing APIs. A model we are seeing evolve with Hasura is to use Hasura for all the reads and delegate writes via the Actions framework either to a serverless function or another HTTP service.


Thank you for writing a nuanced, non-dogmatic article, and for your thoughtful response here!

I should have clarified that I am not criticizing your article. Rather, I am criticizing some zealotry that has emerged in the community promoting GraphQL as the end-all solution.

I have been - at different times and in no particular order - ambivalent, intrigued, fascinated, and skeptical in regards to GraphQL. I need to learn more and do something hands-on with it, of course.

It seems some of the biggest benefits of GraphQL are 1) accommodating client-side needs that the server-side developers did not anticipate and 2) avoiding over-fetching and under-fetching. Is that fair?

If so, it seems many would be served well by "retrofitting" their REST API with the ability to accept dynamic field requests and respond accordingly, as is done with django-restql.

As for tooling, REST is served well in that area with things like OpenAPI and Postman, although it is not clear (to me) how well they can adapt to non-standard GraphQL-like querying capabilities "tacked on".


Vulcain ( https://github.com/dunglas/vulcain ) is another example of getting GraphQL's benefits on top of existing technology.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: