Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
morning everyone so before we get started how people have no idea what PS are seven is ok about maybe a third of you how many people have used PS are seven okay much smaller group of people how many people that know what piece are seven is think of PSR seven
is going to be massively important to PHP okay about same number of people awesome hopefully by the end of this talk everyone will think that PS are seven is going to be awesome so since a lot of you aren't even really aware of what PS are seven is PS
are seven is the HTTP message interface PSR how many people are familiar with fig now okay a fair number of people they brought things like PSR 0 PS are for unhappily brought people PSR one and PS are too how many people are fans of PS are one and PS are too
how many people hate it because of the tabs vs faces thing ah awesome well you're all symphony developers most likely so you're probably already familiar with symphonies CS so it's probably not a big deal there are a lot of people out there that
don't like it though so PS are seven tries to solve a couple of problems and it solves two of them we're going to focus at first on the the server side of the problem so a little bit about myself I've been programming PHP since about two thousand
five somewhere around there like full time doing PHP development around two thousand eight I got pulled on to a project that was heavily involved in spring framework and hibernate in Java how many people use spring framework or hibernate okay handful of people
so i really liked what I saw there with the whole servlet thing I like the fact that there was this httprequest object that sort of encapsulated the the state of HP requests so because i like the right frame works i decided to bring that back into my PHP world
and i create a little framework called halo which no one should ever look for this if you look for this i will probably cry but it's still out there if you really want to find it and I had an HTTP request class that basically brought in a bunch of stuff
that represented the HTP request and i created a little dispatcher utility that would basically take all of the super Global's and create this object for me so I thought I was pretty special I thought it cool no one ever saw my code because I was kind
of a lone wolf but it was it was fun stuff and I was really happy about it but after a while I realized that spending time writing a framework was taking all of my time and I wasn't actually getting any applications written so I started shopping around
for a replacement for my framework and I ultimately decided to go with symphony because symphony felt very familiar to me turned out they had a request object to I wasn't super special the constructor looked almost identical to what I was used to already
anyway and they even had a factory method that did identical to what I was doing was shoving all the super Global's into this request object it really I turned out that I didn't look hard enough because almost all of the frameworks had this same sort
of pattern zend framework has the same sort of thing it doesn't have a factory constructor necessarily but it does say if you didn't pass these things in get them from the super Global's or has a similar approach I haven't checked all of them
but I'm guessing most of the bigger frameworks that have sort of components at this point have this same sort of thing where they have a objective the request and they all pretty much have the same sort of thing for responses as well so if you look at
the response object fours and response object for symphony they're going to be somewhat similar they have the same thing in common it's sort of what we've seen over the last I don't know maybe ten years or so is PHP developers have started
to prefer abstractions over dealing with the super Global's so people you know us we've all looked at this and said you know what I'd rather pass around this object rather than looking at underscore get underscore server it's just easier it
makes more sense and since I had sort of a negative impact on the ecosystem for bhp this is because you start getting vertical silos for Zen programs Symphony programs liberal programs cake programs if you start writing code around this htp abstraction they
don't go very well to the other framework so if you write a controller and one application it's going to be tied to the request object for whatever framework you're in one of the big exceptions that I've noticed was that Symphony to sort of
didn't fall into that trap is badly because of the way that they had broken down the components the HP foundation component in HP Colonel component made it possible for more applications and more frameworks to sort of work together a little better they
could base their applications on the minimal amount of symphony code that they could so that you can start writing a controllers that worked both in symphony and silex you could also get it working in a drupal and anything else that worked on HP foundation
so a group of developers we're sitting around on the silex channel and started to wonder what it would look like to start passing around information at the HP layer instead of you know dealing with these framework silos that's pretty much where stack
PHP came from how many people were here for the stack PHP talk last year handful of people okay how many people have used stack PHP are used in some way okay not as many people as I was expecting I asked that question at PHP benelux and the entire room raised
their hands so one of the interesting things I've seen about stack is that it's really hard to get a grasp on who's using it nobody talks about it every once in a while we'll come up in a blog post or some sort of conversation but it's
not only an anybody advertises hey I'm using stack or stack is awesome but a lot of people tend to use it it's just really hard to to see who's doing it for example laravel for laravel for every level request served three stack middleware I was
a cookie garden or a couple of others so everybody who was running label for didn't realize it but they were actually using stack middleware behind the scenes so the other problem that PSR addresses is a similar problem but on the client side it's
a little less fragmented but the HP client applications and prob libraries are still suffering from the same sort of problem so if you look at like say the geocoded project they have to either make the decision to make people use the htp abstraction client
that they want like if so you build something based on guzzle that means that your users have to use guzzle as well or you have the right adapters which apologize for this is the screens got off a little bit you know if you want to write a curl adapter you
want to write a guzzle guzzle adapter bundle a buzz adapter you know basically you'd have to provide interfaces for every single possible HTTP client implementation that you want to support which is in a very scalable solution this means that every single
library developer needs to be able to write their own adapters their own interface for writing the adapters for all of these things that maybe people will want to use it's just not it's not a very good place to be in a lot of ways it's very similar
to what happens on the server side as well so the problem the PS are seven addresses is the fact that these are all based around the simple HTTP message concept and that should really be a commodity there's no reason that you should have to tie yourself
to a specific implementation of parsing HTTP messages manticore PHP does that on its own already so we shouldn't have to say we're just symphony developers building a symphony to application and we're using HP Colonel interface we should be able
to say we're writing PHP applications and here are the messages here's the request here's the response whether you choose to use symphony ores and or laravel or whatever application you want to use that should be up to you as a developer not dictated
based on the fact that hey I'm writing a symphony app now all of my code has to be locked in the symphony so how do we get there how do we get to PSR seven as we already talked about this game from the framework interoperability group that's PHP fig
their whole idea is interoperability between frameworks so something like PSR seven is a great fit for what their goal is these are seven started its life back in 2012 Benjamin a burly proposed a relatively modest concept for creating a standardized client
interface so however you get the client didn't really matter but once you had a client you'd be able to feed stuff in so this was get around that at that time what seemed to be like low-hanging fruit of the client I don't want to have to write
adapters for guzzle and buzz and curl and all these are the things I want to have a client that you pass to me and then I can just get request of a tear post request to it or whatever I needed to do so this marked a really great debate but then I think PSR
1 and PS are two came into play and sort of sideline the discussion during the discussion a lot of things came up that you know the client interface wasn't going far enough some people wanted to have an actual request object or an actual response object
and as soon as people talked about that they said wait server-side has request in response objects so the conversation got really complicated pretty quickly and fig itself just got sidelined for a little while it wasn't until the very end of the year that
Chris Wilkinson decided to come in and say hey let's take a look at this HTTP proposal again and he sort of distilled the discussion that had happened months prior basically saying that what we're really looking at here is the htp messages we need
to do that first before we try to build a client a client interface or a server interface and when he proposed was not all that dissimilar from what PSR 7 turned out to be but it is it is definitely different so if you look at the there was a common message
interface that both request and response shared request interface kind of extended a little bit I gave it a different constructor signature and the response interface again was just a little bit different than the the core and core message interface and then
things got stuck for a very long time so this was the end of 2012 it wasn't until at the end of january 2014 that things started to pick up again mad at point p PHP fig had a better workflow in place so that you knew when PSRs were going to get numbers
and whatnot so PSR 7 was assigned PSR 7 as the number in January of 2014 and Michael Dowling the author of guzzle had sort of picked this up he was he was running along with the project and said you know what I've decided now that that ghazal would benefit
from this I think everybody would benefit from there being a common client interface so he ran with that until people started to push back again and say you know we really needed this to be a client interface maybe we can do a client interface or sorry a server
interface in addition to a client interface and the the number of interfaces like doubled it got really complicated really fast and Michael sort of took a step back and decided at the end of August you know I'm not going to do this anymore I want this
for guzzle I don't really care about the server side and you know he was getting hit from all angles a lot of people were coming in with different ideas so he just sort of wanted to step back for a little bit so at the time I was one of these sponsors
[ ... ]
Nota: se han omitido las otras 5.882 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.