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 ...
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 ...
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.
Start with PostgREST because of lack of knowledge, believing it "solves everything"
Moving to "edge functions" because of realising one needs business logic in one or two endpoints
Replacing the entire PostgREST API with edge functions as one realise everything needs basic business logic
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
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).
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 ...
I see what you mean, in fact if your logic is in the app (frontend) and your backend is "dumb" then your only line of defense against tampering is HTTPS ... actually this trendy new app that I was referring to is called "BeReal", and I heard about it via some general news channel, when less than a week later there was coincidentally an article about it on dev.to:
BeReal uses Firebase as its backend, and the author of the above article demonstrated how you can totally manipulate what BeReal does and break its "rules" if only you manage to install a "man in the middle" (MITM) proxy on someone's phone ... now, that in itself of course requires "hacking" someone's phone, or getting a malware app into one of the App Stores, but if you manage to do that then it's free for all as the HTTPS link being trusted is the ONLY line of defense the app has.
(I'm not blaming the makers of BeReal, because for them this was probably just the quickest and most practical way to put an app together and get it to market, fast - as the value of this app is obviously not in its technical ingenuity but in the basic idea behind it ... whether we should be enthusiastic about yet another social media fad that urges people to be even more "constantly on" 24/7, given the increasing and alarming levels of mental health problems especially in young people, is another question - but that's of course a totally different discussion)
These simple Firebase, GraphQL and PostgREST "apps" are unfortunately opening up a whole new axiom of security issues, so new we don't even have a name for it, because historically nobody even considered doing this, for the reasons BeReal's problems illustrates. The closest I've come to naming these threats are "Business Logic Injection Attacks", because they're so similar to SQL injection attacks, except it's not the data that is the primary threat here, it's the logic ...
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 ...
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