DEV Community

Cover image for How GraphQL will go extinct
Thomas Hansen
Thomas Hansen

Posted on • Originally published at

How GraphQL will go extinct

Since my opinion about GraphQL seems to have gone viral on YCombinator, Twitter, Reddit and a lot of other sites out there, I feel the need to clarify a bit. However, instead of bashing GraphQL, I want to explain what you cannot do with GraphQL in this article, and why Hyperlambda as an alternative results in higher quality software, with less security issues, becomes a bajillion times more scalable, in addition to reducing your workload as a software developer compared to GraphQL by some 3 to 5 orders of magnitudes. AKA; Explain to you how GraphQL will go extinct!

First some background information explaining my motives. GraphQL is marketed as a LowCode productivity solution. In such a regard it's a competitor of Hyperlambda. That comparison however is like comparing a steam engine from the 19th Century with a UFO from the 3rd millennium as you will soon realise. Let me start with the punchline though, and show you something I created in 5 minutes using Hyperlambda and Aista.

Things you cannot doe with GraphQL 1

The above is a screenshot of an app I created in 5 minutes, with zero coding! Below is another screenshot from the same app.

Things you cannot doe with GraphQL 2

I want to emphasise that I created the above app in 5 minutes, and I didn't have to manually create a single line of code myself at all. In fact, if you're smart enough to use Excel, WordPress or ClickUp, you're smart enough to re-create what I did. You can try a similar app here.

Meta programming

The reasons for that I can create apps such as illustrated above in 5 minutes, is because of a word few have really used the last 50 years - Yup, our "invention" is literally 50 years old. This invention is called "meta programming". Meta programming allows the machine to dynamically assemble snippets of code 100% automagically, without needing anything but configuration settings from the software developer.

With GraphQL there is no meta information available - At least not to the extent there is in Hyperlambda. This results in that you have to rely upon manually coding things.

The way Magic works, is that it reads this meta information from your database. Then it creates default settings for you, for then to allow you to override these settings. "Settings" here implies checkboxes, select dropdowns, and text fields - There is no "code editor" or complex configuration files the way you've got it in GraphQL. If you're smart enough to use Facebook, you can easily teach yourself how to configure the CRUD Generator in a couple of minutes.

Hyperlambda allows non-software developers to create web apps 1,000,000 times faster than software developers

Without this meta data, the CRUD generator wouldn't be possible to implement - Not even in theory. This is a part of my motive for not being particularly found of NoSQL for the record. NoSQL basically have no meta data. No schema, no meta data. Hence, from my point of view, automating development intended to insert items into a NoSQL database without a schema, is like trying to squeeze a square peg through a round hole.

In the video below I am demonstrating how this configuration process looks like, and how I ended up with the above screenshots.


If you're a freelancer or work for an outsourcing company, you probably already know that "time is money". If you can deliver something in half the time as your competitor, you can underbid your competitor, get the job, and still have larger profits when you invoice the client. The above app is roughly 30,000 lines of code in total. 26,000 are Angular frontend code. We know due to research in the subject that the average software developer can produce roughly 550 lines of code per month. This implies that the average software developer would need 55 months to deliver the above app. Yet again, I created it in 5 minutes.

Because of meta programming Magic can read meta information from any relational database system, use this as a formal specification, and automagically generate code wrapping your database in the same time frame. It doesn't matter how many tables you've got. 1,000 tables becomes roughly 2 million lines of code, and Magic will still happily create the code in a handful of seconds, 100% automagically for you.

This implies that if you are to choose between GraphQL and Hyperlambda, your choices are basically as follows.

  1. Use GraphQL, spend 5 months, go bankrupt in the process, and deliver inferior solutions in the end, riddled with bugs, security holes, and scalability issues
  2. Use Hyperlambda and deliver superior solutions in 5 minutes


I don't mean to bash on GraphQL, or developers having fallen in love with it. I really feel kind of sorry for them to be honest with you. From my point of view GraphQL developers are kind of like the Dodo - Happily walking the fields, having no idea of what's about to hit them. Because there's simply no way GraphQL can outperform a Hyperlambda developer - Not even in theory. However, the truth is still the truth, regardless of how many people believe it is false. And somebody needs to say this out loud, and it might as well be me ...

Hyperlambda makes you 10,000 times more productive than GraphQL - And this implies that GraphQL's destiny is to go extinct ...

This tragedy is of course made worse by the fact that hundreds of VC firms have invested billions of dollars in GraphQL startups. However, what can I say? I'm just the messenger here. At the end of the day you've got two options though.

  1. Do like the Dodo
  2. Choose Hyperlambda

To reproduce what I'm doing in the above video, feel free to signup for a free month trial at Aista below.

Top comments (2)

yavork profile image
Yavor Kirov • Edited

I read your other articles of this series and they had a lot of great advice for newbies. However this one is kind of... It's like comparing your whole product to it's REST API. It doesn't make much sense at all.

Yes GraphQL is a useless piece of trash technology that doesn't really scale well because it's a nightmare to setup, a nightmare to work with all the types, a nightmare to come up with a schema for the types and a nightmare to cache data AND a nightmare to authorize access to different pieces of data. (I do know from bitter experience with GQL and also having a ton of xp with REST APIs)

But I'd compare GQL it to tech we already have that's of a similar 'level of abstraction', like a "classic" JSON("REST") API. There of course GraphQL will inevitably lose the the comparison if it wasn't for all the preaching of Facebook Dev Gospel :/

Sadly you're right about the money incentives behind preaching a lot of the latest tech. A lot of tech, that pretty much nobody needs, gets a ton of advertisement in dev events and lectures all over the world. The result is people get hooked and waste their time with the new snake oils.

polterguy profile image
Thomas Hansen

Thx ...