PSR-11 compatibility (container interface)

[SimonFrings]

In addition to our new DI container (#92) back in December 2021 it would be a logical step to add full PSR-11 compatibility into Framework X. By standardizing the way entries are fetched from a container, Framework X can work with any compatible container.

What do you think about this? Looking for feedback to help prioritize feature ideas.

[nazmulpcc]

I think this is the next logical step. A standard container can be a good foundation for future features. Whatever feature we build next can probably benefit from it.

[SimonFrings]

@nazmulpcc I totally agree with you. Like @clue said, we're just wondering if this is a "necessary" feature or something that will come later along the way. We have lots of feature ideas on our side (like this one) and we're starting to open up discussions for each one of them to get some feedback for better prioritizing. While we see potential in PSR-11 compatibility, we also have some key features we want to release ASAP (like file handling, upload/download, etc.).

[shochdoerfer]

Do it. Since it's not much overhead to add PSR-11 support, that definitely makes sense. The only downside could be that someone makes use of a 3rd party DI container that breaks with your non-blocking mantra. But since that is the choice of the user, that's not your problem ;)

[SimonFrings]

You're right, but maybe it is our responsibility to point these things out. That's also why we often have a recommended way on how to use a new feature. This makes it a bit easier to write documentation sometimes. ^^

[clue]

PSR-11 compatibility is definitely on the longer-term(?) roadmap, so I can definitely see this coming at some point in time! 👍

When we publicly launched Framework X in November, there was a lot of feedback about lack of a DI container support, so we started implementing one with #92 and related tickets shortly thereafter. Ever since this implementation has landed, we haven't seen a lot of demand for other DI containers so far. I'm definitely open to the idea of implementing full PSR-11 support, but I'd love to see some actual demand for this before starting to work on features that happen to be "nice to have".

For instance, what does "PSR-11 compatibility" really mean? I'm a big fan of standardization, but how are we planning to take advantage of this? Should our container implement PSR-11 ContainerInterface? Should we accept an external ContainerInterface implementation? Do we need to support all versions of the PSR? How does it affect our supported PHP version range? What are actual use cases that would be covered here?

WDYT?

[clue]

Do we need to support all versions of the PSR? How does it affect our supported PHP version range?

Framework X currently supports PHP 7.1+. PSR-11 currently provides a number of versions:

• v1.0 supports PHP 5.3+
• v1.1 supports PHP 7.2+
• v2.0 supports PHP 7.2+

If we add a dependency on PSR-11, I assume we want to go with v2 only? If so, we would have to increase our minimum PHP version to PHP 7.2+ as well.

Supporting v1 and v2 simultaneously would require some interesting hackery to make its type definition work, plus I'm not sure there's actual demand?

We could go with an optional dependency and some hackery to only implement the container interface if it is actually installed, but I'm not sure how much I like this idea. WDYT?

[nazmulpcc]

I feel like we can only target v2 and focus our resources. This way we can spend more time on useful features rather than hackery and magic. I don’t know about everyone, but I feel like In a framework like X, I would want to work with all the latest stuff.

[JustSteveKing]

I think the best approach here is to support PSR-11 containers, however have an internal class which will proxy the container calls to enforce the async nature of Framework X and ReactPHP. The problem with just allowing PSR-11 is that it won't fit well into the context of the application with a 3rd party container.

[clue]

Agree, that's precisely also my idea! I've filed this PR this weekend and plan to merge this tomorrow unless anything else comes up: #163

[JustSteveKing]

Agree, that's precisely also my idea! I've filed this PR this weekend and plan to merge this tomorrow unless anything else comes up: #163

So the approach would be that you use the X container by default by you can pass through a delegate container that is PSR compatible. A good way to do it!

[maciejfikus]

Compatibility with PSR-11 would definitely be desirable - currently I do not see the option of interacting with the container, which is quite useful in certain cases. For example, I would like to bootstrap an entry from a container into the global helper.

The second issue - currently I miss a lot of functionality known from other containers - tagging or partial autowiring with the replacement of just one element - something like PHP-DI - autowire () -> setConstructorParameter (...). Right now I have to resolve all entries and pass them myself into new instance.

Until the X container will gain more popular features from other containers, it would be great to be able to switch to alternatives whenever needed.

I would say that X container should implement ContainerInterface and if possible - app should accept other implementations.

[nazmulpcc]

Exactly what I had in mind. Thank you for explaining it so elegantly.

[clue]

