DEV Community 👩‍💻👨‍💻

Cover image for A comparison of Supabase, Hasura and Aista
Thomas Hansen
Thomas Hansen

Posted on • Originally published at aista.com

A comparison of Supabase, Hasura and Aista

Disclaimer; I am the CEO of Aista, so obviously it’s impossible for me to give a 100% perfectly neutral comparison of these different stacks, considering that we look at Supabase and Hasura as our primary competitors. I will still try to provide a comparison, as neutrally as it is possible for me to do, without any bias, if that’s possible. However, realise that this analysis is created by a competitor of Supabase and Hasura.

Hasura

Hasura is smaller than Supabase. According to their GitHub profile, they have 28,124 stargazers as of today. Still they dwarf Aista’s GitHub profile in size with only 683 stargazers as of today. According to my knowledge Hasura is in round C of their VC investments, with the total amount of funding being between 100 million dollars and 200 million dollars in total.

Hasura currently supports the following databases; PostgreSQL, Microsoft SQL Server, Amazon Aurora, Google BigQuery, and YugabyteDB. According to their website they are working on support for; Oracle, MongoDB, MySQL, Elastic, Snowflake, CockroachDB, Athena, and SQLite. The fact that they’re implementing support for SQLite, implies they are looking towards hosting your database in the future, due to that SQLite is a file based database, without any networking. I don’t believe Hasura is currently able to give you a database, but I might be wrong here.

Hasura is exclusively delivering GraphQL gateways as far as I know, and they are basically a “gateway” to your own database. This implies that Hasura does not give you a full product, but rather you have to have an existing database from before, and Hasura only simplifies access to your existing data by providing you with a “GraphQL gateway” towards your own database. This implies you have to expose your database to the edge, allowing Hasura’s servers to gain access to your database somehow, which might result in both a whole range of new security issues, in addition to additional latency. The latter is especially true if Hasura’s servers and your database server is separated by a large physical distance. Depending upon how many data centres Hasura have, and / or how smart they are in regards to load balancing requests transparently according to the distance to your database, this might result in even the simplest of database retrieval operations requiring 1 second or more, when it should be easily retrieved in some few hundred milliseconds. In addition, Hasura can never deliver data faster than your database can return it. This comes in addition to latency issues due to distance between your database and Hasura’s servers. This architecture also for obvious reasons significantly increase the attack surface of our end product, since you now have a database exposed to the edge, and unless you really know what you’re doing here, you’ve opened up your database server for a whole new range of attack possibilities.

For the record, the latter is also true for Aista, but at least we have a “hosted database option” here, and so does Supabase.

There are of course multiple opinions about GraphQL – However, most of the concerns about GraphQL is that at least the way GraphQL is being used by Hasura, it probably results in opening up a whole range of security holes, in addition to that it moves the business logic parts from your server to your client frontend code. Having business logic on the client is for most of us considered an “anti-pattern.” Whether or not you think this is fine or not, is personal. However, the general consensus here amongst developers seems to be that the more experienced a developer becomes, the less likely he or she becomes to implementing business logic on the client, due to that he or she considers it an “anti-pattern”. When the client is generating its own GraphQL queries to extract data from your database, all business logic ends up on the client.

Having business logic on the client is a very, very, very bad thing!

If you are accessing Hasura’s servers directly from your frontend client code by passing in generated GraphQL snippets, this implies that everything required to build your application is moved from the backend API parts, and into the frontend client side code. Even ignoring issues such as “business logic injection attacks” (if that’s even a word), this simply moves the problem. You’ve solved nothing, you’ve just moved the burden of implementing your app from your backend to your frontend. You have arguably saved nothing. What you have achieved though, is the ability to write your app in one language. If all you know is one language, this might be a value proposition too tempting to resist of course. I suspect a huge amount of Hasura’s users today are junior developers, with zero knowledge about architecture and great designs, and that when they come out into the “real world”, their current methods of creating applications will be brushed aside as “toys for kids” ...

If you’re developing internal backend administration applications though, the above concerns are less important. For anything exposed to the edge of the internet though, allowing users to generate their own GraphQL queries and transmitting these to Hasura, this becomes a major problem – Due to that the client can at least in theory construct his or her own “business logic” and transmit these to Hasura to modify your data in unpredictable ways. This is a whole new security threat we don’t even have a word for because we’ve never even considered exposing such functionality historically for obvious reasons. If I’d have a go at coining a phrase for it, I’d name it ...

Business Logic Injection Attacks

Notice, Hasura is obviously painfully aware of their own shortcomings related to business logic, since one of their FAQ questions is; Where do I put business logic? As to their answers to this question, I’m not even sure if I want to comment on it. I’ll let their own answers do the commenting for me here. If you’re not technically savvy yourself, I suggest you find your senior developer and ask him; “Would you put business logic in stored procedures or event triggers?” I suspect your senior developer’s reaction will be all the understanding you’ll ever need.

Hasura's business logic answers

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

Notice – GitHub is now removing all GraphQL support from their infrastructure. Obviously GraphQL was a “bad experience” for GitHub. We have to assume the largest code repository service provider on the planet knows a thing or two about GraphQL that most of us have still to catch up on.

Supabase

In only 2 years Supabase has dwarfed Hasura. In its existence it has achieved 39.400 stargazers at GitHub. Supabase is built on an entirely different technology. However, Supabase seems to have GraphQL initiatives in the making, and might deliver GraphQL later since it’s currently a BETA product they deliver. However, their primary product today is based upon PostgREST. PostgREST is a thin layer similar to OData that sits on top of your web server allowing you to transmit basic queries that are executed towards your database. It suffers from the same “business logic injection attack” problems as GraphQL, and simply moves the burden of implementing business logic to the client, solving few problems really.

Supabase are marketing themselves as “The open source alternative to Firebase”. However, technically the platforms couldn’t be further apart, although for practical concerns they have similar functionality. Supabase too have gathered some slightly more than 100 million dollars in VC funds, and are currently in round B of their funding.

Supabase contrary to Hasura is a more “complete” solution, since they do provide you with file storage, and a PostgreSQL database. I am not entirely sure if Hasura provides you with a database, but I couldn’t find any information on their website in regards to this – So I suspect Hasura only works as a “gateway” to your own existing database.

Because Supabase is more “complete” you can use Supabase “out of the box” and immediately start creating your frontend code after having designed your database. This is not that easy with Hasura, since you need an existing database, and existing authentication endpoints, etc. On the simplicity scale, I suspect most developers would experience Supabase as the superior product, since they can instantly start creating frontend code – Where as with Hasura, you need to have an existing database and an authentication server before you can even start using their product. Supabase also provides authentication out of the box, allowing you to ignore everything that’s backend code, exclusively focusing on frontend. For obvious reasons this is probably a very tempting value proposition to junior developers and frontend developers only having experience with JavaScript or frontend platforms such as the iOS SDK, etc. Supabase is also much less expensive than Hasura, which begs the question if they can keep on delivering at these prices, or if they have to increase their prices as they run out of VC money.

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?

If you don’t understand the problem related to business logic, 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. This is a ridiculously simple “business logic use case”, and I suspect you can’t even do it in Supabase without invoking some 3rd party API, such as SendGrid from your client side frontend code. Notice, sending an email from your client side frontend code is a very, very, very bad thing! If you don’t understand why, let me enlighten you ...

Postman + credentials to SMTP server + script kiddie with access to API == 40,000 emails sent per second to some “whatever email address”

Are you beginning to see the problem here …?

Edit - Read the comment further down, where one of the co-founders of Supabase answered my question by showing how "edge functions" can solve the problem.

AISTA

Aista don’t provide any “query languages”, neither GraphQL, PostgREST, nor OData. Instead, we generate code automatically in your backend. This creates a “strongly typed” web API, exposing meta data to clients wanting to automatically generate frontend code. An example of an app that was 100% automatically built using this process can be found below.

A 100% automatically generated web application

Ignoring the fact that we solve the business logic problem, by allowing you to implement your own business logic on the server – Even imagining some GraphQL, PostgREST, or OData endpoint being able to generate something such as the above, is simply impossible. The reasons are because a “strongly type” web API exposes meta information about your database. Something that’s completely lost as you have a dynamic endpoint accepting some “query language”. This is true both for PostgREST queries and GraphQL queries.

The disadvantage with us compared to Hasura and Supabase, is that you have to learn a new programming language called Hyperlambda. This might be a larger initial investment for you mentally, since learning a new programming language is hard – However, we have done it as easy as we can for you by creating a Free Hyperlambda Course where you should be able to at least in theory learn Hyperlambda in 5 to 10 hours, depending upon how much software development theory you understand from before.

