A comparison of Supabase, Hasura and Aista

dev.to/ozcap/hacking-bereal-a-prac...

there's a certain category of apps that are heavy on data but low on logic, where Supabase or Firebase are a great choice

This is correct, however exposing PostgREST or GraphQL endpoints to anyone on the web, might easily result in "business logic injection attacks". If done for internal apps, where only authenticated users can invoke the PostgREST or GraphQL endpoints of course, and only "employees" are allowed to authenticate, because it's an "internal" app, the situation becomes different. The remaining question then though, becomes as follows ...

If all you need is data (CRUD), why not go for the superior solution

At least our stuff allows you to apply business logic for those cases where it is required ...

leob • Oct 6 '22 • Edited

I see what you mean, in fact if your logic is in the app (frontend) and your backend is "dumb" then your only line of defense against tampering is HTTPS ... actually this trendy new app that I was referring to is called "BeReal", and I heard about it via some general news channel, when less than a week later there was coincidentally an article about it on dev.to:

BeReal uses Firebase as its backend, and the author of the above article demonstrated how you can totally manipulate what BeReal does and break its "rules" if only you manage to install a "man in the middle" (MITM) proxy on someone's phone ... now, that in itself of course requires "hacking" someone's phone, or getting a malware app into one of the App Stores, but if you manage to do that then it's free for all as the HTTPS link being trusted is the ONLY line of defense the app has.

(I'm not blaming the makers of BeReal, because for them this was probably just the quickest and most practical way to put an app together and get it to market, fast - as the value of this app is obviously not in its technical ingenuity but in the basic idea behind it ... whether we should be enthusiastic about yet another social media fad that urges people to be even more "constantly on" 24/7, given the increasing and alarming levels of mental health problems especially in young people, is another question - but that's of course a totally different discussion)

These simple Firebase, GraphQL and PostgREST "apps" are unfortunately opening up a whole new axiom of security issues, so new we don't even have a name for it, because historically nobody even considered doing this, for the reasons BeReal's problems illustrates. The closest I've come to naming these threats are "Business Logic Injection Attacks", because they're so similar to SQL injection attacks, except it's not the data that is the primary threat here, it's the logic ...

leob • Oct 6 '22 • Edited

Yeah it's not a matter of whether this gets exploited, but when ... the interesting thing about the BeReal article (the man in the middle attack with the proxy) is that a BeReal user could install the proxy themselves (rather than a hacker doing it) - and thus manipulate the way the app works? Although I have a hard time coming up with a reason why a user would want to jump through these hoops, the incentive isn't really there - but this makes it even more evident how easy it would be to manipulate this :)

All you need is an endpoint accepting GraphQL payloads, and / or PostgREST invocations. Exploiting this implies clicking F12 in Google Chrome really ... :/

You don't even need WireShark or anything "fancy" to win here ...

Psst ==> dev.to/polterguy/dynamically-aggre...

I had a great idea as I went for a swim :D

Mike Talbot ⭐ • Oct 5 '22

Of all of the comparison articles I've read of yours, this one seems the most complete in setting out your vision of how things should work, and as I don't have any experience of Supabase or Hasura I'll wait to see what others have to say in defence of your legitimate concerns. I have been burned by Firebase on a side project, on database costs, at least I could write server side functions there.

You and I share opinions on a number of things - I really like ActiveEvents and I use a similar pattern in React and NodeJS to effect pluggable extensible architectures. For reference I don't use Angular because since v2 it makes a lot of that stuff difficult in favour of its own dependency injection which I find less flexible.

I also appreciate the principle of HyperLambda and the way it resolves out as it runs to populate its graph. It is syntatically weird, but that's probably only worrying about learning iterators and when to unwrap. I prefer the whole of the interceptors thing to running code to modify code - I'm too worried there will be errors that damage something in that (it seemed in some of the training that this happened to you, and who can be more expert than you) - and I feel that wrapping shells around shells gives you better single places to enforce rules like authorization. You may well have use cases where the self modifying nature would be even more powerful, but they seem like they'd be pretty arcane and out of the reach of ordinary folk.

