Comments (21)
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
from psr7-middlewares.
Really, this is incredible work, man! This is really going to help set fire to PSR-15. Thank you :-)
from psr7-middlewares.
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 :-)
from psr7-middlewares.
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.
from psr7-middlewares.
+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.
from psr7-middlewares.
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.
from psr7-middlewares.
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.
from psr7-middlewares.
+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"
from psr7-middlewares.
+1 for splitting, using right package for right job, not need all packages for doing foe example recaptcha
from psr7-middlewares.
+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.
from psr7-middlewares.
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 examplemiddleland/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?
from psr7-middlewares.
@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.)
from psr7-middlewares.
(would it make sense to gather not only middleware, but also dispatchers, under a single organization-name? everything middleware-related in one place?)
from psr7-middlewares.
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).
from psr7-middlewares.
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.
from psr7-middlewares.
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).
from psr7-middlewares.
Holy shit, you just did all that work yourself! Kudos! 👍 :-)
from psr7-middlewares.
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.
from psr7-middlewares.
Great.
FYI, I have a roadmap with several random ideas of possible new components (https://github.com/middlewares/psr15-middlewares/projects/1)
from psr7-middlewares.
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.
from psr7-middlewares.
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...)
from psr7-middlewares.
Related Issues (20)
- Error handler middleware assumes stream immutability HOT 1
- Does this project follow semver? HOT 2
- HTTPS terminated at load balancer HOT 9
- Custom Middleware HOT 2
- Closed
- Expose Middleware HOT 2
- JSON Schema incompatible with Slim Framework HOT 5
- Defective unit tests not marked as risky. HOT 1
- JsonDecoder HOT 4
- Csrf middleware is not fully PHP 5 compatible HOT 5
- Slim v3 and DigestAuth middleware is endlessly looping the password dialog. HOT 3
- Question about Cache Middleware HOT 3
- AuraRouter curl stuck at 404 not found. HOT 3
- Adding extra slashes after domain name in url allows you to bypass JWT Authentication
- MiddlewareInterface HOT 2
- https middleware HOT 10
- BlockSpam default path to spammers.txt is wrong HOT 1
- FormatNegotiator - hard coded priorities? HOT 4
- apply http-interop/http-middleware compatibiity HOT 6
- Firewall middleware needs ClientIp executed before HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from psr7-middlewares.