However, where Supabase and Hasura are “shiny toys for JavaScript script kids”, we allow you to create complete apps, with complex business logic, integrations towards 3rd parties, send emails securely (pun!), and whatever you want to do. The initial mental investment you have to do with Aista is slightly larger, unless all you want is a CRUD frontend of course – However, once the initial investment has been done, you can create things you can’t even imagine doing with Supabase and Hasura – At least not without creating your entire business logic in your frontend – Which I assume you at this point understand is a very, very, very bad idea!

Conclusion

Yet again, I am the CEO and founder of Aista, so obviously I am biased, and you will need to make up your own opinion in the end. However, when I’m thinking of that both Supabase and Hasura was able to get hundreds of millions of dollars in VC funding, and I and most other senior software developers cannot even take their value proposition seriously, and they have close to zero intellectual property due to being thin abstractions on top of open source products they do not own themselves, and everybody can download and install on their own VPS in minutes, and that there are …

It becomes increasingly difficult for me to even take them seriously. In fact, I told my partner several months ago when we discussed Hasura over a dinner the following.

If you want me to create a Hasura copycat company, I would need 3 devs and 3 weeks, at which point I’d be able to technically completely replace their entire value proposition ...

The same is of course true with Supabase. These companies aren’t software development companies, they are something else. I think I should avoid enlightening you with my theories in these regards though, due to me after all being biased the way I am. However, it is impossible for me to take them seriously, at least from a technical perspective … 😉

They are both very good at marketing though, and they have nice websites – At least that counts for something … 🙂

If you disagree with me, please explain in a comment how I'd go about sending an email as a Supabase or Hasura endpoint is being invoked - FROM the server, without having to expose my SMTP credentials to my frontend in any ways ...

Top comments (44)

Collapse
 
leob profile image
leob

Completely agree, putting that much business logic in the frontend is an anti-pattern ... honestly I don't see the hype about Supabase, and the elephant in the room is of course "where do I put my business logic" - and with Supabase the answer is mainly "in the frontend".

(I believe they have something like lambda functions in their roadmap but it's not there yet I think ... and coding business logic in PostgreSQL stored procs is of course something nobody takes serious as a "solution")

Collapse
 
polterguy profile image
Thomas Hansen Author • Edited on

Stored procedures is as you say, not something anybody takes seriously. Of course, writing "edge functions" is a major improvement - Edge functions is what they're referring to their lambda functions as.

However, if you're writing a function anyway for your business logic, at which point I assume the function at least must have some sort of compliance towards some type declaration of your data, unless you want to dynamically traverse the graph object given, at which point Hyperlambda is anyways superior - My question is why not just create the entire logic in the same function? To condense the question ...

If you need to write a function, in a 3rd type of technology to apply business logic, and this function requires strongly types data to understand what it's dealing with anyways, why not store the data from your function also to avoid unnecessary dependencies, at which point PostgREST becomes useless?

Of course, doing it as I suggest above, basically results in that they've reproduced the functionality we've got in Hyperlambda ...

However, edge functions is a major improvements over stored procedures ...

When that's said, edge functions are basically the same as lambda functions from AWS and Azure functions from Microsoft, so there's no real innovation here - And I suspect both Azure and AWS functions are "slightly more mature" - And at least Azure functions are ridiculously inexpensive, and there's no way anyone can compete with Microsoft on price for these guys while still earning a profit ...

Collapse
 
leob profile image
leob

You mention innovation - I don't see any real innovation with Supabase ... they give you freebees, like free or low cost storage and a hosted PostgreSQL database, and some auth stuff, and that's probably what draws people in, but apart from that I don't see what the hype is about ... Firebase has more innovation with their "real time database" than what I see with Supabase (they're not even really that comparable, as you already rightly remarked).

Thread Thread
 
polterguy profile image
Thomas Hansen Author • Edited on

Well, I don't disagree with you. Lambda functions and azure functions have been around for a decade, and at least Azure allows you to write your functions in something like 50+ programming languages, where Supabase restricts you to TypeScript (I think) on "edge functions". I suspect why people are flocking to it as I said in the article, is because of the simplicity that PostgREST gives you as a beginner, not realising it's painting you inside of a corner technically in the long run, resulting in that the "simplicity" over time turns into a maintenance nightmare ...

