Middleware around API proxy
Hi all
I have this in my
app.config.json
I would like to add a middleware that runs for all the requests that I receive, including the requests that get proxied.
I tried adding a normal solid js middleware using these instructions: https://docs.solidjs.com/solid-start/advanced/middleware
However this middleware doesn't execute on proxied requests.
I also tried adding a nitro middleware, but that doesn't execute at all.
https://nitro.build/guide/routing#middleware
Is there another way in which I can add a middleware that wraps everything?Middleware - SolidDocs
Fully featured, fully customisable static site generation for SolidStart
Server Routes - Nitro
Nitro supports filesystem routing to automatically map files to h3 routes.
28 Replies
Part of the problem that I am trying to solve here, is that if the external API is down, I have no way of knowing. The other thing is that it would be nice to have logging attached to that proxy request.
The way I see it, the best way of doing this would be to wrap the entire application in a middleware.
when the external API is down don't you get an error when you make the request ?
I get an error on the browser (reporting a 502 or 503), however I don't get anything on the terminal, or on a log that I can use to debug.
do you just want to see an error in the terminal?
and you don't consider the browser as good source of tracing errors?
Well, the console print-out would be step 1. If I can print it on the terminal, I can do more things.
I don't consider the browser a good place to trace errors, as it is ephemeral, especially when a non-technical user encounter these errors. If I encounter an error I would like for it to be logged and e-mailed with as much information as I have access to.
isn't the proxy only a development feature?
the developer is the only user in development
Wouldn't that be the devProxy option?
How else would you access an external API in production?
I am not sure, I don't know start in depth
is it a documented feature?
I got to a fair amount of depth trying to figure it out. The feature that is documented is this: SolidStart uses vixni, which uses uses Nitro in production, Nitro allows for proxying in production by use of the routeRules.
This is why I tried to use Nitro's middleware to try and wrap the proxied requests, but it seems that vixni overrides Nitro's handlers.
So I came to ask here with the hope that I was missing something.
ok thanks for the info.
I did not know how complex start have become
is nitro what you eventually deploy to production?
Yes, that's how I understand it. When you run
npm run build, it calls through to vinxi build. Vinxi then configures a nitro server for you based off your app.config.ts, and nitro is what ends up serving the production application.got it , now one more question
if this is not a documented feature by solid start
what will happen if one day they will stop using nitro?
I don't know, but the reliance on vinxi and nitro is well documented. I also don't think that these kind of what-ifs are really constructive. I migrated my app from Svelte to Solidjs recently. I never asked myself "what if Svelte introduces runes, and starts imitating Solidjs." But when it happened, I made a decision, and I believe it was the right one. So if SolidStart stops using nitro,and it breaks my app, I will make a decision and hope for the best.
my emphasis is on "if it is not documented"
where is it documented how to put your own nitro middleware in a solid start project
if you don't like what if i will stop using what if
Oh. My apologies if I misunderstood.
You can't add your own nitro middleware to Solid Start. I tried it, and it didn't work. That is why I opened the discussion.
What I am trying to figure out is if I can do one of these 2 things:
1. Add a middleware that wraps everything, including routes proxied through nitro.
or if that isn't possible
2. Proxy the external API requests in a different way so that they are effectively covered by the SolidStart middleware.
the simplest solution that come to my mind
is to create a server function in the start project
and handle the proxy / delegation yourself
there you should have better control on what to do when there is an error etc
the built in proxy seem kind of nice, but if you need server side error tracing and nitro does not do that, or allow to do that, this might be a good feature request ( to the nitro project) that then solid start can make configurable
Yeah. I think you are right. There are some footguns in that approach, but I've used it before in another project with a different framework. I was just hoping SolidStart would have something more convenient.
Thanks for taking the time to help out with this!
The built-in proxy is very nice. It is was one of the selling points for using Solid Start in the first place. My other option would've been to make the API the entry-point to my app, and have the API serve a SolidJS SPA. The second approach is probably more conventional, but I like proxying API requests through a frontend framework for some reason.
I am a proponent for separating backend from frontend
If I needed to hide the external api, I create my own api for it and expose that as an independent service. this is typically what I will call an integration api
it might be easier the way you are doing it. but for larger scales this may not work as well.
what will happen if one day they will stop using nitro?FYI: https://discord.com/channels/722131463138705510/1319990584512876584/1320071844392468624
I guess nitro is to stay and vinxi is to disapper?
Turtles all the way down
Basically Nitro is the foundation for Nuxt but TanStack Start and SolidStart are leveraging that foundation; vinxi showed that it could serve a much wider user base, similar to how Vite got adopted as the modern web dev build tool.
TanStack has the potential to "onboard" quite a significant React contingent in addition to Nuxt's existing Vue contingent.
The challenge is whether vinxi can go away entirely as it is currently serving as an adapter layer. For the time being that layer doesn't give 100% transparent access to Nitro features.
oh interesting so it is either gone, or need to be replaced with a better/leaner solution and return the ownership to the solid team.
also if nuxt uses nitro and it does not need vinxi why does solid needs it
Because at the time Nitro didn't fully support what Start needed and vinxi wanted to enable. But some of vinxi's features revealed concepts that Nitro (and Vite) felt were valuable enough to assimilate. So vinxi was driving some innovation in Nitro.
yeah it served its purpose, is there any estimate when vinxi will be refactored out?
Nitro v3 hasn't materialized yet so … and ultimately full integration may never happen—hence “a set of new, leaner [adapter] modules”.
GitHub
Roadmap for Nitro v3 · nitrojs nitro · Discussion #2324
Over the next two months (April and May 2024) (delayed, but more exciting stuff on the way!), we plan to make major changes to some UnJS projects alongside the Nitro v3 release. 🎯 We plan 1 more mi...
vinxi 0.5.3 lists nitropack ^2.10.4 and vite ^6.0.0—but using it is very different from making its features available.
This is very cool. thanks for all the info!