I like the direction with working towards eliminating korg here!
One of the reasons I chose Directus over Supabase (they can also be used together, it's not either/or) is that I'm one of the rare engineers out there that doesn't like containers.
Well, to be more specific: I don't like containers for languages that don't need them. For example, a node monorepo doesn't really need a container, it's just a npm install away from working pretty much anywhere. Or a go static binary. Containers are great for languages/stacks that have more difficult dependencies.
That being said, Supabase just had too many moving parts for me. I'm allergic to complexity. I want my stack to be as basic as possible, I want to innovate in the business problem domain space, not the tech stack space.
I totally get the "don't reinvent the wheel" idea, but the complexity of a Supabase installation when you look under the hood at what's going on inside the container really turned me off. With Directus, it's just a npm dependency to your node app, nothing else. It'll automatically reflect over your database schema, and progressively enhance it with additional capabilities as you choose, automatic REST and GraphQL APIs with detailed and comprehensive configurable role based row-level security. An automatic and very capable Vue based admin app, and lots of other goodies. All the code is open source, well structured, easy to debug (it runs in-process, it's all just nodejs), and to fork/enhance as needed. Doing the same with Supabase would be difficult, to say the least.
I like the direction Supabase is moving with this - consolidating back to more of a monorepo with less internal services and dependencies.
I really like the Supabase Postgrest-js client too. One of the things that troubles me about directus is the home-grown DSL for queries. It's limiting and error prone, and impossible to do anything complex (you currently can't even query json fields, though that's coming soon I think). I think Supabase did a really good job with isomorphism with that library.
Another thing I think Supabase did right is to just focus on Postgres. Directus is hamstrung by their knex backend and multi-db support, imho.
I've been thinking that if I were to build something similar from scratch, I think I'd lean heavily on sequelize and build the whole shebang around that. It already has a very mature and capable DSL for queries that can be adapted to isomorphism with some symbol mapping and injection protection. It has the capability of enforced row-level security with scopes, and you don't have to deal with the issues around Postgrest or Directus' custom DSL. The only thing it doesn't have is automatic schema reflection - it's a model-first ORM. That's a solvable problem though.
I've had an "itch" about this for a while. I may be "retiring" in a year or two, and I'm seriously considering taking all the lessons learned from both Supabase and Directus and trying to create a super-simple sequelize based monorepo option as my next thing.
One of the reasons I chose Directus over Supabase (they can also be used together, it's not either/or) is that I'm one of the rare engineers out there that doesn't like containers.
Well, to be more specific: I don't like containers for languages that don't need them. For example, a node monorepo doesn't really need a container, it's just a npm install away from working pretty much anywhere. Or a go static binary. Containers are great for languages/stacks that have more difficult dependencies.
That being said, Supabase just had too many moving parts for me. I'm allergic to complexity. I want my stack to be as basic as possible, I want to innovate in the business problem domain space, not the tech stack space.
I totally get the "don't reinvent the wheel" idea, but the complexity of a Supabase installation when you look under the hood at what's going on inside the container really turned me off. With Directus, it's just a npm dependency to your node app, nothing else. It'll automatically reflect over your database schema, and progressively enhance it with additional capabilities as you choose, automatic REST and GraphQL APIs with detailed and comprehensive configurable role based row-level security. An automatic and very capable Vue based admin app, and lots of other goodies. All the code is open source, well structured, easy to debug (it runs in-process, it's all just nodejs), and to fork/enhance as needed. Doing the same with Supabase would be difficult, to say the least.
I like the direction Supabase is moving with this - consolidating back to more of a monorepo with less internal services and dependencies.
I really like the Supabase Postgrest-js client too. One of the things that troubles me about directus is the home-grown DSL for queries. It's limiting and error prone, and impossible to do anything complex (you currently can't even query json fields, though that's coming soon I think). I think Supabase did a really good job with isomorphism with that library.
Another thing I think Supabase did right is to just focus on Postgres. Directus is hamstrung by their knex backend and multi-db support, imho.
I've been thinking that if I were to build something similar from scratch, I think I'd lean heavily on sequelize and build the whole shebang around that. It already has a very mature and capable DSL for queries that can be adapted to isomorphism with some symbol mapping and injection protection. It has the capability of enforced row-level security with scopes, and you don't have to deal with the issues around Postgrest or Directus' custom DSL. The only thing it doesn't have is automatic schema reflection - it's a model-first ORM. That's a solvable problem though.
I've had an "itch" about this for a while. I may be "retiring" in a year or two, and I'm seriously considering taking all the lessons learned from both Supabase and Directus and trying to create a super-simple sequelize based monorepo option as my next thing.