Split into separate discrete packages?

[jakejohns]

I had some recollection of this being discussed, but I don't see it in the issue
tracker, so I figure I'd raise it here. I assume there has been some discussion
on this, so at minimum, I think it would be nice to have the record of it here.

Firstly, I'm a fan of minimalism and the 'do one thing and do it right' ethos.
In my opinion, it would be nice to have this collection split into separate,
discrete packages. Things like the Authentication middleware might be grouped
together, but things of disparate concerns with varying requirements
could/should be separate.

I think the most obvious reason is that a handful of these have real
requirements (i.e. AuraRouter), which are only listed as suggestions. The
ability to actually require the dependency (including version requirements)
seems like an obvious benefit.

Additionally, it just doesn't feel right to me to require the whole thing to
use a single component. It would be nice to glance at componser.json and have
at least some idea of what functionality is being leveraged. It's also strange
to continually get updates which are possibly unrelated to the utilized
functionality.

I also assume (possibly without cause) that release versioning is/will-become
cumbersome with this paradigm. Given two components of unrelated concerns,
should not one be able to change it's public API and require a 1.0 release
without affecting the other?

I would register my vote for separate vendor prefix with discrete packages (eg
oscarware/aura-router, oscarware/auth, etc.). If absolutely necessary, they
could require a common utility package. For those desiring the "all-in-one"
paradigm, an additional package could be created which simply requires the
discrete ones.

Thoughts?

[oscarotero]

Yeah, I had this discussion other times, but not in github, so it's fine.
The original idea of this package is to provide a set of micro-middleware pieces that you can use in your projects. Most of them with less than 100 lines, and only a couple more than 200.
The goal was to be something like underscore or other similar packages that provide a collection of utilities for a specific purpose, in this case psr7 middlewares.

The benefits of the "all-in-one" apropach:

• Easy to maintain, due some middlewares are dependent of others, or share the same traits.
• Easy to install, just one package and that's all
• Discovery: you can play with different middlewares that you didn't use if you had to install them individually. This is specially useful for newcomers or to experimentation.

The benefits of split packages:

• Dependencies: installing, for instance, AuraRouter middleware, Aura.Router package is installed.
• You install only what you use.

I think both approaches are valid, but cannot live toghether. If this package is divided in micro-packages, with the dependencies required (not suggested as they are now), the "all-in-one" package will install all dependecies.

Currently we can find a lot of individual middlewares and I think a good point of this package, is precisely, provide a different way.

That being said, I'm open minded, so if more people prefer divide all, a good solution is use a "psr7-middlewares" vendor, and create a github organization with more people that want to be involved.

[codeliner]

+1 for splitting the package

atm I only use the Payload middleware in my cargo sample. Some days ago a user opened an issue because the sample app did not work. Reason was that the Psr7Middlewares\Middleware\Payload interface was changed in a minor version and I did not recognize it. Here is the related issue and the necessary change

If each middleware would live in its own package one can follow changes more easily.
Besides that it is really a big advantage if individual packages can manage their dependencies. We apply this strategy for our prooph components and it works really well. You can test different versions of dependencies on travis and let each package evolve independent from the others.
The drawback is a decentralized documentation. We solved the problem by using bookdown.io and aggregate package documentation in a meta package. Bookdown.io lacks some features but PRs are on their way.

[wolfy-j]

I might agree on splitting routers into separate packages as having multiple routers in one place seems very unrealistic. However having rest of middlewares together seems cool, being able to connect and play with middlewares is very useful on medium/big projects.

[sander-bol]

