Hello again, I was reading this lovely article which I’m currently using as my migration strategy from vercel (php-lamda) to fly, and I’m super interested in this method, however I have one or potentially a few questions:
Is there any way I could write the middleware a bit cleaner? I’m not sure if there are events that write queries can put out where we can just attach the header on-the-fly.
My other questions would it be better for me to return a response as shown or potentially do something like:
if (env('FLY_REGION') && env('FLY_REGION') != $primaryRegion) {
return $next($request)->withHeaders([
'fly-replay' => $primaryRegion,
]);
}
Thanks for all your help and awesome work on Laravel Bytes, they’ve been a huge confident boost on migrating away from my previous vendor.
Hi!
Is there any way I could write the middleware a bit cleaner? I’m not sure if there are events that write queries can put out where we can just attach the header on-the-fly.
I’m SURE the code could be cleaner in the middleware in the example there. However I’m not clear about your concern related to events.
The middleware should short-circuit any application logic in theory, unless there are some (write) queries being run during the bootstrapping of the application (perhaps in a service provider).
My other questions would it be better for me to return a response as shown or potentially do something like:
If I’m reading that right, I think your application would fulfill that request completely and then have Fly replay the entire request in another region, which kind of makes the middleware useless (you probably don’t want that behavior).
Returning a response directly (not returning $next(...)... basically tells your application to stop everything and instead replay that request in another region.
Let me know if I can clarify anything there.
Thanks for the super fast response, in terms of the middleware order where are you typically placing this in a middleware stack? Does that have any sort of effects?
In terms of the actual middleware thanks for letting me know how exactly that works, I’ll keep the original way it was written.
It’s generally safe to rely on Middleware to be run early enough to not affect your application logic. However, sometimes there’s a lot of stuff going on in people’s custom middleware, so you should be careful there. Generally, this middleware should be applied early.
That being said, in the setup in the article, we used a named middleware and apply it to specific routes (rather than it being a global middleware). So you have a bit less control over the order of the middleware is being run in that case. I believe global middleware is run before named middleware.
I’m currently trying to play with the fly-header middleware and I’ve seen it currently gives me a 502 response error, how would I go about debugging this? Obviously every laravel app is different, but I’m definitely unsure as to why it would be producing a 502, thanks!
Hi!
I think that would come from your application and not from Fly’s proxy (since in this case, the middleware returns a response to Fly, and Fly just replays it).
Can you see in your logs (fly logs...) if there’s any such request reported? (check just after you get that error perhaps).
Perhaps an app in a specific region isn’t responding / isn’t healthy? (It might say in the fly dashboard).