[RFC]: deployments using nitro enabling multiple cloud providers deployment

[brendonmatos]

Summary

In short the proposal is to migrate the build system to Nitro (the team call it nitropack by what it indicates) and use it to make edge deployments for multiple clouds.

Motivation

As most edge computing providers aim to support more technologies related to fullstack frameworks, support work is expected to increase dramatically in the near future. I was taking a look in the most recent version of Nuxt (3.0.0) and they use an engine called nitro (github.com/unjs/nitro) which is decloupled from the framework and builds the server for several different clouds. They have a very effective layer of abstraction that could benefit the deployment of RedwoodJS, perhaps enabling cases where we could deploy on the edge in several clouds.

Detailed proposal

Currently supported clouds

• AWS Lambda
• Azure
• Cleavr
• Cloudflare
• DigitalOcean
• Firebase
• Heroku
• Layer0
• Netlify
• Render.com
• StormKit
• Vercel

Are you interested in working on this?

• [X] I'm interested in working on this

[dac09]

Thank you @brendonmatos - this looks very interesting indeed, thank you for raising the RFC

I wonder if the first step here would be to have a simple example (without Redwood framework changes) - that demonstrates that building with nitro is possible?

In my head I'm thinking just having simple node.js scripts that would build the api side (I assume its only for API). What do you think?

A few things to note:

• we currently transform all requests so they look like lambdas (whether you are deploying to a lambda or not) - this is so that you can change between deploying with fastify (render, fly, baremetal) or directly to lambda (vercel, netlify, aws serverless) without needing to change your code. This is a legacy decision, and while we want to maintain the "note-changing-your-code" part, we probably should move away from the lambda part.

I think we should move to a more generic form, such as the Fetch API request/response https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

The code for this sits here: https://github.com/redwoodjs/redwood/blob/main/packages/api-server/src/requestHandlers/awsLambdaFastify.ts - where it transforms a Fastify request to a lambda. The code is only used when you deploy serverful.

• it's not clear to me what the shape of the request and event in nitro is. Would you be able to shed some more light here please?

[brendonmatos]

Hi @dac09!

Some new insights upon brief investigation:

Nitro seems to me like a superset of integrations with storage, cache, cloud providers, file-based routing, with an optimized builder.

Related to conversion: looks like they convert everything to node and then to @unjs/h3 event format.

Nitro: https://github.com/unjs/nitro/blob/a31db233a73cf55cbd58119a0cd4b93bf12c259f/src/runtime/app.ts#L58

H3: https://github.com/unjs/h3/blob/10f40fa30cf0ced9df1c829788cc5100b9b0d15e/src/node.ts#L29-L50

So, it seems that everything that was written with fastify should be rewritten to @unjs/h3 format with @unjs/nitro to support that.

As I said, I don't know much about h3 and nitro. Maybe it would be cool if @pi0 was on top of this

[brendonmatos]

Nitro is now being used by SolidStart https://twitter.com/solid_js/status/1737346535279792292