The thing that is strangest to me is your deep dislike of GraphQL - I would have thought that you could easily use your conventions and HyperLambda to make elegant GraphQL query, mutate and subscribe methods which would be self documenting and easy to consume by front end authors - while having the benefit of only transmitting the required data for the particular use case - like your record slicing but on read as well. This would be writing business logic, called by GraphQL, in HyperLambda.

Having read much of what you've written and having watched pretty much every AISTA video I really appreciate what you are doing and, given we have travelled similar development paths across our careers, I can see how you've come to this solution. I still think I'd have done a Javascript framework library and used dynamic V8 compilation on graphs described by JS functions rather than inventing a new language, primarily because I think you'd face less adoption resistance and have less to build and debug, but I get it and I wish you success.

It is syntatically weird, but that's probably only worrying about learning iterators and when to unwrap

You just summed up the two most difficult to grasp concepts, and these are challenges with the language. Unfortunately, we haven't been able to figure out how to correctly eliminate them, if that's even possible ... :/

I prefer the whole of the interceptors thing to running code to modify code

The way I'm doing it in the video, I'm "free flowing" of course. In a controlled environment you'd create reusable snippets, test them in DEV, before applying them to PROD of course ...

it seemed in some of the training that this happened to you, and who can be more expert than you

Hahaha, it's not perfect, but at least we're giving it a shot :)

You may well have use cases where the self modifying nature would be even more powerful

This is actually exactly how the "CRUD Generator" works in fact. It's starting out with 4 basic templates, for then to dynamically add, and / or remove parts from said templates, allowing it to create dynamic code endpoints. And today I am not aware of a single bug in it, even given the extreme amount of permutations you can apply during the process ...

The thing that is strangest to me is your deep dislike of GraphQL

Don't tell anybody, but I don't really dislike GraphQL, I only believe the way it's being used today is madness (exposing GraphQL to clients, for then to believe one can implement everything in frontend). As a middle layer, it's probably awesome in fact. Exposing it to edge (web) is probably madness though, even if you know what you're doing, something I think GitHub's latest move illustrates ...

However, too loosely coupling such as with GraphQL, and you've got no meta data. Without meta data, all automation constructs are impossible. It's the same reason I dislike NoSQL. However, also NoSQL is something I don't passionately dislike, I just think it's seriously overused. It has its use cases (sometimes) ...

like your record slicing but on read as well

Touche! You found our weakness man ... ;)

primarily because I think you'd face less adoption resistance and have less to build and debug

That is true, but even C# with its extremely strong reflection capabilities, doesn't provide us with "enough meta data" unfortunately. With JavaScript, all bets are off, and there's nothing to hold on to ...

but I get it and I wish you success

Thank you ^_^

The same to you :)

Mike Talbot ⭐ • Oct 5 '22

Raises some more interesting questions and points but I fear they'd only really work with a whiteboard (and maybe coffee/beer) :)

Hats off to you for the training videos though, that must have been a mammoth effort and it was very interesting to watch and learn some of the deeper details.

Hats off to you for the training videos though, that must have been a mammoth effort

I spent 12 hours, every single day, for 5 days. I was done 11PM on a Sunday!! :P

Thank you ^_^

Tanmai Gopal • Oct 7 '22

Hey Thomas. I’m one of the founders of Hasura.

Good work on hyperlambda! Saw your article on the Microsoft docs as well. Some very cool concepts - haven't gotten my hands dirty with it yet, but will try to play around with it soon :)

On the Hasura front, adding custom business logic is analogous to what one would have done with firebase like with using serverless functions on GCP. Hasura does the work to help invoke that business logic but Hasura doesn't host or run that business logic. And there are 3 ways of invoking that logic depending on where the logic is and where you want the logic to be:

Actions: part of the API, similar to firebase functions
Event triggers: HTTP handlers that are invoked when database events happen
Cron/Time triggers: HTTP handers that are invoked based on a time schedule