@maciejfikus Thank you, definitely valuable input (also below in #159 (comment))!

The second issue - currently I miss a lot of functionality known from other containers - tagging or partial autowiring with the replacement of just one element - something like PHP-DI - autowire () -> setConstructorParameter (...). Right now I have to resolve all entries and pass them myself into new instance.

This sounds like a useful feature and might indeed be something we may want to add to our container implementation! Can you elaborate what you mean with "partial autowiring"? It sounds like this might already be supported with the built-in container like this:

$container = new FrameworkX\Container([
    Acme\Todo\UserController::class => function (React\Http\Browser $browser) {
        // example UserController class requires two arguments:
        // - first argument will be autowired based on class reference
        // - second argument expects some manual value
        return new Acme\Todo\UserController($browser, 42);
    }
]);

See https://framework-x.org/docs/best-practices/controllers/#container-configuration

I would say that X container should implement ContainerInterface and if possible - app should accept other implementations.

You're making some excellent points in #159 (comment) why implementing PSR-11 might indeed be useful!

At the moment, the Container provides internal APIs only that are needed by the App and MiddlewareHandler to function. I'm not sure the App itself should accept other implementations, but I can definitely see the Container accepting another implementation and working as an adapter here.

[maciejfikus]

It sounds like this might already be supported with the built-in container like this

Yes, end result is the same, so it is fine. Mentioned solution is more convenient tho, all you need to do is specifying parameters which are about to change, it takes care of fetching and passing rest of dependencies.

[clue]

I'm open to the idea, but I don't think this is related to PSR-11 compatibility at all? This discussion is already quite lengthy, perhaps you can file a separate discussion so we can take a look at this in more detail? 👍

[maciejfikus]

Actually, the more I code with X, the more it is getting cumbersome with built in Container. Right now it works only in fully automatic way and only in request/response context. Let me show you few use cases which I find critical for an app development with X, and which are related to container.

Global helpers.

// DI
$services = require __DIR__ . '/../src/Application/DependencyInjection/dependencies.php';
$container = new FrameworkX\Container($services());

// APP
$app = new FrameworkX\App($container, \Domain\Common\ErrorHandling\ErrorHandler::class);

// DICTIONARIES
//$dictionary = $container->callable(Dictionary::class);
//$dictionary(new ServerRequest('GET', '/'));

// ROUTES
$routes = require __DIR__ . '/../config/routes.php';
$routes($app);

$app->run();

Dictionary class is making a call to external api every 1 hour (loop interval) to load into memory some dictionaries I need pretty much all the time. Another use case could be some global functions to access app config class. As you can see, due to lack of something like $container->get() I built a workaround to fetch entries from container. Sadly, I had to use internal function which is probably not the most performant solution in this case and wrap it with fake request and make my class invokable.

Testing
In my TestCases I would love to be able to fetch some entries from container.

External tools
There are a lot of essential packages which accept ContainerInterface in order to load its dependencies. One of the examples can be symfony/validator, which has a container-aware factory for constraints. I use it for input validation, which I guess is a pretty popular choice.

Internal tools
I would love to see X\App using container to fetch its dependencies like ErrorHandler. I assume the main target of X is an api microservices, and the only available error handler returns only HTML responses and is not configurable at all. Having it integrated with container would allow us to pass our own implementation.

[maciejfikus]

@clue, thanks for an answer!

What seems to be a major problem with implementing PSR-11? Looking at the current implementation I would say that implementing get(), has() should be fairly easy, it is pretty much done with and within load() function. At the first glance set() shouldn't be hard as well, however I am not sure how it would cooperate with async world. Am I missing something?

As for other examples of external tools, next one that comes to mind is a command bus. Most of popular implementations use container internally to instantiate handler classes. Haven't found an acceptable way to workaround it yet.

For internal tools – separate discussion is definitely a way to go.

Tbh, I am under a little pressure as I picked X as a framework for a new high load microservice in my company, had hope to prove to my colleagues that async php is a thing. Being aware that it is still early beta, I assumed there is everything I need to begin. Sadly, current state of container is killing me – is there any hope for at least get() method in the nearest future? As async php is relatively new concept for me, I don't feel comfortable to contribute to core stuff just yet, however based on provided examples I am pretty sure it would be useful not just for me.

[clue]

@maciejfikus I'm currently leaning towards accepting (rather than implementing) a given container instance implementing ContainerInterface for internal use in X. This way, you can use any container implementation of choice that would provide you with your API of choice. Using this container to get() an instance should be trivial.

Considering the minimal code changes required, I agree implementing PSR-11 is relatively easy. The question is really more: Should a framework such as X really require this interface? I completely agree that container interoperability is a nice feature and using a container inside X can be super useful (as outlined in #89 and linked tickets), but I'm not so sure if and/or how we should expose this interface. This would mean we would have an additional dependency (Container implements ContainerInterface can't be optional without hackery) and also that we have to increase our minimum PHP version for PSR-11 v2.

Even if we would implement ContainerInterface, I can see some use cases that would want more control over the container or perhaps use some custom configuration format (YAML anyone?). It's my understanding that providing an interface for more advanced (niche?) features would probably be better rather than trying to cover all use cases in X itself. I think this aligns perfectly with our "batteries included, but swappable" philosophy.

WDYT?

[maciejfikus]

The question is really more: Should a framework such as X really require this interface?

I would risk saying yes as it is pretty minimalistic interface, however as long as we can use external implementations of PSR-11 through some kind of bridge, I think we could ignore interface requirement.

I think this aligns perfectly with our "batteries included, but swappable" philosophy.

Totally agree. As I mentioned a "bridge" between our container and PSR-11, all we would need at the moment is a possibility of building such bridge rather than already providing it directly.

we have to increase our minimum PHP version for PSR-11 v2.

If we go towards bridge concept it doesn't matter anymore, however minimum PHP version is separate topic. Sooner or later we will encounter bottlenecks of lower php versions and maintaining workaround for them will get costly. X is new framework, so most likely it won't be used for exsiting, legacy apps. Having this in mind, I would go with newest PHP version (max one before) until first release is done. After that we could consider whether LTS versions are fine or not. Even symfony/laravel are already bumping to 8+ with new releases.

[clue]

I think this aligns perfectly with our "batteries included, but swappable" philosophy.

Totally agree. As I mentioned a "bridge" between our container and PSR-11, all we would need at the moment is a possibility of building such bridge rather than already providing it directly.

I've filed a PR this weekend and plan to merge this tomorrow unless anything else comes up: #163

[maciejfikus]

@clue, great to hear! Simple yet effective solution, good job!

[clue]

Good news, Framework X now supports the PSR-11 container interface to pass in custom containers! 🚀

Documentation: https://framework-x.org/docs/best-practices/controllers/#psr-11-container-interface