[Jean-Papoulos]

>Because these simple scenarios appear to be distant outliers for Supabase

You've only talked about 2 things : Lack of documentation (which I somewhat agree with) and using custom certificates. Custom certificates is not a "simple scenario" and I don't blame Supabase for not spending time on this. I fact I would prefer they work on other things (like documentation !).

[DidYaWipe]

It is 100% a simple scenario. I can't speak for Android, but you have to use HTTPS now for calls in an iPhone app if you want to get it approved. That means you need to deploy certificates to your test devices, simulators, and development machine.

"Lack of documentation" speaks to several apparently routine use cases being outliers; otherwise, they'd be documented. I already talked about the User table Supabase provides (and populates in unexpected ways), and about the Swift library that you have no reference for formulating joins through... another critical and expected ability.

[madamelic]

That is the root of the problem with these batteries-included frameworks: lock-in.

Once you encounter a problem they either don't want to solve or haven't solved, your only choices are either:

- start layering on hacks (in which case you quickly get into case where no one and nothing else could help you)

- decide not to do that-thing

- do a rebuild to get rid of the batteries-included.

Personally I think something Supabase is great for toy projects that have a defined scope & no future or a very early startup that has the intention to rebuild entirely. Just my opinion though, maybe others feel more comfortable with that level of lock-in.

Even something like Heroku is miles better because they keep everything separated where your auth, database, & infrastructure aren't tightly coupled with a library.

[cpursley]

By comparing supabase to Heroku, you demonstrated that you don't actually understand what it is...