We deliberately have chosen never to get in the database hosting or the serverless function running space, because it’s a dedicated part of infrastructure that others will run better and keep improving and innovating on. Everything from databases like self-hosted Postgres on digital ocean to Aurora, to cockroach. And then not just Postgres flavors. Similarly, for “edge functions”, there’s some amazing providers, everyone from Cloudflare, to the cloud vendors to newer vendors like fly, render and more recently Deno (which is what supabase “edge functions” uses under the hood).

Hasura does a few simple things and we want hasura to do it well. We don’t want Hasura to interfere with other parts of your stack and what technology you want to use, esp as new innovations happen so that you can continue to use the latest and greatest.

When you’re querying stuff, you need to cache, add authorization rules and fetch from multiple models efficiently. Hasura is blazing fast and scales up and out very easily. Especially if you have use cases when you want to join across multiple databases. Say transactional data in Postgres and time-series in Timescale and analytical in BigQuery.
When you’re writing stuff, Hasura takes care of basic CRUD and gives you the right hooks to add your own stack however you want. Ideally, if you can get a serverless environment going, then you don’t have to do any “ops work” and everything is managed.
1. You have a great database vendor (say aws aurora or crunchy data)
2. You have a managed GraphQL API layer that handles the grunt parts of the work for you (Hasura runs as a container or runs on Hasura Cloud)
3. You have your own serverless function vendor (say Cloudflare workers or aws lambda)

I’d put together some thoughts a while go on how hasura works: hasura.io/blog/how-hasura-works/
Some work on how hasura does performance optimization: hasura.io/blog/architecture-of-a-h...

Our work is rather simple. We take away some parts of the work as neatly as possible, and make sure that it was written as if you had loads of database and API server experience. Everything else is yours and meant to be, because otherwise we get in the way of new innovation. For example, I’m pretty sure that one could use hyperlambda very easily along with Hasura. I’ve come across users who use Hasura along with supabase (eg: when they start hitting performance and scaling challenges).

The answer to how you’d build a “send email with Hasura”: you won’t. You’ll build it however you like and you would have usually! You might use Hasura to trigger that business logic when there’s an API call, or when there’s a database event or when there’s a time event. That's Hasura's role there.

Also, I saw some comments you made around a domain thing. That domain really isn't ours and I don't completely understand how we can help, but also please do feel free to reach out to me (tanmai [at] hasura.io). No, we don't have a shell company in Japan that's buying out lambda associated domains! Lol, we're a tiny startup and it's insanely hard to do legal and compliance stuff with multiple companies and stuff and there's no reason for us to do that.

We've never said anything negative about anyone in the ecosystem and we don't like "stifling" competition buy buying out domains or anything like that. It's not our style and it's just evil and stupid. You're doing great work and I will never deliberately sabotage anything you or anyone else does, and that's not what we would do at Hasura.

Looking forward to see how you build aista/hyperlambda and excited for what's to come!

Wow! Thank you. You sound legitimate, and I apologize for jumping the gun Tanmai. My bad 😊

One great quality I pride myself in regards to, is that when I'm wrong, I admit it! Something my team can testify towards.

I actually played with your stuff a couple of hours ago, and it has some cool stuff. The dashboard is nice, and easy to use. As to "tiny startup" though ... 😂

WE are a tiny startup. From my point of view, you're "huge". As to "doing one thing, and doing it really, really well", I can respect that. If more people and companies did that, the world would be better (ref; Nash and Game Theory) ... 😉

As to our "domain problems", and the "company in Japan", these parts make me reach back to my Viking and Berserker inheritance. If you say you e got nothing to do with it, I'll believe you though. It's just such a simple and cheap thing to do, and my knee jerk reaction to it, of course, as I assume you can understand is; "Where's my battle axe?"

If you say you've got nothing to do with it, I'll take your words for it, and believe you on it 😊

And I'll ease down on my "war rethoric" here. At least towards you. However, it was a simple thing to do (for the person doing it), and I would encourage the person who did it to simply stop! I'm one of those guys you want to be FRIENDS with, and not make your enemy ... 🤬