I guess a summed up experience for most devs would be the following.

  1. Start with PostgREST because of lack of knowledge, believing it "solves everything"
  2. Moving to "edge functions" because of realising one needs business logic in one or two endpoints
  3. Replacing the entire PostgREST API with edge functions as one realise everything needs basic business logic
  4. Regret one didn't use Azure functions, Lambda functions, or Hyperlambda as you realise you no longer needs PostgREST, and you might as well have created your entire project using "code" anyways

However, one tries to be polite ...

Thread Thread
 
leob profile image
leob

Supabase is fine if you understand what it gives you, and if it really meets your requirements (also in the long term) ... there's a certain category of apps that are heavy on data but low on logic, where Supabase or Firebase are a great choice (there's this trendy new social media app, the name of which I can't remember right now, that was built on top of Firebase - and seeing the requirements of that app I can say they probably made a logical choice).

So yeah there's that :)

Thread Thread
 
polterguy profile image
Thomas Hansen Author

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 ...

Thread Thread
 
leob profile image
leob • Edited on

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:

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

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)

Thread Thread
 
polterguy profile image
Thomas Hansen Author

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 ...

Thread Thread
 
leob profile image
leob • Edited on

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 :)

Thread Thread
 
polterguy profile image
Thomas Hansen Author

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

Collapse
 
coco98 profile image
Tanmai Gopal

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:

  1. Actions: part of the API, similar to firebase functions
  2. Event triggers: HTTP handlers that are invoked when database events happen
  3. 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.

  1. 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.
  2. 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!

Collapse
 
polterguy profile image
Thomas Hansen Author

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 ...

Collapse
 
coco98 profile image
Tanmai Gopal

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.

Thread Thread
 
polterguy profile image
Thomas Hansen Author

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

Collapse
 
miketalbot profile image
Mike Talbot

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.

Collapse
 
polterguy profile image
Thomas Hansen Author

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 :)

Collapse
 
miketalbot profile image
Mike Talbot

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.

Thread Thread
 
polterguy profile image
Thomas Hansen Author

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 ^_^

Collapse
 
sina68 profile image
sina

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.

Collapse
 
polterguy profile image
Thomas Hansen Author

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 :)

Collapse
 
sina68 profile image
sina

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.

Collapse
 
polterguy profile image
Thomas Hansen Author

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 ...

Collapse
 
supabase_io profile image
Supabase • Edited on

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

Collapse
 
polterguy profile image
Thomas Hansen Author

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 :)

Collapse
 
kiwicopple profile image
Copple • Edited on

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

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

Thread Thread
 
polterguy profile image
Thomas Hansen Author • Edited on

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!

Sending an email using Hyperlambda

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
Enter fullscreen mode Exit fullscreen mode

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 ...? ;)

Thread Thread
 
kiwicopple profile image
Copple

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

Thread Thread
 
polterguy profile image
Thomas Hansen Author • Edited on

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 :)

Collapse
 
saikrishnakaushik profile image
SaiKrishnaKaushik

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

Collapse
 
polterguy profile image
Thomas Hansen Author

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 :)

Collapse
 
revskill10 profile image
Truong Hoang Dung

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

Collapse
 
polterguy profile image
Thomas Hansen Author

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

Collapse
 
katafrakt profile image
Paweł Świątkowski

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?

Collapse
 
polterguy profile image
Thomas Hansen Author

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 ;)

Collapse
 
sina68 profile image
sina

Hello to all
I apologize in advance for not being fluent in English.
I read the full text of this article and another article of yours and I realized that you used the names of two famous projects to attract audience for your start-up and you used them without being fully familiar with these two projects and of course You questioned them unfairly in order to focus on your project
I have been working with Hasura for about 2 years and I am very satisfied with it, and as you said, I did not use business logic on the client side.
When you don't know how to work with a project, you certainly can't comment on it
In my opinion, it would have been better if you had mentioned the features of your project and avoided unfair criticism of these two projects
Yes, I am a senior and I use Hasura.
Goodbye

Collapse
 
polterguy profile image
Thomas Hansen Author • Edited on

Great, good luck :)

Psst, it's called a "competitor analysis", everybody does it, and the only reasons why Hasura and Supabase haven't already done it with us, is because we're "too small" for them ...

And I am 100% honest about who I am, and where I work, before I give my analysis ... ;)

Just sayin' ...

