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, consi...
For further actions, you may consider blocking this person and/or reporting abuse
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 ;)
I am genuinely curious as to why the email needs to be sent FROM the same server as Hasura? You could dedicate an emailing server (separation of concerns), and access it via SMTP credentials from a serverless function hooked into Hasura via webhook in one of 3 ways:
I avoid hosting my own email server by outsourcing to Sendgrid. An example of my serverless function and my very basic frontend code.
Please don't judge my node/javascript code too harshly. I am a few days in. Constructive criticism welcome though.
Great question, and the answer of course is "it doesn't need to". If your frontend however has access to send emails, so does anybody else able to inspect your frontend code, implying you're opening yourself up to vulnerabilities, unless you explicitly add security layers on top of your SMTP frontend code. It's the same problem as with OpenAI, as in there's NO WAY you can (securely) integrate it into frontend code without a middle (backend) layer doing some security for you ...
Then I don't see how we disagree. However, injecting SMTP credentials into your frontend code is madness ...
Yes, I think we don't disagree. My smtp creds are still protected. My hasura server is not responsible for email, a different server is.
Your criticism of Hasura as "exclusively delivering GraphQL gateways as far as I know" is completely false. Hasura has always included database hosting and in fact it builds both the database and API immediately via it's schema editor. Almost all of your other criticism against Hasura is based on this flawed assumption. Some of your other criticism may be valid and Supabase and Aista may well be superior as far as I know but I am seriously doubtful based upon this invalid criticism.
It's irrelevant. Where do you put your business logic? On the client? If not, then you're in server land. If in server land, you end up adding REST on top of GraphQL to secure things. If you have to do REST anyways to apply BL, why go with GraphQL anyway ...?
However, last time I checked, Hasura delivered only gateways. I think their CEO even commented that fact on one of my articles a year ago or something saying "Yeah, we want to focus on what we're good at, implying gateways" (roughly) - What they're doing now I have no idea about. I left AISTA 5 months ago ...
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
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 ...
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 ^_^
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
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 ...
Tanmai is the founder of Hasura ...
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 ...
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?
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.
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 ...
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.
Psst ==> dev.to/polterguy/securing-graphql-...
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?
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 ...
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 ...
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 ...
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 ...