Migrate function to generic code using Hono and bun

[riderx]

Currently, we have Supabase Deno function who are translated to Deno Netlify function, Cloudflare worker and Node function with a custom script.

This leads to some complexity.

Supabase just released support for npm: prefix.

Hono and Bun start to be stable.

So we can now have only one base code for all functions.

We need to move all the code in a backend folder, with only export of Hono app in each function.

Env should use Hono adapter to work on any platform:
https://hono.dev/helpers/adapter#env

Then the code server implementation should be present in :

• supabase/functions
• cloudflare
• netlify/functions
• netlify/function-edge

Who import the exporter app.

A script should be provided who can create a new implementation.
The script should allow creating :

• Supabase function
• Cloudflare function
• Cloudflare scheduled function
• Netlify function
• Netlify Edge function

He will ask for a name and create a basic hello world server endpoint, with all selected implementations.

It could be nice if the script knows how to add implementation later on endpoint who already exist.

Each time and implementation is added, the required config file is updated ( Netlify config file, Cloudflare, Supabase)

Currently, Cloudflare is implemented in preprod branch but with all endpoints on the same function and with Senoflare.
We want to switch to pure worker thanks to Hono and multi endpoint for easier debug.

This script could become an autonomus CLI in the future

[WcaleNieWolny]

I strongly believe that this is easier said then done. Fundamentally none of the problems solved by our current conversion script are solved by bun/hono/npm: prefix. Those features are nice and all, but they do not make it easier do deploy a multiple runtime edge function.

Let's start at the beginning. Hono does not REALLY have official support for supabase

Second, we have the problem of the npm prefix. That is nice and all but it really does not solve anything. Even if we assume that EVERY package from npm will work on deno (and that likely is not the case) then we still have to account for cloudflare and netlify. Since we migrated from denoflare that means that cloudlfare with wrangler is going to be a problem. It's closer to node runtime BUT there are a lot of packages from npm that just do not work with cloudflare.

If we are going to use 1 package for ALL runtimes then essentially that package has to meet the following requirements:

• Work in deno (supabase)
• Work in netlify edge function (I think it's based on deno (?))
• Work in netlify normal edge fns (It's based on node)
• Work in cloudflare (based on node, but in reality a custom runtime)

Given all that, it might be possible to improve the conversion script (rewriting it for example in deno + typescript for example) but I highly doubt we can get rid of it entirely / drastically improve how it works

[rishi-raj-jain]

@WcaleNieWolny

I whole heartedly and technically agree with that.

@riderx @WcaleNieWolny

What are the runtimes we currently use?

[WcaleNieWolny]

right now?

(-> is when the previous options fails)
denoflare -> supabase edge fns -> Netlify edge -> Netlify normal (node) fns

But once d1 gets integrated into production it will no longer be like this. It will go:
wrangler -> supabase edge fns -> Netlify edge -> Netlify normal (node) fns

I have wrote changed the transformation script to concert the supabase functions into ones that can be run using wrangler. This is because I needed D1 and denoflare did not support d1 locally but the entire chain i think is quite useless.

Honestly the wrangler -> supabase makes sense but anything after that will generate garbage results and unnecessary increase cost. In my opinion this backup (netlify) made senses before we integrated cloudflare but honestly I trust cloudflare to handle our edge fns correctly (without crashing). Before the chain would start with supabase, and supabase had a tendency to crash so the backup was necessary.

The entire code generation is a big mess. There are dirty/mysterious macros (commens) to paste some code, unexplained changes (not documented), easily breaking codegen (recently a lint caused the codegen to fail to detect some of the macros), no typescript, wrongly named folders (cloudflare_workers_deno, this should be something like cloudflare_workers_wrangler) and many other problems

[rishi-raj-jain]

The entire code generation is a big mess. There are dirty/mysterious macros (commens) to paste some code, unexplained changes (not documented), easily breaking codegen (recently a lint caused the codegen to fail to detect some of the macros), no typescript, wrongly named folders (cloudflare_workers_deno, this should be something like cloudflare_workers_wrangler) and many other problems

I definitely know that. I did try doing it all to Hono but yeah it's perplexing.

What are some of things in the queue which might block if I work on something? I'm thinking to do something that abstracts the core. Makes sense?

[rishi-raj-jain]

Would @riderx and you be interested for me to work on something like below:

abstract core of an API to a workflow that does aim at handling all the envs

Step 1. Focus on a single endpoint, and try to migrate that and figure out the basic migration workflow.
Step 2. Rapidly add more endpoints, migrating to the new workflow.

(as from your above response, it looks like it's everything edge & node w/o deno) hence we do need it for every environment.

[WcaleNieWolny]

i think the biggest improvement you could make to this codegen system is the migration of the convert_deno_to_node.mjs to typescript with a general cleanup of the mess that script is.

As for if ridex is interested in this - i do not know.

Right now we are planning to migrate from denoflare -> wrangler. It's already MOSTLY in production but I was to scared to switch prod to use wranger so when Marin has a while he will likely do the switch himself. There might be occasional changes to the migration scripts but nothing big

[WcaleNieWolny]

oh yea, i also have to change the codegen script a bit because this

should be using drizzle but right now it is not

This is the only change to the codegen script that is planned for the foreseeable future