In my recent article “Why not use GraphQL” (https://wundergraph.com/blog/why_not_use_graphql), I discussed a lot of the most common misconceptions about GraphQL. I keep hearing people compare the two as if they were exclusive concepts which can replace each other. Some people might have interpreted this as if I’m arguing against using GraphQL when quite the opposite is the case. I’m just not buying into the general “GraphQL solves XYZ problem and is better than REST” thing.

Instead, I’d like to give a detailed explanation of why the whole “GraphQL vs. REST” discussion doesn’t make sense. I’ll give you an in-depth view of why I believe the relationship between GraphQL and REST is much more like the one between Javascript & lower-level languages like C/C++ and Rust. Reading this will prepare you very well for discussions around choosing the right API style and implementation.

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.