Another +1 for splitting. See for example how Zend Framework does this (https://github.com/zendframework/zf2) they have a zf2 package which just groups all their small packages together.

[adamaltman]

+1 for splitting... the main issue I see with splitting is the shared traits, which are used by many of the middlewares. Although, those could also be split into their own repository, and required as needed by the middleware. A meta package which groups the smaller packages together would work fine, for someone who wants the all-in-one, or mainly, I think, a way to explore for new packages and ideas.

+1 "create a github organization with more people that want to be involved"

[hdimo]

+1 for splitting, using right package for right job, not need all packages for doing foe example recaptcha

[mindplay-dk]

+1 for splitting.

Per OP, being able to correctly use require rather than suggests is quite compelling.

Moreover, how would you manage a breaking change in one of these middleware components?

You'd have two choices: major version bump, which will cause conflicts between packages that use any of these components - or breaking semver, which will cause run-time errors.

That alone should be a sufficiently compelling reason to package these individually. (The odds of never needing to make a breaking change to any of a growing number of components? Not good.)

I'd suggestion creating a GitHub organization for the individual packages. Rather than inviting people to PR against a monolithic package, you should invite them to publish their middleware packages under the organization banner.

With PSR-15 coming up (and I'm assuming you're interested, because you've been participating in the discussions) you will need to make breaking changes to every component anyhow, so that should be an opportunity to gradually port these components to individual packages under a new organization-name.

You could invite the community to participate in that effort. I'd be happy to help port some of these - I'm eventually going to need PSR-15 versions of some of these anyhow.

[oscarotero]

Yes, finally I'm agree to split the packages 🎉
The idea I had in mind was the following:

• Wait until PSR-15 is released before port these middleware components under a new organization.
• I've created the organization middleland, but if any native english speaker has a better name, I'm open to change it. As you can see, I was playing with a middleware dispatcher, that requires php7, but maybe it's too early to discard php5?
• Each component may have its own package (for example: middleland/trailing-slash but we could create also metapackages. For example, middleland/path-utils containing trailing-slash, base-path, and other components for path modification. Other example middleland/authentication including BasicAuthentication and DigestAuthentication.
• Some middleware components implemented in just one class could be splitted in various classess. For example Payload that can handle json, csv and urlencoded can be splitted into PayloadCsv, PayloadJson and PayloadUrlEncoded (but all included in one package middleland/payload)
• @mindplay-dk I'd happy to have you in the organization, and any other interested in joining it's welcome.

What do you think?

[mindplay-dk]

@oscarotero "middleland" sounds a lot like a "brand-name". Isn't that also the name of your middleware dispatcher package? That would seem to imply this is middleware designed specifically for that library.

I think that a community effort should have a more neutral name, like e.g. php-middleware, psr-middleware or even psr15-middleware.

(my personal favorite would be php-middleware, since, hopefully, that's what PSR-15 will become: the standard for PHP middleware.)

[mindplay-dk]

(would it make sense to gather not only middleware, but also dispatchers, under a single organization-name? everything middleware-related in one place?)

[oscarotero]

would it make sense to gather not only middleware, but also dispatchers, under a single organization-name? everything middleware-related in one place?

This is why "middleland" (the land of middleware). I know that it's a brand name, but what isn't?

Isn't that also the name of your middleware dispatcher package?

The dispatcher name is simply Dispatcher, but yes, it's included in the organization, using the same namespace. Anyway, this was only an experiment (it's not even registered in packagist) and can be removed (or moved out of the organization).

I think that a community effort should have a more neutral name, like e.g. php-middleware, psr-middleware or even psr15-middleware.

php-middleware exists. And I don't think we could use psr-middleware, because seems a PSR official package (in fact, initially I renamed the vendor name of this package because this. And the problem with Psr15-middleware is whether Psr-15 becomes obsolete and replaced by other specification (ex psr-34).

[mindplay-dk]

Brand-names have corporate connotations to me, that's all. I'd prefer a name that sounds more like a neutral community/group-effort than a product/brand-name, which (to some) could imply ownership.

middlewares is available.

middleware-group, middleware-list and middleware-community are all available, and .org domain-names are available for any of those too, in case we want to set up a community hub or other non-GitHub presence at some later time.

[oscarotero]

Ok, I've created middlewares and invited you (feel free to reject if you don't want to join now). I think the prefixes -group -list or -community are innecessary (at least in the organization name of github).

[oscarotero]

Hello
There's the first version of the psr-15 port of these middlewares, splitted in individual packages and other improvements. You can check it here:
https://github.com/middlewares/psr15-middlewares

[mindplay-dk]

Holy shit, you just did all that work yourself! Kudos! 👍 :-)

[mindplay-dk]

Really, this is incredible work, man! This is really going to help set fire to PSR-15. Thank you :-)

[oscarotero]

Holy shit, you just did all that work yourself! Kudos! 👍 :-)

Thank you. I had a couple of weeks with lot of free time.
I did almost all work but there's some middlewares that I didn't ported:

• CSRF: The current implementation is session dependent. Because there's no a psr for session (I think it should be the next big step) I'd like to use jwt or any other method to be more independent. But I'm not a security expert, so if anyone want to help with this, that would be great.
• FormTimestamp: If the CSRF is based in jwt (so is not session-dependent), I think this middleware is not neccesary.
• LeagueRoute. The current version of leagueRoute is psr-7 compatible but uses double pass to handle the routes. I'm not sure what to do here.
• AttributeMapper: Because the new version store the data directly as request attributes, this component is not longer neccesary
• GoogleAnalytics/Piwik: Not sure if a middleware to insert this specific thing adds much worth.

Anyway, I'd like to use the new repository to discuss about this or other issues.

[mindplay-dk]

My coworker is working on PSR-7/15 components and middleware for cookies and sessions. Should have a release in a week or two. I'll keep you posted :-)

[oscarotero]

Great.
FYI, I have a roadmap with several random ideas of possible new components (https://github.com/middlewares/psr15-middlewares/projects/1)

[mindplay-dk]

Haha, you have my new chrome-logger on there already - I haven't even announced it anywhere yet, you're fast ;-)

That one will have middleware soon though - the package might just come with it, or I might create a separate project under middlewares, not sure; it'll be very small and simple, obviously.

[oscarotero]

I think using the middlewares vendor should increase its discovery.
Btw, I decided to change the list of packages in the README and group the components by type instead alphabetically (security, development utils, optimization, authentication, routers, session, etc...)