Request pre-processing using JavaScript is amazing! Will I be able to deploy an Astro app on supabase edge functions? I'm building a multi-tenant B2B2C product on supabase that's deployed on a customer's sub-domain, so writing reverse proxy logic in js would be a boon.
We currently block HTML responses on Functions and Storage, but we are considering relaxing that limitation, so that you can host static sites on our Storage. And allowing user-defined functions running on every request to Storage in the edge runtime would get you the reverse proxy logic you are looking for.
Supabase Edge Runtime: Self-Hosted Deno Functions
101–105 of 105 posts
Re: Supabase Edge Runtime: Self-Hosted Deno Functions
#102Earlier quoted context omitted.
I’ve been using Cloudflare workers for a while now and I have to disagree. There are entire classes of problems I no longer worry about with Workers and can just focus on building. My search history is a reflection of that. I’m no longer looking up “how do I put this thing in a Jails or container to limit exposure?” “how do I properly secure an SSH server?” “what is the magic incantation in my NGinx configuration to…
I'm afraid you're trying to make system administration look much harder than it actually is. As an example, adding good defaults to your nginx config is automated by certbot, or you could use caddy. You could run your apps statelessly by containerizing your applications or by simply writing Ansible playbooks and then not have to worry about upgrades - you simply deploy the application on the new server and spin down…
I've maintained large systems and small systems. FreeBSD and Linux systems. I helped build and maintain the serverless platform that hosts the Netflix API. I managed build systems and CI/CD for docker images deployed to k8s and built a package manager to address the instability that is inherent with rebuilding artifacts the way tools like Docker do (which are already a marked improvement over Ansible).
Ansible is essentially logging in and running a series of shell scripts. This works great in isolation, but do it long enough and you'll realize a lot of things you thought were idempotent, atomic, and infallible are not. Most package managers are glorified tarballs with shell scripts wired up to lifecycle hooks during install. You YOLO unpack them into a global namespace and hope for the best. With any luck, when something surprising happens, you can just rerun your script to bring the server back into a good state. But often times the server just ends up borked and you have to throw it away and start over.
K8S somewhat addresses this by maintaining the desired state in a declarative format and comparing the actual state against the declared state in an eval loop. But K8S is absolutely massive and unbelievably complicated. Most declarative systems are non-trivial. The closest I've seen our industry get to this ideal is Nix.
Linux itself is a beast, a reliable beast, but it's a chunk of software I don't think you can just wave your hand at and say "this is easy!" It's easy because it works. When it doesn't work, it's absolutely not trivial.
And this is the core of it: everything you just listed off that makes server administration easy has no delegation of responsibility. They are abstractions that you ultimately own. When they stop working, that's your problem. The Ansible project has no vested interest in the health of your server or the success of your CI/CD pipeline. They have no engineers standing by to help you bring your site back up. That's all 100% you even if you've pushed it down under the covers.
Compare that to my serverless deployments. I pay a vendor to be responsible for everything I possibly can, and everything I end up being responsible for I keep as minimal as possible. These deployments aren't mine, they are my customers'. My customers are small to medium sized businesses (for my fortune 500 contracts, I build the systems you're talking about and a whole lot more). A small to medium sized business can not maintain Ansible. They are mechanics, plumbers, drywallers, etc. They are not Linux System Administrators. And I'm not here to milk them for money, I want to get in, get done, and leave them with a stable system that requires minimal maintenance. I do that by having vendors lined up that are responsible for the system running below my software and those vendor's support contracts are a lot cheaper than my weekly rate.
Re: Supabase Edge Runtime: Self-Hosted Deno Functions
#103Do you have feature parity with Firebase. The main thing I love is getting auth up and running. The Flutter integration is also top notch.
Hi, Supabase Auth Engineer here. We are very close to feature parity with Firebase Auth. Off the top of my head, the 2 features we're missing right now is anonymous authentication and multi-tenancy. We're also gonna be launching something auth-related this week too so stay tuned!
Re: Supabase Edge Runtime: Self-Hosted Deno Functions
#104hey hn, supabase ceo here This is a webserver for Deno. It is MIT licensed, written in Rust, and based on the latest Deno Runtime (1.32+). It can serve TypeScript, JavaScript, and WASM functions. This one is important for local development and self-hosting. For local development, it ensures there is parity between development and production. For self-hosting, it means you can deploy and manage your Deno Functions on…
Re: Supabase Edge Runtime: Self-Hosted Deno Functions
#105hey hn, supabase ceo here This is a webserver for Deno. It is MIT licensed, written in Rust, and based on the latest Deno Runtime (1.32+). It can serve TypeScript, JavaScript, and WASM functions. This one is important for local development and self-hosting. For local development, it ensures there is parity between development and production. For self-hosting, it means you can deploy and manage your Deno Functions on…
Hey! I wonder, why CEO, not even CTO or other Principal Engineer come here in person. Is it cuz company doing so great that CEO has so much free time to spend it on activity of that sort or HN is consider so serious resource to spend time on it even for C level person..
2. We encourage all of our developers to participate in the discussions, I just am usually just faster to respond.
3. Personally: I love HN and the community. I read it every day and learn a lot from it. I'm a developer like most other readers