10 ms·
Looks like Supabase does support edge functions now. I've inherited a Parse codebase in the past, and thought it was pretty gross. You're stuck building with t
by programmarchy 4y ago
Looks like Supabase does support edge functions now.
I've inherited a Parse codebase in the past, and thought it was pretty gross. You're stuck building with their ORM abstractions, so it hurts when you need to do something complex. I view Parse as Facebook abandonware that's been salvaged by a community of developers who need to maintain legacy apps on life support. I think it'd be unwise to start a new project backed by Parse.
Having to deal with one-size-fits-all database "adaptors" for either Mongo-flavored or Postgres-flavored Parse is limiting, whereas having direct access to Postgres is a huge benefit of Supabase.
With Supabase, you can leverage all of the goodies that Postgres has to offer, which is exactly what I want as a developer. Even something as simple as writing custom SQL is a well-defined operation within the Supabase ecosystem, whereas with Parse you're in undefined glhf territory. Add that to first-class support for realtime updates, row-level security, and their other features, and Supabase comes out way ahead in my opinion.
- longrod 4y agoAll of those are supported in Parse as well. ORMs are a feature, not a bug. Writing SQL is all well and good but if you have GraphQL, it's not an issue. I think the whole point behind tools such as Supabase & Parse is a well defined & safe set of defaults which can easily be customized if the need arises. Parse is very well suited for this as you can custom endpoints, custom pgsql functions, custom edge functions in multiple languages (Go, Node etc) etc. Supabase is not that customizable. Sure, Supabase has a huge funding etc and it might get there someday but if you are into self-hosting (from which POV I am speaking), Parse comes out way ahead.