Supabase Edge Runtime: Self-Hosted Deno Functions

Hi Mark, hosted Supabase Edge Functions would still run on Deno Deploy, so those limitations would still exist. However, we plan to introduce file system access via integration with Supabase Storage. This is still a rough idea stage, maybe we'll have a solid answer in a couple of months :)

For dynamic imports, we haven't looked into it since Supabase users haven't requested it. If you can open an issue on Edge Runtime repo [0] and explain how you intend to use them, we can probably work on a solution.

[0] https://github.com/supabase/edge-runtime/issues

> Example: https://github.com/PostgREST/postgrest/issues/915

> while there isn’t much action on existing issues.

That one is planned but it's not high priority because it can be solved already with SQL functions[1][2] in a flexible and secure way(GROUP BY is an expensive operation, it cannot be exposed to the frontend just like that).

I do get that some conveniences on the JS libraries are missing but they're not blockers(or critical features IMHO).

[1]: https://postgrest.org/en/stable/api.html#stored-procedures

[2]: https://supabase.com/docs/reference/javascript/rpc

This way of doing things is just so much more painful in terms of ergonomics we elected to instead escape hatch into raw SQL with a different library (Sequelize) in our case. Black boxing some of our business logic into views or RPC is just not something devs I work with are comfortable with. Having business logic live in the db like this just unlocks a whole new world of pain for people who aren’t used to it. Now I have a whole new class of problems too, now I have to have unit tests in the db with pgTAP and now I as a dev have to decide when and where this kind of logic should go in the db vs in the application layer and how to test it. In general I would really call this not a viable alternative at all unless there are some comprehensive design documents that say “do this stuff as RPC in the db because it makes sense to do it there, do this stuff in the application layer”. When I tried selling this ‘workaround’ in its current form to other devs in my org, they all balked at it.

Maybe I’m thinking about how Postgrest is supposed to work fundamentally wrong and all of this stuff is generally supposed to live in the db. But there certainly isn’t any guidance directing that in documentation currently. And in general I think if you want to advocate for a design where you split business logic between your application layer and your db there should be a plethora of examples where this has been done successfully, especially because that idea goes very much against how a typical developer thinks about system design.

It’s weird because I can do everything else in a “typical CRUD app” the nice way with Postgrest except this. It feels like the part of the codebases where I have to deal with this (and indeed, it comes up every time) is a constant wart in an otherwise pretty good setup.

Please don’t take this as me hating on Postgrest. I think it’s absolutely fabulous software and I am in genuine awe of what you have achieved. I can only aspire to have your work ethic and vision when it comes to this kind of stuff. I just want to help you see how myself and the devs I work with use it in real life and how they react to Postgrest in the context of using it when trying to make maintained business applications over years of time.

As someone who has been doing this for some years now, it is not simple.

To be fair, you can write a simple Ansible playbook if Ansible isn't doing much for you. But if you're using Ansible to manage things which are themselves not simple (like "just install a Node runtime please") you are at the mercy of whatever shell script Ansible eventually ends up calling.

I've been through Ubuntu version updates and Ansible really didn't help with issues like "that package is now no longer in the PPA you got it from".

Administration doesn't take a lot of my time, but when I do need to do it, it can take a solid day of focus to make sure I know what I'm doing, make the changes, recover from the pitfalls I always forget (e.g. "this Ansible step fails in --check mode because it depends on a file that is created in an earlier step, which doesn't happen in check mode") then work through the inevitable issues. I wouldn't want to do it without Ansible, but it's not "simply" anything.

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.