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.
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 (50)
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")
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 ...
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 ...
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).
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.
However, one tries to be polite ...
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 :)
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 ...
At least our stuff allows you to apply business logic for those cases where it is required ...
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)
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 ...
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
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.
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 ... :/
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 ...
Hahaha, it's not perfect, but at least we're giving it a shot :)
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 ...
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) ...
Touche! You found our weakness man ... ;)
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 ...
Thank you ^_^
The same to you :)
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.
I spent 12 hours, every single day, for 5 days. I was done 11PM on a Sunday!! :P
Thank you ^_^
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:
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.
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 ...
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 😊
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.
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.
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 :)
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 ... :/
Thank you :)
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.
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 ...
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?
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 ...
In your Edge Functions: supabase.com/docs/guides/functions
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 :)
Of course, and thanks for the writeup !
I'm not sure the concerns are the same:
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.
Here's a a guide I found which should work with Supabase Edge Functions
dev.to/vuelancer/sending-emails-us...
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 ...
In Hyperlambda it would be an
ALT+Voperation 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" ...
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 ...? ;)
Fair enough! Looks like you've got a great system for sending emails. Good luck with Aista, Thomas - looks very cool
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 :/
Thank you, good luck to you guys and gals too :)
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 ;)