1

I cannot find any articles or docs on the web that say that clearly. Are PSR-15 middleware objects expected to be reusable or each server request implies creating brand new middleware instances?

This is important when there is need to keep data in the middleware instance properties and be sure such middleware still will be usable in "event-driven" environments (like reactphp).

Mikhail Karakulov
  • 193
  • 2
  • 9
  • If you can use JSON parser as middleware in different places, why use same code in different classes? It should be re-usable as any other classes. From PSR-15: `A middleware component is an individual component participating, often together with other middleware components, in the processing of an incoming request and the creation of a resulting response, as defined by PSR-7.` - so two components can use same other component – Justinas Jan 28 '19 at 08:11
  • I mean reusability of the class instance, not class source code. The real question is about middleware being singleton or instantiated each time new request begin processed. – Mikhail Karakulov Jan 28 '19 at 08:14
  • the term "component" is unclear. component as class or component as class instance? – Mikhail Karakulov Jan 28 '19 at 08:15
  • *IMO* component of middleware should not keep state of previous request, but can keep dependencies loaded, e.g. DB connection should be single for all calls, while DB query params should not be effected by previous call. – Justinas Jan 28 '19 at 08:33
  • What you need to keep in mind is, that a new server request can be created any time, by calling the `with*` methods on an initial `ServerRequestInterface` instance. Any such new implementation will contain changes vis-à-vis initial object. You can reuse (e.g. share) the same `MiddlewareInterface` instance, as long as its properties will reflect the state of the "newest" `ServerRequestInterface` object passed to it. – PajuranCodes Jan 29 '19 at 00:00
  • @dakis, by "new server request" I always mean not ServerRequestInterface but real new request from client when new request handling roundtrip happens. Creating request modified clones through with* is out of scope, no problems with them. But nothing said about behavior of the middleware handlers, their lifecycle. The whole idea about those PSR-15 interfaces is in interoperability. So phrase "You can reuse" must be reformatted to the "Actual framework where middleware will be running can reuse". Or not? If I miss to add cleanup/reset code to middleware implementation it will be just broken. – Mikhail Karakulov Jan 29 '19 at 05:01
  • 1) Since the phrase cited by @Justinas specifies a behavior, it should be understood as "component as class instance". – PajuranCodes Jan 29 '19 at 17:38
  • 2) Indeed, I meant: "In the scope of **one** web app, e.g. of the actual framework where middleware will be running, you can reuse, e.g. share (!), (e.g. see it as singleton), the same `MiddlewareInterface` instance, as long as ...". Why do I hyphenize "**one**" web app? Because each web app should have its own dependency injection container, responsible with the creation of objects for its scope. As for the life cycle of the objects: all PHP objects are destroyed (by the garbage collector of the PHP engine) at the end of each request-response cycle. – PajuranCodes Jan 29 '19 at 17:40
  • 3) In the PSR sense, _interoperability_ means defining a common interface, implementable in different ways, but respected by all collaborators (individuals, frameworks). So, let's say you have a class method in your app, for which you specify a PSR-7 interface as type declaration. You can inject an instance of the Zend Diactoros implementation for that PSR-7 interface. Or, instead, you can decide to inject an object of the PSR-7 implementation provided by Slim 3. In both cases, the method code will/should work, without requiring any changes. – PajuranCodes Jan 29 '19 at 17:42
  • So, both PSR-7 implementations - Zend Diactoros and Slim 3 - share the same PSR-7 interface... But sharing the same interface by different implementations and sharing an instance of a chosen implementation in the scope of an app (throughout a request-response cycle) are different stories... P.S: I am not quite sure, if my perspective gives you an answer, but I hope it will, at least, help you finding it. Good luck. – PajuranCodes Jan 29 '19 at 17:48

0 Answers0