Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I didn't see any purpose to the PostgREST part as a back end to an application, because I'm not going to hard-code queries in my application. My server is going to provide an API that isolates the application from the DB structure.

So no... PostgREST wasn't a factor for me at all.



> My server is going to provide an API that isolates the application from the DB structure.

The same can be achieved with "schema isolation". See https://docs.postgrest.org/en/v12/explanations/schema_isolat....


Thanks for the reference. I'll take a look.


It seems your opposition to it is philosophical and/or based on assumptions (that one must "hard-code queries in the application"), or limitations of Supabase's Swift library.

I'm sorry you had a bad experience with this kind of tool, but I hope that one day you choose to revisit it.


"Seems" how? I gave specifics, not assumptions. I already explained WHY an auto-generated HTTP API to your database caters to the hard-coding of queries in the application. And the shortcomings of Supabase's Swift library (or its doc) are neither philosophical nor assumed.

So... what are you talking about?


You keep saying “this does X which is bad” while at the same time saying “if it doesn’t do X it is useless”.

To me this is a 100% philosophical opposition.

People find this tech useful. You might prefer writing your own backend. Claiming it doesn’t save time for people who use it to save time however doesn’t make much sense, does it?

> And the shortcomings of Supabase's Swift library (or its doc) are neither philosophical nor assumed.

I didn’t say it was.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: