auth-ui VS edge-runtime

Supabase is great - I use them now and they and would be my choice for a new project today - but I have to say I am not a huge fan of how they communicated the whole auth-helpers and ssr situation, and I am not the only one with this comment by a long shot. This is, I think, a part of wider issues with their documentation; it seems like whoever's doing documentation at Supabase is intelligent but stretched thin. Particularly for Sveltekit, the documentation and examples are incomplete, there isn't any guide to migration or how to modify your code, and if you Google things or follow any links or examples you quickly end up in a web of deprecated repositories where it's unclear what to do next or replace them with. One example: https://github.com/supabase-community/auth-ui

If you produce a product for developers, you really need to have 1) quality, readable documentation with an introduction that noobs and pros alike can follow, 2) multiple complete, cloneable examples on how to integrate and use your product in several different libraries, 3) obvious migration guides and timelines whenever you deprecate something. Supabase lacks all three, which is extremely frustrating and means there's always a giant caveat when I recommend them. They're still the best, it's a very powerful and impressive product, and the possibility of self-hosting is amazing.

The Auth component itself now has a new name "Auth UI", and lives in its own separate repo. Though originally intending to use it, as I began migrating the code I've found this new component to not work quite as well as I'd hoped, getting in the way more than helping. For that reason, I've decided to abandon it in this guide, and build one instead.

- Functions have a critical bug that prevent us from using in development so we decided to move to our own API servers: https://github.com/supabase/edge-runtime/issues/212

source: https://github.com/supabase/edge-runtime

we needed this to get feature parity across local, the platform, and self-hosting

Refactoring the module loader fixes a few other bugs, such edge functions erroring out when an deno.lock file is already present in the project.

Cold-starts are the time it takes for the “initial load” of an Edge Function. Because the model needs to be downloaded to the Edge Function, could starts can take anywhere from ~2-6s (based on the model). Loading the initial model and building the pipeline usually contributes to it. We are experimenting with the idea of attaching a “read-only disk” of models to our Edge Runtime which mitigate any download penalties. We’ll share more details about these optimizations in a future blog post.

[Supabase engineer & Author of the blog post]

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