Generating APIs is becoming more and more popular. Especially the GraphQL community is "suffering" from this trend. Production-ready APIs with authentication and caching in minutes, define the schema, and you're almost done. As we all know, everything comes at a cost. This post takes a critical look at generated GraphQL APIs, the benefits as well as the tradeoffs you're going to make.
I think GraphQL will change the world. There will be a future where you can query any system in the world using GraphQL. I'm building this future. So why would I argue against using GraphQL? My personal pet peeve is when the community keeps advertising benefits of GraphQL that are very generic and really have nothing to do with GraphQL. If we want to drive adoption, we should be honest and take off the rose-tinted glasses. This post is a response to "Why use GraphQL" by Kyle Schrade (https://www.apollographql.com/blog/why-use-graphql/). It’s not meant to be direct criticism. The article is just an excellent base to work with as it represents opinions I keep hearing a lot in the community. If you read the whole article, it’ll take some time, you’ll fully understand why I think Kyle’s article should be named “Why use Apollo”.
GraphQL is currently one of the most frequently mentioned technologies when it comes to innovation in the API economy. Adopters enjoy the ease of use and tooling like for example GraphiQL, the browser-based user interface to try out any GraphQL API. The whole experience of GraphQL is exactly what frontend-developers need to build amazing interactive web applications.
However, with the rise of adoption, I'm starting to get more and more concerned about the way people understand GraphQL and use it. In this post, I'd like to share my unpopular opinion on what GraphQL really is meant to be and why you should be concerned if you're using it the popular-but-risky way.
WebSockets are an outdated technology deemed dead thanks to the ietf not adding HTTP/2 support. Using Server Sent Events, we could simplify the implementation of GraphQL Subscriptions, reduce frontend code and increase performance as well as flexibility when writing modern frontend applications.
In this post we'll compare rich GraphQL clients that come with a normalized cache implementation and the generated WunderGraph clients that rely on HTTP caching.
Let us imagine that by writing a handful of GraphQL queries, it would be possible to build a fully functional React application. For a TODO app, we could allow users to login, post, retrieve, update and complete tasks. In this post, I'll explain how WunderGraph could be leveraged to achieve such a thing, and what the implications are.
Today we're happy to announce the launch of WunderGraph which also marks the beginning of the public beta.
Our vision with WunderGraph is to make developing Apps easier.
There has been a phenomenal growth in the adoption of GraphQL and accompanying tooling. As with any new technology however, we are still learning about security, best practice approaches & how to do GraphQL right. There is still debate around when it is appropriate to use GraphQL as opposed to REST or gRPC for example.
This post tells my story about why I created WunderGraph, how I believe that WunderGraph takes the best of GraphQL and REST and puts them together, in a particularly unique way, to help developers to become more productive.