bref icon indicating copy to clipboard operation
bref copied to clipboard

Make the HTTP request path parameters available to the FPM process

Open dhrrgn opened this issue 3 years ago • 3 comments

This was spurred by #1237.

Currently, there is no way to access the request's path parameters when using the FPM runtimes.

Making these available removes the need to add a router or parse urls if using the API Gateway as the router.

dhrrgn avatar Jul 08 '22 10:07 dhrrgn

Sorry for not answering here. I've been uncertain about this from the start but I should have explained it at least.

The idea of the FPM layer is that it can be used with existing frameworks "as usual". If you want to use API Gateway for routing, then using the function layer makes much more sense. Was there a reason you didn't use the function layer in your case?

mnapoli avatar Aug 20 '22 07:08 mnapoli

Some notable reasons one might prefer the FPM over the Function:

  • Performance: the overhead of starting PHP for each invocation can add up quickly for high throughput functions. The BREF_LOOP_MAX workaround works, but most PHP devs (generalizing here) are used to requests being isolated. This will lead to things like DB connections left open, because people are used to them auto-closing when the request ends.
  • Some PHP features/libraries work differently, or not at all, when run using the CLI SAPI.
  • Opcache: CLI uses file based opcache, which is slower

I think, honestly, the ideal solution would be to forward the entire event to the handler, not just the context.

I may be missing something, but I don't see a reason to limit what event data a developer can get at. If this were a PHP "framework" (for lack of a better term), then sure, being opinionated makes sense. However, Bref is a runtime at heart, and should have very few opinions on how a developer uses it. Not to mention, having the entire event is great for debugging.

dhrrgn avatar Aug 20 '22 08:08 dhrrgn

OK, thank you for the details, for the arguments and your patience (another way to say "sorry for the delay" haha).

I'm convinced, let's do this! Now the only thing that bothers me here is where the new documentation is inserted. Indeed, this is a quite "advanced" feature, for a use case that I wouldn't recommend by default to anyone. It's cool to document it, but I don't think it should be shown at this point in the docs because it will only confuse new Bref users (the role of the FPM layer is kind of to hide the complexity of API Gateway, and make PHP run "as usual").

Here's a suggestion: how about moving the docs to the bottom of the page, under a new section "Advanced routing". Then open the section with a sentence that makes it clear it's for advanced needs, e.g.

It is possible to use API Gateway to perform the routing, instead of your favorite framework. Note that this approach is more advanced and useful for those that do not use any PHP framework.

mnapoli avatar Sep 13 '22 14:09 mnapoli

Closing inactive PRs, feel free to reopen.

mnapoli avatar Mar 19 '24 14:03 mnapoli