Taylor Otwell — Laravel: A Guided Tour — php[world] 2014

all right so I guess it's time to get started here my name is taylor ott well I wrote the laravel framework a few years ago and this talk is about kind of how laravel works under the hood so it's a little bit more of an advanced talk than i've done in the past I think but I've tried to break it down into little pieces so it's easy to keep up I'm a little bit about me I am a lifelong or kanzen I'm from Arkansas I graduated from Arkansas Tech University in 2008 I started programming my professional programming career doing enterprise net and legacy COBOL so we had like an asp.net MVC front-end that pipe to a COBOL back-end on a mainframe so it was a weird mix of new-school and very old-school and then in 2011 I wrote laravel because I had some side project ideas that I wanted to flesh out just like some different startup ideas and it's a little tricky to host.net on your own it's more expensive it's more complicated than hosting PHP so PHP was kind of a natural choice in terms of language to use that was easy to get going and then I joined user scape in 2011 so Ian Landsman my boss he saw laravel this is back when laravel was was not very popular and he thought it looked cool and he wanted to bring me on board to build some new helpdesk products so I've done that for the past few years and at the end of this year I will go full time on laravel and working on laravel and laravel forge which is a server provisioning tool I also wrote a book which you can have for free it's lean pub comm slash laravel and the coupon code is PHP world one two three I put a hundred uses uses on the coupon so I think that should be enough but if it's not just let me know all right so about Lera bells philosophy I'll kind of like lay some groundwork first before getting into the code and stuff we have this cheesy motto that's developer happiness from download to deploy and that means a lot of different things to different people so some goals are we aim for simplicity which who doesn't I mean everyone's trying to write simple code and maintainable code we have minimal configurations so like if you download laravel and you install it you don't really have to do a lot of configure configuring out-of-the-box to get things to work things pretty much work how you would expect out of the box so things like authentication and you know logging people in and sessions and even like email and queues it's pretty easy to configure with maybe just one or two options laravel has a has a real terse in text so there's a lot of methods there's hope almost any methods that are two words they're almost all one word like redirect to or off check or queue push you know it's very simple syntax and that makes it very memorable and easy to learn we also have a lot of kind of powerful infrastructure that was kind of new to PHP frameworks like Q is a good example you can push a closure bottle to a queue you can use various cube backends we have a powerful ioc container which i'll talk about in a little bit and we embraced the PHP community so laravel currently exists 21 community packages that are not written by us that includes nine symphony packages and then a host of other packages so that's things like symphonies routing component their console component we use carbon monologue swift mailer all like you know top-of-the-line PHP components from the community and that really takes a big load off of off of me and the rest of the laravel community because we can kind of focus on our stuff which we have an ORM or authentication system or cue system and let let other people worry about those components so when people a lot of people will mention like they like to glue a lot of components together and that's really like what laravel is it's a glues a lot of the best PHP components together into a usable framework and then kind of sprinkles our own flavor on top and some of our own components okay so just to give a few examples of what layer bail looks like if you've never seen it before it does do dependency injection by default on all controllers and cue handlers and event handlers and most other things so simple when I say simple I don't necessarily mean stupid I don't mean the absolute most basic way to code I just mean simple and intuitive ways to code so if you type in something on a controller it's going to be automatically injected by your dependency injection container you don't really have to configure anything so you can just ask for a class and it will be injected in you can also do this on methods select right here I can type in this create photo request which might have some validation rules and that will be injected in automatically as well so some pretty powerful features that let you build more testable and flexible code there our ORM is an active record implementation so this would be in contrast to something like doctrine which is a data mapper but just an example of the syntax so you can get an idea for what it looks like if you haven't seen it you can just say I want to get all photos with comments so that would be like an eager load so pull it all the comments for these photos in you know two queries instead of n plus one queries and where the user ID is whatever and then get all those photos and then you can real easily convert those to Jason so laravel is really nice for working if you're doing like angular work or you're doing a JSON API laravel is is really nice to work with in that in that scenario for routing it can also look a lot like Silex or another kind of simple router so you can just pass a closure into a route declaration and that will be run when that URI is called and then I could just return out an eloquent result which will be automatically converted to Jason because it implements the Jason serializable PHP interface all right so we also have a few other things that are not usually considered core framework features so this is an optional package called laravel cashier and it provides a subscription stripe subscription management for your users so you can subscribe people to plans you can swap plans which handles prorating the prices you can add coupons you can do a lot of different things and then you can check if they're subscribed and it's all a very fluent simple interface so if you're building if you're building like a noose a startup subscription billing is really like a pain in the neck and even though the stripe API I know it like sounds developer friendly but it has a lot of weird quirks in terms of how prorating works in terms of you cancel a subscription most likely in the human world do you want to continue that subscription until the end of their billing period so they get the rest of their time stripe doesn't have a big concept of that or it's not very intuitive so laravel cashier can really help alleviate a lot of those that weirdness and stripe system all right and this is not Larry Bell specific really you can use this with any with any of your other projects there's also a lot of other a lot of other things in the Larry Bell ecosystem so to speak so a lot of surrounding tools and products there's laravel homestead which is a vagrant machine and you can use that with things that aren't laravel so you could use that with WordPress or Drupal or symphony or Zend or whatever it's just a nice PHP virtual machine if you haven't used bagrat definitely check that out it will make your development life a lot easier because you don't have to muck around with your your your main operating system Larry about forge which is I think I was kind of a poor man's Heroku it is a $10 a month service that can provision servers on digitalocean Linode and then any custom VPS so like Amazon or Rackspace or anything like that and for $10 a month you can do unlimited verse it's a little different than Heroku and that you still own the server yourself it's not like a fully managed infrastructure so that's why the price is lower and you know Heroku is price you're paying a premium for them to manage it and stuff so it kind of depends on what you want but it can be a helpful tool laravel elixir which is a simplified gulp and then we have Lera castes which are video tutorials and then Larrick on Alaric on EU so if you're not familiar with laravel that's kind of a rundown of what it's about but this talks about how does it work so we're gonna start where Yoda would start which is the ioc container and to talk to them to start with the ioc container we first need to talk about dependency injection and dependency injection is a big word for something very simple and basically it is instead of doing something like this this top code example where we're creating a MySQL connection right in the constructor of this class we just want to pass a MySQL connection in that's really all dependency injection is okay so why do we want to do that to use another example say we want to send emails from a class we were going to pass a mailer in because it's going to let us easily test this code so right here I can mock that mailer I can set some kind of expectation that should be called so I'm going to say when I run this method on this service I expect the mailer to be called once the send method and then I can pass in my mock implementation into the service so when you use dependency injection you get a lot of benefits one of them is this this is it's easy testability another one is easier to swap implementations and it's also makes your code more explicit so to speak so if I'm consuming the code I know that it needs a mailer as obvious that this is doing some kind of mailing stuff it's not kind of hidden under the API that makes sense but you don't need a dependency injection container to do dependency injection it's just a convenience tool it just makes your life easier you could do it all by hand so you could pass all your dependency manually into every constructor that would work fine that would be dependency injection containers are nice because you don't want to have this all throughout your code it's just inconvenient so say you have a new discount broker needs a new repository needs an event dispatcher the longer needs an email driver which is an SMTP thing it's just a hassle so containers can build these kind of complex object graphs for you and can automate a lot of that throughout your code has anyone ever used the ioc container okay very number of people okay there is another way to use a container a service container which is called service location so in this scenario you would pass a container into a class in the constructor as you can see and then say our vacation Booker is going to book a vacation for a certain hotel and dates and it actually when we call that ask the container to give it a mailer this is this is probably still testable but it hides the dependencies of these classes so that they're not very obvious to the consuming code and your code is kind of like lying at that point in a way so you probably you probably want to avoid this and keep your dependencies more explicit through dependency injection all right now to get laravel specific let's talk about Larry Bell's ioc container and what it can do all right the ioc container is in this aluminate container component which really has no other dependencies you can pull that in and start using it with any project or even just in a plain PHP file just to tinker around with it now let's pretend we have this SMS notifier in our vacation Booker and our vacation Booker takes the SMS notifier in its constructor we're going to new up a container instance and then we can just call container make vacation Booker and this is this is the auto resolving capability of Larry bells IOC container when I ask for that class it will use PHP reflection libraries to read this constructor right here it will read that needs an SMS notifier and it will say okay I need to make that and then pass it in and it will do that all the way down the chain you know if that has a dependency it will read its constructor so this is a really powerful a handy feature because if you have a class like a controller or some other domain service that needs dependencies I can just add it to the constructor I don't have to go configure anything else so it's a really handy feature to have and the same way I can take away dependencies and not have to worry about configuring anything okay so that's the reflection based approach to resolving dependencies there's also a second way to configure the container which is registering closures I can say bind I'm going to bind something in the container called vacation Booker and when I need a vacation Booker I want you to call this this closure this anonymous function and whatever that returns is going to be my vacation Booker so in this in this example the container will be passed to your closure so if you need to resolve any other dependencies I'm just going to return a new vacation Booker and then make my SMS notifier out of the container or whatever else I need to do so you can do whatever you want in this closure to build this object okay so this is a more manual way to configure the container so it's not going to use the reflection at this point when you need a vacation Booker you can also do Singleton's or some containers called them like shared instances where say you only want one vacation book or instance throughout your whole application or you only want one logger or one email or you can tell it that you want that to be a singleton and after it creates that first intent instance of the vacation Booker it will use that same instance on subsequent requests to the container for that type okay the container can also bind interfaces to implementations so I can say I want to bind this interface to X implementation so say so remember our SMS notifier say we had a notifier interface and we had an email notifying SMS notifier in a smoke signal notify or whatever we could say bind notifier interface to SMS notifier anytime a class needs a notifier interface i want to use this implementation that make sense so that in this example you can see this something class needs some interface and I'm telling it to use some implementations so that when I make something it's going to use the implementation I tell it to use when I need that interface any questions on that stand with me okay the thing Symphony people always ask me about in this scenario because this is something they do a lot in symphony what if you need a different implementation somewhere else so what if I need the SMS notifier in my vacation Booker but I want the email notifier in some other service so you can do contextual container stuff where I say when vacation Booker needs a notifier interface give it the SMS notifier so a very simple very fluent interface for configuring different implementations for different services all right now this was all illuminate container this is not necessarily laravel stuff this is just Larry Bell's container which you can use in any project so now I'm going to move to you know laravel specific how laravel works we need a place to put all this container stuff the layer of a framework puts a lot of its own stuff in the container the router the event dispatcher the exception handler the email stuff all that's in the container then your application puts all its stuff in the container so your vacation business has the vacation Booker and your notifiers and all that and you need a place to register all this stuff and the kind of bootstrap that application and so lerigot has this concept of service providers which if you use Silex is basically an identical concept as silac service providers so what a service provider does is it can kind of group these these ioc bindings these container bindings so let's say I'm using the react database I might have a react service provider which binds that react connection into the ioc container and in my say it binds a few other react related things into the container and it does that inside a register method which will be called by the framework when this service provider is registered with the framework the boot method is called after all other service providers have been registered so the whole framework is bootstrapped and this lets you override any other container bindings that might have been bound by the framework or any other providers so unless you kind of modify the ioc container at that point okay so what that looks like in laravel terms is say we have a laravel application it has a register method which you can give it a service provider instance or just a string class name of a service provider and that's going to call that register method so now our react connection is going to be bound into the container and then we can ask for it through the container make method okay so that service providers and they're basically just a convenient way to add functionality to add slices of functionality to your app so you might have a react service provider maybe laravel has a mailer service provider has a routing service provider as a cue service provider so kind of every slice of functionality that Larry Bell has there's usually a corresponding service provider that gives you that functionality into the container so that you can ask for it ok so now I'm going to talk a little bit how all this IOC service provider mess comes together to really be the core of how laravel works and first let me show you the Larry Bell directory structure this is this is what the root directory would look like on a fresh laravel application and your app directory would be your code your controllers your your services your model your domain model all that is an app bootstrap basically creates the application and registers to compose there autoloader stuff so it's really just two files it's two very simple files the config directory has you know your your authentication config in your mail configuration maybe some debug configuration stuff like that database has all your database migrations and your database seeds layer belt database migrations look very similar to Rails database migrations have a very fluent syntax and works with my sequel Postgres sequel server SQLite public is going to be like your public images your index dot PHP that kind of thing your web accessible directory resources are several things it's your CoffeeScript your less your sass your templates your language files like if your site is multilingual your language translations and stuff would be in there storage is where laravel writes kind of like a kind of our directory it's kind of like a rushed temporary files and caches and logs and stuff like that and you can also write stuff here if you want and then your test directory contains your unit tests your acceptance tests or whatever ok so let me let me dig down one level into that app directory and inside that app directory you have an HTTP folder which contains your controllers your middlewares your requests and then you have a console folder and then you have providers and the best way to think about this is HTTP in console are just two interfaces into your app so I can access my app through HTTP through the web or I can access my app through the console through the command line they're just too light translation layers into your real application if that makes sense and then your providers directory has your service providers that we talked about earlier so that's where things will be registered into the container and then how you structure the rest of your application or how you structure your domain TM is up to you and these are just light translation layers into that domain if that makes sense so you can add an infrastructure folder or a services folder or however you like to structure your app this is just a psr-4 namespace folder so you can do whatever you want in there okay now in the config directory there's a very important configuration option called providers and this just lists all the providers that we want to be registered with the framework when it when it boots so as you can see here there's a there's an awesome provider cache service provider and there's a long semi long list of providers that that are under there but those provide those services into the container and you can add or remove these as you want and that's going to add or remove features from the framework so if you install a package that provides a service provider you install a react package database package you might add that react service provider you know right here under your service providers and that's going to make that stuff available to you so providers add the features in a very literal sense they add all the features to laravel okay so let's pretend we got an HTTP request then we're going to walk through it from beginning to end so where it starts is in public index dot PHP so our quest comes in and you're either Apache or nginx configuration is directing all requests into index dot PHP so this is basically like a front controller pattern which is common in most frameworks nowadays okay and this is literally the real code this is all the code that's in that file I just remove the comments and what happens is we're going to register the autoloader and then we're going to get our app instance which is a container instance the laravel app is just kind of a powerful container and then we're going to make what's called an HTTP kernel and we're gonna pass it the request which the illuminate HTTP request extends the symphonie HTTP foundation request so if you're used to Symphony all the same methods are of course available and then that's going to give us a response we're going to send it and then we're going to terminate the application which kind of gives you an opportunity to do anything like after the the response has been sent to the user so log something or whatever okay so this kernel this kernel is very important so I'm going to dig into that next and what it does is first at bootstraps the application this is these are like very foundational things and it's literally you're just going to loop through this class of bootstrapper so this array of bootstrappers and it's going to make them and then call the bootstrap method passing itself in and these are very simple named classes and they're very like kind of action word classes so the first one is detect environment bootstrapper and that's going to detect are we it's going to read the DMV file from your folder is going to set the application environment to like local or production or staging you know that kind of thing it's going to load the configuration so your configuration files so that it it has all that it's going to set the exception handlers and then you know of course two very important ones there may be the most important ones in terms of how laravel works or it's going to have a registered providers bootstrapper and then a boot providers and those correspond to those two methods on our service providers so register providers is going to loop through it's going to loop through this array of service providers and call register on each one okay so that's what registered providers us and then boot providers is going to call boot on each one after they've all been registered so at that point your app is ready everything is in the container everything has been configured the exception handlers are set up we're ready to handle a request okay so like I said that that load providers bootstrapper is literally just going to iterate through those providers and call register on each one that's all it does and at that point we're ready to handle the request everything is in the container the router is ready event dispatcher is ready everything and it has this kind of real fluent syntax right here where it makes a new what's called a stack and they says I want to send this request through this middleware and then I want to dispatch to the router so this is this is just copied and pasted from the HTTP kernel in the layer bellecour any questions so far before I transition to Middle where yeah the question was do I still have a deferred property on a service provider and the service provider concept to give you some background like I said was inspired by Silex however one issue with that implementation in large applications is say you have 30 serviced writers or 40 service providers that can be time-consuming to load on every request and you don't need every service provider on every request for example like that react service provider I don't need my react database connection on every request so you can actually mark a service provider and affirm and what that means is laravel will not actually register that service provider until you need something that it provides and it keeps a manifest a JSON manifest of every service that every Saoirse writer provides so that when you ask for it it knows what service provider to load so a lot of core search writers are deferred so I think the cue service provider be a good order the male one those are deferred so those aren't actually loaded until you need the queue or you need an emailer so it's a performance tweak all right HTTP middleware is basically this picture this is a good way to picture HTTP middleware and if you can see the layers kind of around this like core rock picture this rock is being your your application and each of these lines is kind of a middleware and so we're our quest is coming in you know and it's coming through these layers and right here might be an authentication middleware and right here the request is going to get caught and the authentic authentication middleware is going to say are we authenticated if it's not it's going to send out a response it's not gonna get any further into the app if it is authenticated we're gonna jump to the next middleware which might be CSRF token validation or verification if that's invalid we're not going any farther so it's these little filters so to speak on the way into your application okay like little HTTP layers they can intercept and interrupt the HTTP request/response lifecycle and in laravel it ships with five or six middlewares one of them's authentication CSRF token verification are we in maintenance mode you know so it shows like we'll be right back screen to your users those are all middleware and what they look like in code is pretty simple they just have really one method that's required don't handle and it receives a request and then it receives a call back and this is the authentication middleware so I'm basically I'm gonna type int the Authenticator thing class and it's going to be injected automatically because all middlewares are resolved out of the ioc container though we learned about at the beginning so I've got the off implementation I'm going to say are they a guest if they are I'm going to return a redirect response right here they're not going any further if they are logged in that I'm just going to pass the request to the next callback on the chain just further down the line and this middleware doesn't need to be concerned about what's next what's further into the application it just passes it along so that makes sense it's a little tricky at first but it's a pretty powerful and simple concept and it's it can be powerful because in PHP we have like PSR 7 coming up as a as a fig standard which will give us a standard HTTP request interface and the reason this isn't type in it because I I knew that was coming and didn't want to lock it down yet - any specific implementation but say we have like a chorus middleware that sets certain response headers for Korres and Ajax access and all that that could be shared across a lot of your applications or across different frameworks or even systems when we have a common request that we're all using you know across symphony or Zend or laravel or whatever alright so that's that's basically how an HTTP request works in laravel now the other way never we have the HTTP folder in the console folder so the console command looks like this it looks very similar we register the autoloader we get a new application instance and then we have a consul Colonel Colonel instead of an HTTP colonel and this has a handle method as well just like the HTTP Colonel did except it takes symphony input and Symphony output implementations from their console component because HTTP requests obviously don't make a lot of sense here and instead of returning an HTTP response he returns a status code which we then you know push back out now the console kernel is very similar to the HTTP kernel it it runs the same bootstrappers detect environment handle exceptions load providers boot providers it's going to spin through all your providers just like the HTTP kernel except instead of handing the request to the router it just hands it to the symphony console component so they're very similar they're very similar in their architecture and the way they're set up so you've got two kernels both with handle methods the HTTP kernel just takes the requests the console kernel just takes input and output and they both return you know an either an HTTP response or a console status code okay so picture those are just the two ways to interact your application they load the providers they execute the command either to the router or the console command return the response and it's a very simple way to think of the two ways to enter your application and a very simple way to picture how laravel works as a whole is through these two kernels and your service providers okay and that's pretty much a summary of how laravel 5 is architected it's actually a pretty simple system it's just service providers and registering with a container and handling the request it's not actually a very complicated framework okay so what I can do is I can pull up like a basic level app and if you have any questions we can actually just look at the code you know in person if you want and you know answer any questions you may have anything wreckage Eric asked a question yeah yeah you could but I would probably do it like a little differently in this HTTP folder there's this request thing and right in this you can see this login request has this authorized method so say you had an edit user thing like you were talking about you might have an edit user request and in that authorized method you would check if the authenticated user can edit can perform this action and you would just return true or false if you return false it's going to return a 403 forbidden for you and it's going to do that if you just type in it it will run authorized before it gets injected in because it's a an HTTP request and if it if it returns false your authorize method you won't even make it this far like you won't even make it into the method you'll just get the 403 so that's a really simple way to do authentication without kind of like cluttering up the controllers the question the question was what's the big difference between laravel and Silex and the big difference is we ship a lot of service providers out of the box so Silex comes without really without a lot of the other features like authentication or key right any of that laravel is like Silex on a lot of steroids like a lot of service providers baked in or like batteries included it's also a little different in that it doesn't use the stack PHP anymore it uses our own kind of middleware stack implementation but it just has more features out of the box it is a very similar framework the main difference is just what it includes and how its set up out of the box like you get the query builder object yeah I don't know okay I mean we can kind of hack on afterwards if you want and you can show me what you have and I can take a look at it hello so our level 5 middleware where's different from laravel four filters functionally in terms of like scope or how they can be used or is it mostly just reorganization rebranding okay the question over I guess you heard the question she has a mic middlewares are not different in terms of their purpose they're different in terms of for example and Larry before we had before filters and after filters we had global before filters and global after filters and those had different signatures that you had to remember so and after filter might receive the request and the response or like the router of the request in the response before filter doesn't receive any response it's just a request and maybe no route the thing with middlewares is is always the same so it's much simpler for you remember you just have to remember the one handle method texture request and an X no matter if you're gonna do something after before the request it's always the same so yeah I think you're right there they're the same purpose this is a simpler implementation and filters are still available and Larry about five I mean it's not removed or anything this is kind of middleware so that encourage default all right well I'll be I'll be around so thanks it thanks a lot for your attention you

Channel: php[architect]

Views: 17,324

Keywords: PHP, Laravel (Software), Programming Language (Software Genre), Software Framework (Software Genre), Software (Industry), Computer Science (Field Of Study), PHP (Programming Language)

Id: qI49j5lGPmw

Length: 38min 30sec (2310 seconds)

Published: Thu Apr 09 2015