Anyways, I believe you when you say you've got nothing to do with it. And paradoxically, I admire your drive and product, and I respect that you want to continue delivering what you do great. I don't believe in zero sum games. From my point of view, 2 plus 2 is ALWAYS 5 😉

Thank you for the nice words of encouragement. I suspect we might be good friends over time. I just need to soak in your words first, and figure out some way we could play each other BETTER instead of competing ...

You've got the GraphQL thing, we've got the business logic parts (Hyperlambda). The only remaining question is how to combine it .... 😊

Thank you Tanmai, for an honest and respectful reply. From now on and onwards, the respect will go BOTH ways ...

Tanmai Gopal • Oct 7 '22

Thanks Thomas - glad to hear that! Keep us posted on any ideas you have around hyperlambda/aista and hasura together :)

Esp. if there's something interesting we can do for the .NET ecosystem along with SQL server (one of the databases we've recently started supporting).

If we get a nice shared value prop for developers it would be great to talk about it. No worries if not, always happy to be a friend in the ecosystem.

Thank you, and I'll answer your email too. Deeply appreciate it 😊

sina • Oct 8 '22

I want to use hyperlambda. Are there all the features mentioned on the website in the version of Selfhost?
If the answer is yes, I want to use it seriously so that I can give a better opinion about it. If it is really as you say, I will definitely use it.

Thomas Hansen • Oct 8 '22

Are there all the features mentioned on the website in the version of Selfhost?

Thank you. The easiest is to signup for a cloudlet here - Contrary to Firebase though, Hyperlambda is open source, so if you want to self host it, you can find its GitHub profile here. I'm not going to tell you hosting it is easy. It requires some configuration on your part, but it should be possible within a day or two to manage for a seasoned developer ...

As to all the features? There are even more features if you self host it, such as CQL (Cassandra slots) and a Terminal allowing you to do at least some basic commands in a web based terminal. The terminal is not super feature rich, and we've kind of ignored it for a while, but you get all features in the self hosted version as you get in the hosted version, and more ...

The easiest way to learn it is here. It's some roughly 5 hours of YouTube videos, and I am creating more as we proceed, FAQ style of videos.

If it is really as you say, I will definitely use it

Great! Remember, Hyperlambda was created as a "domain specific language" though, where the domain is creating high performing and highly scalable web apps, with a lot of data access, wrapping in simple business logic to your endpoints. You can't create desktop apps with it. You can't create "Twitter" with it (unless you use CQL and Cassandra). You can't create iOS apps. You shouldn't use it for algorithm heavy apps (polygon rendering for instance) - Etc ...

Its purpose is to make it very easy to implement internal backend administration apps. For this domain, it is "simply superior", due to its ability to automate a lot of your development ...

Let me know how it goes. If you're stuck and you supply a ticket, we typically answer within 2 minutes :)

SaiKrishnaKaushik • Oct 7 '22

I was wondering, if you could point me to any source where Github is moving away from GraphQL. Interesting article btw!

Like I said in another comment here, my source was two different commenters at YCombinator, independently of each other saying the same. I have no official source on it, and I can't find anything as I am searching for it. However, nobody objected to the statement at YC, and the person commenting seemed to know what he was talking about, and nobody have been able to object to it in any ways here either, so although it's not 100% certain that this is a true statement, I'm fairly confident in that it's the truth. Confident to keep it ...

However, I might have edited it and said something like "according to my knowledge ..." - Or something ... :/

Interesting article btw!

Thank you :)

sina • Oct 8 '22

Regarding the BeReal application, I must say that their good choice to use Firebase has made them able to quickly enter the competitive application market and bring their good idea to the hands of millions of users.

Thomas Hansen • Oct 8 '22

Choosing tools that gets you to market ASAP is a smart thing to do (sometimes). Choosing tools that at the same time paints you into a corner with lockin tech, resulting in that your existence is dependent upon somebody else's "goodwill" is not a good thing. I don't know everything about BeReal - However, I built my own social media application in 3 weeks 2 years ago using Hyperlambda. This was before Hyperlambda was mature, and I could probably have replicated it in 3 days today if I tried hard enough ...

