Migrate function to generic code using Hono and bun about capgo HOT 7 CLOSED

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

from capgo.

@WcaleNieWolny

I whole heartedly and technically agree with that.

@riderx @WcaleNieWolny

What are the runtimes we currently use?

from capgo.

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

from capgo.

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?

from capgo.

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.

from capgo.

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

from capgo.

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

from capgo.