Supabase allows you to create a database free of charge, and use PostgREST to generate a CRUD API towards your database. The problem is that if you need any business logic between the client and your database, then PostgREST is useless, and you'll have to resort to edge functions.
Edge functions are based upon programming and requires extensive knowledge about Python or NodeJS. Ignoring the fact that Python is so slow in a multi threaded environment that (literally!) its best practices recommends using multiple processes in multi threaded environments, and NodeJS' package manager feels like something created while micro dosing on LSD - You still have to understand complex programming theory, completely eliminating your ability to use Supabase as a no-code and low-code framework.
Supabase is not Low-Code or No-Code
In addition your client's single HTTP invocation towards your edge function results in 3 internal network connections, significanly reducing scalability while increasing latency. To understand why that is let's break down the flow.
- The client invokes an edge function
- Your edge function invokes PostgREST
- PostgREST invokes your database
This of course compounds your scalability problems, especially if you're using Python, making it literally impossible to truly scale your app beyond some specific threshold. If you don't know what I'm talking about, come back when you've got 100+ simultaneous users in your Supabase app ...
Magic to the rescue
With Magic and Hyperlambda you can sometimes completely rid yourself of the requirement to create code (manually), in addition to removing at least one of the above network connections. This simplifies your job, while also making your solution more scalable, due to less resource requirements for each HTTP invocation. Since Hyperlambda is async to the core, this results in that no thread is taken up by the host operating system while it's waiting for data from your Supabase database, making it "a bajillion" times more scalable. Watch the following video to understand.
The point with Magic is that it's a true low-code and no-code software development framework, allowing you to use "declarative programming" to solve most of your tasks. Declarative programming is basically just a fancy word for "drag and drop based programming", where you can add fairly complex business logic, without manually having to create the code yourself. This is why Magic's slogan is as follows.
Where the Machine Creates the Code
This allows you to solve most of your business logic requirements using Hyperlambda workflows, which of course is a superior way to solve problems compared to Python and NodeJS. And if you're stuck with something you can't do with declarative programming, you can of course resort to manually coding. This creates a bridge between 3 worlds, allowing you to seamlessly jump back and forth between 3 different worlds.
- Solve 80% of your problem with the Endpoint Generator
- Use Hyperlambda workflows for 80% of the remaining problem
- Resort to manually creating Hyperlambda only where needed
All in all, this typically allows you to take an existing Supabase database, connect it to your Magic Cloudlet, and have working software up running in a couple of hours.
So when you're stuck with Supabase and the only way forward seems to be to learn Python or NodeJS, do not despair, we've got you!
Epilogue
There are 1 million Supabase databases according to Supabase themselves. My guess is that 90% of these are just people playing around, having tested it once or twice, for then to never bother with it again. This leaves 100,000. Out of these maybe 100,000 databases are actually being used. 90% are probably "simple solutions" not really needing anything but simple CRUD, such as translation apps, and other types of lookup tables, etc.
However, this leaves 10,000 real world systems, actually being used, with complex requirements that are almost impossible to rapidly solve with Supabase - And even if you manage to solve them, your solution basically feels like sirup. Implying there are 10,000 solutions out there believing in that "edge functions" are their only way out of their own mess, while edge functions actually only compounds your problems and increases the magnitude of its scope.
I'm here to tell you that not only are edge functions the equivalent of adding duct tape and chewing gum to an airplane to fix it, but there are also alternatives to edge functions - Implying of course Magic Cloud and Hyperlambda.
There (might be) life after death!
However, I'm only one guy - Yes, literally, one guy! And I can't help all of you at the same time. However, the first 100 people signing up for a cloudlet to fix their Supabase problems will get 50% discount, allowing you to purchase a cloudlet for $149 per month. This does not give you an on premise solution, and no C# extensions, but it'll rapidly fix your Supabase problems. Notice, this will be a reduced cloudlet, only really allowing you to wrap your Supabase database, and not contain "fancy stuff" such as file uploading, a lot of storage, etc.
In addition I'll work on your domain problem for $170 per hour if you need help. 10 hours with me of course is probably worth 100,000 hours with the average junior dev charging you $50 per hour. Something that can be seen by the fact of that I've got roughly 15,000 commits towards GitHub the last 5/6 years, and that I basically created Hyperlambda and Magic 100% completely alone!
And, it's not like as if you've got any options really. I presume you've already been prompt engineering ChatGPT trying to figure out how to solve your mess, which of course failed, so it's not like as if you've got any (real) options here. However, I'm a nice guy, so I'll help you out if you want to.
However, when working with me, there's one rule of thumb, and the reasons are because you chose Supabase to build your app on top of, and that rule of thumb is as follows.
I'm right, you're wrong!
The reasons are simple; I don't have the time to explain everything, and you've already proven your inability to chose correct architecture for your own problems due to chosing Supabase. So even though you might in theory be correct 1% of the time, I simply don't have the time to explain my decisions, because yet again - There's one of me, and 10,000 of you - And if we're to do this, we need to make sure we can do it in a way that results in that as many as possible gets help.
So even though you might be right 1% of the time, it will take too much time to discuss and convince you that you're wrong the remaining 99%, so I'll only do this if you show me the respect I deserve, which is that by default you accept my decisions as I try to help you ...
I'm right, you're wrong! A simple rule set 😊
If you're interested in the above, please contact me below.
Top comments (0)