The difference between vendors such as Aista, Hasura, and Supabase on one side, and Firebase on the other side, is that the first 3 are Open Source platforms, allowing you to move your stuff into your own hosting infrastructure as you grow. With Firebase you live your life on Google's mercy, and Google might anytime they wish pull the plug on you, something we saw with the infamous Amazon and Parler incident a year ago ...

Building (anything) using Firebase is madness, and it's not even a question of their technology, it's a question of "who owns your data and software". The answer to that question is (of course) not BeReal ...

pguardiario • Mar 18 '23

Supabase comes with built-in foot guns. They could block frontend connect with cors if they wanted to, the question is, why don't they want to?

Truong Hoang Dung • Oct 5 '22

Sad that the FE code is for Angular. Hope React.js will support soon.

Tell me about it ... :/
It's what EVERYBODY is telling me. It's "in our pipeline" though ...

Supabase • Oct 5 '22 • Edited

My question to Supabase though, is arguably taken from Hasura’s FAQ, and basically sums up the problems you will be facing if you choose Supabase, and it is as follows ...
Where do I put business logic?

In your Edge Functions: supabase.com/docs/guides/functions

dev.to/vuelancer/sending-emails-us...

OK, thank you :D

Psst, scroll further up and see comments about the same concern related to Hasura ...

Thank you though. Sporty of you guys to answer :)

Copple • Oct 5 '22 • Edited

Thank you though. Sporty of you guys to answer :)

Of course, and thanks for the writeup !

same concern related to Hasura ...

I'm not sure the concerns are the same:

Event triggers
3rd party REST APIs
GraphQL APIs
Stored Procedures and Database Functions

Edge Functions are Deno functions, and they're isolated from the database. It's very similar to running your own NodeJS server, using Cloudflare workers, or Serverless.

have a key account manager at Supabase explain to you how you’d go about with sending an email as an endpoint is being invoked.

Here's a a guide I found which should work with Supabase Edge Functions

Thomas Hansen • Oct 5 '22 • Edited

Yes, but then the value proposition disappears, and you're left with not two systems (backend + frontend), but in fact 3 systems (backend + frontend + edge), and possibly 3 different programming languages, plus 3 different platforms, and 3 different systems. At which point you've made things more complex and not less complex. Since removing complexity is probably the largest reason devs are attracted to Supabase in the first place, I'm not sure I agree with your primary value proposition ...

Don't misunderstand me, using stuff such as yours for simple CRUD stuff is probably OK, ignoring that using Aista for simple CRUD stuff is a bajillion times easier, maybe not quite as flexible though since after all PostgREST is more powerful than what you can do by "clicking the button in Aista Magic Cloud" - But exposing stuff to the edge, client side apps, and creating edge functions, or database functions for that matter, is not a simplification of the domain - Regardless of what domain you're in ...

Not to forget authentication and authorisation duplication with said edge functions, etc, etc, etc ...

Here's a a guide I found which should work with Supabase Edge Functions

In Hyperlambda it would be an ALT+V operation from Hyper IDE into your endpoint code, implying having one codebase, one language, one platform, and one server. Below is a screenshot of the entire process. Two clicks on your keyboard, and you're done!

Below is the code for reference purposes. Yet again, this goes into the same file that is responsible for accessing the database - Implying if you're doing anything beyond the simplest of data retrieval / manipulation, Hyperlambda is superior in regards to simplicity, even though your product arguably has a smaller initial mental investment requirement, due to our "Hyperlambda thing" ...

// Example of how to send an email using Hyperlambda.
mail.smtp.send
   message
      to
         Thomas Hansen:thomas@gaiasoul.com
      from
         Testing Gmail:testing.anarchy@gmail.com
      subject:This is subject
      entity:text/plain
         content:This is body

Edit - Below is a video where I am sending an email from a Hyperlambda endpoint in roughly 10 seconds of "no coding" by clicking two buttons on my keyboard. It's a bit rough on the edges, since I created it explicitly for you to watch now, so please bear with me if the video isn't professionally produced _^