As to "unfairly talking about competitors to attract clients" - I got an email from Hasura a month ago, and yes I subscribe to their newsletter, the email had a meme of a kid looking at some garbage with the title; "This must be made by Microsoft" ...

I have been using Microsoft for 25 years professionally, I am a CEO, and yes I am a senior developer ;)

However, feel free to tell us where you're putting the business logic. According to Hasura's own accord, one of two options seems to be adding it to the database as stored procedures, and / or functions.

And, as to "unfair business", feel free to checkout hyperlambda.com please ...

When I started Aista, the person who owned it wanted several thousands of dollars for it, and I couldn't afford it. It was registered by a user in the Hasura "community" 4 months ago, at the time I started writing these articles ...

Then feel free to inform me what Hasura's "community members" could possibly want that domain for ...

Also check up who owns that company in Japan who "'accidentally' share our name, and also 'accidentally' happens to be delivering cloud services". When you're done, come back and tell me who are doing bad business here ...

However, I'll cut them a deal; When Hasura transfers my domain to me, and shuts down the company they "accidentally" opened up in Japan, that "accidentally" shares our name, and "accidentally" are delivering "cloud services", I will stop talking about them ...

Until then, I will talk about them as much as I want to, until I have vacuum cleaned their GitHub repository of star gazers, minus you ofc I assume ...

Yet again ...

Where do you put your business logic? In the frontend such that everybody can see it?

If Hasura's software developers, and their business developers, wants a crash course in business logic, I would be happy to provide a course for them. I've already started in fact ^_^

Collapse
 
sina68 profile image
sina

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

Collapse
 
polterguy profile image
Thomas Hansen Author • Edited on

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 ...

  1. As to performance? Hyperlambda is 7 times faster than Python
  2. As to scalability? Hyperlambda is "async to the bone", implying it probably scales a "bajillion times" (literally) better than Python
  3. 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 ...

Collapse
 
sina68 profile image
sina

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?

Collapse
 
polterguy profile image
Thomas Hansen Author

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 ...

Collapse
 
sina68 profile image
sina

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.

Collapse
 
polterguy profile image
Thomas Hansen Author
Collapse
 
sina68 profile image
sina

It seems that you got narcissistic with this hyperlamda you made
Because the name of any technology or programming language that I bring is a toy for children.

Of course, I understand because when I make a project myself, I love it like my own child

How do you consider yourself an expert programmer when you consider everything to be the speed of execution and simpler syntax, which of course is the case.
So the developers of Instagram, Google, NASA, etc. are all children who use Python and only you are adults

Please be reasonable, because everyone reads what you write here as the creator of the hyperlambda project and what do you think they think about you?

Collapse
 
polterguy profile image
Thomas Hansen Author • Edited on

the name of any technology or programming language that I bring is a toy for children

Literally, Python is the first programming language we teach our children. It's easy to start with, it teaches OOP, so it provides a foundation for children to grow. Even I tell children to teach themselves Python, the same way we used to teach them Logo 4 decades ago.

It is at least one order of magnitude slower than mature languages such as C#, and there's a reason why once you're done with colleague, few companies are taking it seriously for their internal needs. Google invented GoLang as a "Python killer", because they were tired of the lousy performance Python gave them.

Literally, Python is a child's toy. Few if anybody in the "real world" takes it seriously for anything more complex than maybe the occasional bash script ...

So the developers of Instagram, Google, NASA, etc. are all children who use Python and only you are adults

Like I said, creating simple bash scripts in it is probably OK. Google however is trying everything it can to replace it with GoLang for the reasons I mention above. If you've got the same app written in for instance C#, GoLang and Python, then it becomes as follows ...

  1. Serve 100 simultaneous users in your Python app
  2. Serve 1,000 simultaneous users in your GoLang app
  3. Serve 5,000 simultaneous users in your C# app

Python scores similarly with every other main stream programming language that's out there. Even the creator of Python had to give up trying to optimise it. He made it as a "fun programming language" thing in a couple of weekends, and it never really move out of its original beginnings ...

So the developers of Instagram, Google, NASA, etc. are all children who use Python and only you are adults

You will find NASA engineers that are driving Volkswagens. Does that imply Volkswagen is "NASA technology" ...?

Yet again, for simple bash scripts and such it's probably great. For anything serious though, it's a nightmare ...

DEV has this feature:

Settings

Go to your customization settings to nudge your home feed to show content more relevant to your developer experience level. 🛠