Combine Slim with Amphp to create concurrent middleware

Amphp (https://amphp.org/) is a very cool concurrency framework which uses generators to yield promises, which are then resolved concurrently using non-blocking IO. My thought was that this can be combined with middleware to support concurrency in the pipeline. E.g., imagine you have an invokable class which returns a generator. The middleware pipeline need to be extended so that when it detects a generator, it will activate the Amphp event loop. I think this can be a rather small change, maybe through a subclass. What do you think?

1 Like

Do you mean PSR15 middleware ? As far as I can see (please correct me if I am wrong) you don’t need SLIM’s middleware pipeline integration considering Amp Http Server ⋅ Middleware. Also, as far as I can see, there is a decent router delivered, so I wonder what do you need SLIM for ?
By the way, thx for mentionning this project, I have been looking for a long time for some properly documented php solution related to websockets and this one looks promising.

hi @tj_gumis!

Yes, I mean PSR middleware.

The linked Amp libs are the opposite of my use-case. :slight_smile: I don’t want PHP to take care of requests concurrently, that should still be done by nginx or what have you. What I want is to, seamlessly, be able to inject a concurrent middleware into a “normal” middleware framework like Slim. E.g. a middleware that does 10 curl calls concurrently or 10 database queries. The default is still synchronous execution.

Let me quote you:

… middleware that does 10 curl calls concurrently or 10 database queries.

I have to admit that request concurrency is not my strongest scope, but what about Guzzle - Async Requests with a How to handle async request concurrency with Promise in Guzzle 6 and this Guzzle async requests not really async? ? That should work smoothly with SLIM, although it does not solve the case of local database queries, but if you deal with api endpoints exclusively, why not? Personally I use Guzzle with SLIM only for endpoints sync requests. It is a decent package with one of the best documentation I’ve ever seen, so maybe you can take a look ? This way or another, I would be really interested in your final approach so don’t forget to share it :smiley: