🚀 Improve the SolidStart Cloudflare (bindings) integration

dario-piotrowicz commented 6 months ago

Describe the solution

Summary

People deploying their SolidStart applications to Cloudflare Pages do not have a proper DX when it comes to accessing Bindings, it would be great if we could find a solution for this.

[!NOTE]

SolidStart is currently the only mainstream fullstack framework that doesn't provide a good Cloudflare bindings DX (all mainstream fullstack frameworks reply on the getPlatformProxy utilities in order to provide bindings locally)

SolidStart prior to the Beta 2 reimplementation had a very good Cloudflare bindings DX

SolidStart applications not using bindings work perfectly fine on Cloudflare Pages

Details

Prior to the SolidStart Beta 2 reimplementation users were able to use bindings via an env object made available by utilities such as createServerData$, for example:

export function routeData() {
  return createServerData$(async (_, { env }) => {
    const { MY_KV } = (env as { MY_KV: KVNamespace }));
    // ...
  });
}

Such bindings were available both during local development and in production.

For local development people would declare their bindings in the vite.config file, for example:

import solid from "solid-start/vite";
import { defineConfig } from "vite";
import cloudflare from "solid-start-cloudflare-pages";

export default defineConfig({
  plugins: [
   solid({
     adapter: cloudflare({
       kvNamespaces: ["MY_KV"],
     }),
   }),
  ],
});

and the vite plugin would, by using Miniflare (2) populate such bindings during local development.

Developers could then also configure their bindings in the Cloudflare dashboard and have them available in production as well.

Since SolidStart Beta 2 however the above API is no longer available and:

there is no way to access Bindings locally
the way of accessing bindings looks like a very poor/hacky DX

In details:

There is no way to access Bindings locally

SolidStart, since Beta 2 is using vinxi under the hood, vinxi is (as far as my understanding goes) a fork of nitro, although in nitro we do have a solution (nitro-cloudflare-dev) to make Cloudflare bindings available during local development, such solution doesn't work in vinxi because of how it diverged from nitro.

The way of accessing bindings looks like a very poor/hacky DX

In the current SolidStart implementation, in server side code the Cloudflare bindings are accessible via the nativeEvent object in the following way:

apiEvent.nativeEvent.context.cloudflare.env.MY_KV

This feels very unpolished and ideally people wouldn't have to use such an API to access Cloudflare bindings.

Also personally I am not sure if this nativeEvent is accessible throughout all the application's server side code (it might as well be, but I haven't really investigated this deeply).

What to do

We should try to collaborate with the SolidStart team and:

find a way for SolidStart application to be able to use bindings during local development, by either re-aligning vinxi with nitro and make use of nitro-cloudflare-dev, or by having vinxi/SolidStart use getPlatformProxy directly (which is the utility used under the hood by nitro-cloudflare-dev)
trying to implement a more proper API for accessing Cloudflare bindings that doesn't necessarily require to go through the nativeEvent, if we can't manage to agree on/implement a better API, the current one could be good enough, but ideally we'd have to make sure that nativeEvent is accessible throughout all the application's server-side code
update our C3 solid scaffolding based on the outcome of the above
update out solid-start guide based on the outcome of the above

[!NOTE] This issue is for tracking purposes and involves more than the workers-sdk repository (but this was what seemed the most convenient place where to put this)

dario-piotrowicz commented 6 months ago

@Tommypop2 if you could help out, especially with points 1. and 2. that would be really great 🙏

I am more than happy to get involved and be part of any conversation regarding potential solutions and decisions 🙂

@pi0 (the main nitro maintainer) has also had conversations with the SolidStart team in the past and might provide great insights regarding the vinxi situation and potentially get involved in conversations/decisions regarding that 🙂

IgorMinar commented 6 months ago

@ryansolid fyi - per our convo we are looking into updating the integration. @Tommypop2 graciously offered to take the lead on this one with @dario-piotrowicz supporting him. 🚀

pi0 commented 6 months ago

Vinxi dev server is not same as nitro's isolated dev-server and that's what makes this inconsistencies.

Nitro v3 will adopt Vite and also built-in Worked isolation based on same model of Node worker isolation. So ideal and stable solution would be that Solid-start/vinxi adopts this and avoids non-isolated dev runtime.

cloudflare / workers-sdk