Now if you want to create a Youtube video about sending emails from Supabase, I'd love to watch it ^_^

Feel free to propose the next use case too, then we can compare notes. Maybe we'll get some great ideas both of us, allowing us to further develop our platforms by comparing notes ...?

Thank you - Yet again, sporty of you guys to answer ... ^_^

Now if I could only have Hasura transfer my domain to us - Maybe we all could co-exist in peace, and wish each other good luck ...? ;)

Copple • Oct 5 '22

Fair enough! Looks like you've got a great system for sending emails. Good luck with Aista, Thomas - looks very cool

Thomas Hansen • Oct 6 '22 • Edited

Looks like you've got a great system for sending emails. Good luck with Aista

Hahahaha :D

Thank you, I'm slowly beginning to accumulate some respect for you actually ^_^

Good luck to you guys and gals too. Psst, a piece of advice, you need to figure out a USP for your edge functions, it's a nice value proposition, but you're in a "red ocean" here, considering that AWS and Microsoft are a decade ahead of you, and don't need to earn profit on their functions, and hence are giving these away for free (almost) to their devs. My suggestion to a value proposition would be the following ...

At which point you'd run in circles around Hasura. Now of course, the only way to accomplish the above, would be to either use Magic directly, and / or reinvent Hyperlambda. The latter I don't recommend, the process took me 10 years :/

Good luck with Aista

Thank you, good luck to you guys and gals too :)

Paweł Świątkowski • Oct 6 '22

GitHub is now removing all GraphQL support from their infrastructure

Got any link on that? I'm always keen on good ol' GraphQL bashing. Are they killing GraphQL API completely?

It was a couple of commenters, independently of each other. I have no idea where they got it from, but one was at YCombinator, and nobody replied to object, so I consider it "scientifically proven" if not for anything else but for the simple fact that nobody objected ;)

Dean Kayton • Jan 19 '23 • Edited

I am genuinely curious as to why the email needs to be sent FROM the same server as Hasura? You could dedicate an emailing server (separation of concerns), and access it via SMTP credentials from a serverless function hooked into Hasura via webhook in one of 3 ways:

time based (cron, e.g. if it doesn't depend on custom input from a user)
actions (explicitly triggered by graphql mutation for example)
event trigger (upon a database change)

I avoid hosting my own email server by outsourcing to Sendgrid. An example of my serverless function and my very basic frontend code.

Please don't judge my node/javascript code too harshly. I am a few days in. Constructive criticism welcome though.

Thomas Hansen • Jan 19 '23

I am genuinely curious as to why the email needs to be sent FROM the same server as Hasura?

Great question, and the answer of course is "it doesn't need to". If your frontend however has access to send emails, so does anybody else able to inspect your frontend code, implying you're opening yourself up to vulnerabilities, unless you explicitly add security layers on top of your SMTP frontend code. It's the same problem as with OpenAI, as in there's NO WAY you can (securely) integrate it into frontend code without a middle (backend) layer doing some security for you ...

My 'serverless function' is hooked up like this (backend code)

Then I don't see how we disagree. However, injecting SMTP credentials into your frontend code is madness ...

Dean Kayton • Mar 24 '23

Yes, I think we don't disagree. My smtp creds are still protected. My hasura server is not responsible for email, a different server is.

Trevor de Koekkoek • Sep 11 '23

Your criticism of Hasura as "exclusively delivering GraphQL gateways as far as I know" is completely false. Hasura has always included database hosting and in fact it builds both the database and API immediately via it's schema editor. Almost all of your other criticism against Hasura is based on this flawed assumption. Some of your other criticism may be valid and Supabase and Aista may well be superior as far as I know but I am seriously doubtful based upon this invalid criticism.

Thomas Hansen • Sep 11 '23 • Edited

It's irrelevant. Where do you put your business logic? On the client? If not, then you're in server land. If in server land, you end up adding REST on top of GraphQL to secure things. If you have to do REST anyways to apply BL, why go with GraphQL anyway ...?

However, last time I checked, Hasura delivered only gateways. I think their CEO even commented that fact on one of my articles a year ago or something saying "Yeah, we want to focus on what we're good at, implying gateways" (roughly) - What they're doing now I have no idea about. I left AISTA 5 months ago ...

sina • Oct 8 '22

Indeed, if someone has used hyperlambda, come and give his opinion about it.
Because I would like to know the opinion of someone other than the manufacturer.
Of course, this discussion will help me improve my English

Thomas Hansen • Oct 8 '22 • Edited

Because I would like to know the opinion of someone other than the manufacturer

Check out Aista.com - There are some quotes at the bottom down there. However, I think Tanmai's words most adequately describes it I think ...

Good work on hyperlambda! Saw your article on the Microsoft docs as well. Some very cool concepts - haven't gotten my hands dirty with it yet, but will try to play around with it soon :)

Tanmai is the founder of Hasura ...

As to performance? Hyperlambda is 7 times faster than Python
As to scalability? Hyperlambda is "async to the bone", implying it probably scales a "bajillion times" (literally) better than Python
As to syntax? Hyperlambda has zero OOP, implying the threshold to learn it becomes a bajillion times easier than Python

I could go on for hours, but literally, using Python as a use case against Hyperlambda, is like using a Volkswagen argument against space shuttles ...

A piece of advice; Python is a nice toy for kids, nothing more, nothing less ...

sina • Oct 8 '22

My favorite programming language is Python, so I do business logic with it. For example, it is possible to send email on the back-end side and only from the back-end.
I don't want to learn a new language to write back-end business logic when I already have a good command of Python.

Hasura is not made to replace back-end programming, and of course Hyperlambda can't do it either, unless you know all the back-end work is CRUD operations and sending emails.
The backend is much more complicated than that.

Things that I use Hasura in my project and that's why I like Hasura:
1- Console
2- Data modeling
3- The possibility of specifying accesses in a way that I have not seen anywhere else
4- The possibility of using view and function in the database (someone who knows how to work with the database will understand what I'm talking about)
5- Web hooks
6-Real time possibilities

Now tell me which of these things that are very helpful in my project, how do you do it in your project?

Thomas Hansen • Oct 8 '22

Hyperlambda can't do it either, unless you know all the back-end work is CRUD operations and sending emails

Hyperlambda is a complete programming language, and you can do much more than just sending emails with it ...

We built our entire infrastructure with it, integrating with Kubernetes, registrations of users, accepting support tickets from users, with screenshots, billing, invoicing, Stripe integrations, etc, etc, etc. And we built it in 30% of the time we had originally scheduled for the project with GoLang.

Now tell me which of these things that are very helpful in my project, how do you do it in your project?

I have answers to all of those questions. You can start out with seeing how I visually design a database and create a CRM system in 21 minutes, from scratch, in the video below ...

I have to apologise for being so slow though. I could probably have created the CRM in some 5 minutes, if it wasn't for the fact that I was making a YouTube video at the same time I was creating the CRM ... :/

As to web hooks, OK ...

Technically, they're not web hooks, but they're gateways rather - But it solves the same problem, and I could easily have create a web hook instead. Notice, we also accepts web hooks from for instance Stripe. So not only can you create them, but you can also consume them ...

As to Data modeling, OK, check out the generated Hyperlambda code in the above CRM system, how it applies joins, allows you to extract exactly what you wish, etc, etc, etc ...

As to real time possibilities, OK ...

What you don't understand is that although GraphQL is a nice thing to extract data - Hyperlambda is a complete programming language. This implies that even though you can find the occasional use case where GraphQL might be easier to use for you, I can create a bajillion use cases where you couldn't even use GraphQL, simply due to that GraphQL is a query language, and Hyperlambda is a programming language.

The difference becomes similar to the differences between HTML and JavaScript. 99.9999% of the stuff you can do in Hyperlambda becomes the equivalent of "writing a loop in HTML" trying to solve using GraphQL ...

sina • Oct 7 '22

GitHub still uses GraphQL
docs.github.com/en/graphql

To create integrations, retrieve data, and automate your workflows, use the GitHub GraphQL API. The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.