Laravel Octane with Swoole — Beyond the Basics

hey everyone at the time of making this video laravel octane is the latest offer from laravel it's basically a package that allows you to run your application faster by serving it under a stateful php7 we are not going to discuss installing octane and running it on your machine in this video so i suggest you go to the documentation and find how to run it on your machine this video is all about what's beyond the basic starting with the difference between stateful php and stateless php now we have all been running php in a stateless mode it's actually something that makes deploying php applications and building bhp applications very easy because it's stateless whenever a request comes in it gets a fresh state however when you run php in a stateful mood which octane offers it will run faster because your application instance is not on is only going to be bootstrapped once and the same instance is going to be used to serve all the requests on the incoming requests to the server however being stateful means that the state will persist between requests running statefully has side effects which we are going to discuss later in this video but right now let's start with stating the difference between swole and roadrunner the difference is that roadrunner is just a binary that you install while installing octane and you can start using octane right away however swool is a php extension that you have to install on your machine before you can run octane on your server for some people installing a php extension is problematic and that's why roadrunner option is available for you to start using octane immediately however using swole has a lot of benefits which we are going to discuss in this video so let's get started octane runs your application in a stateful mode means that a single application instance will be created when the octane server starts and each incoming request will use this instance to serve response to the user now that's not completely true the same instance is not going to be used to serve the requests octane is going to clone the original instance that was created when the server started it's going to clone it and it's going to use that clone to serve the request octane does that so the application instance or the laravel container which is the same as the application instance the larval container will be in a fresh state while serving each and every single request so if you do any manipulation to the application container while serving a request these manipulations will not pass to the next request because the next request will clone a fresh instance from the original container or the original application instance that's started when the server start octane will not only clone the application instance for each request it will also clone the configuration repository and it's for the same reason if you do any manipulations on the configurations inside the request it doesn't pass to the next request so now that we understand the main differences between running octane and running on a regular nginx php setup let's see the side effects of running your application on laravel octane here i have a version on my application running on laravel valet which is basically nginx plus php fpm versus another instance that runs on actin i haven't started the octane server yet and that's why it's returning an error so let's start the octane server and see the difference between running on octane and running on nginx plus php fpm so i'll go to the terminal and i'm going to run php arts and octane start and i'm going to use the swool server for my example now octane is running on port 8000 on my machine so if i go to the browser and visit port 8000 i can see that my application is served under laravel octane here i'm visiting a route on the application called static let's see what's inside this route in this route we have a static array called values and each time we visit this route we are going to add the current time inside this array if we hit this route under php fpm several times each time we will get a fresh instance from the array however if we hit the same route inside level octane we will see that the values of the current time will be added to the array on each request now this example might be too obvious now let's see another example while using the larval container i have another route here that's called store and this route resolves an instance of the store service from the container and calls a store method stores the current time and at the end of the route we are going to use the same instance and we are going to just dump the values stored inside the store now this service is registered inside the app service provider as a regular binding to the container if we take a look at this class we can see that the store method just adds the value provided to the store array inside the instance if we go to the browser under php fpm and we visit the store endpoint here several times we see that the array is empty even though we are adding values to it each time we fed the request but that's because the we are registering this store service as a regular binding this line will resolve an instance from the container and this line will resolve a completely different instance from the container a regular binding is going to be resolved each and every single time it's requested from the container and that's different from a singleton a singleton is only going to be created once and the same instance is going to be used each time we request it from the contain so now if we visit this route again we can see that values are being added to this array but again even though we are adding values to the array on each request with each request we make under php fpm we get a fresh instance from this array because a php fpm runs your application in a stateless mode however let's run the store route on the laravel octane but before we do that we must kill the octane server and start it again so our changes our code changes reflect now let's stop octane and start a new instance from the server and visit this store route and as we can see each time we visit this route we get a fresh instance from the array even though we say that cuctain runs your application in a stateful mode and the reason for that is that octane clones and instance a fresh instance from the container to serve each request so inside the request if you resolve a singleton this singleton will only ever be available inside this clone when serving a fresh request it will get a fresh clone from the original container inside this fresh clone this single tone will not exist because the singleton belongs to the cloned instance from the previous request in other words single tones don't process between requests when using laravel octane except for singletons that are resolved while the application is bootstrapping so inside the put method here if we call up and we resolve this store service once this will create a singleton when the original container instance is being created which is when the octane server starts the singleton will live on the original instance of the container so on each request when this instance is cloned the same instance from the store service is going to be used to serve all requests and we will see this right now let's stop the octane server and start a new one and we go to the browser to the store endpoint and we hit refresh several times and we can see the difference between now and before we resolved the instance from inside the binding or the put method on the provider now because the singleton is resolved when the application is bootstrapped it lives on the original container instance and it goes to each and every request that's handled by octane so singletons are not scary when using octane unless these cylinders are resolved inside the put method of any of the service providers if you are not resolving the singleton while the application is bootstrapping this singleton will not live between requests so you don't have to worry about it that's one thing you need to know about laravel octane the other thing is that at each any point in time while serving a request there are multiple instance or two instance exactly from the application container alive the original instance that started when the server started and the cloned instance that's supposed to serve the request if we look at the bind this binding here for this service we can see that the binding uses this app to pass an instance of the application inside this service now this service basically stores the past instance of the application and there is a method called app id that gets the object hash of the application instance that's passed inside this provider route here we are comparing the app id or the instance the id of the instance that's passed to the service when we grab it from the container versus the object hash of the current instance of the container or the instance the cloned instance that's supposed to serve the request if these two ids are identical we will print same if not we will print different now let's go to php fpm and check the provider endpoint and we can see that the instance is the same which makes sense because when running php fm it's only a single instance handling the request however if we check the octane version we will find that the instances are different and that's because we passed the original application instance it's the instance that's created when the octane server starts it's not the cloned instance that's used to serve the request we need to fix that each time we pass an instance of the application to a service we need to pass this instance instead the one that's provided to the closure here now let's terminate the octane server and start a new one visit the endpoint again and now we see that we are serving the same instances the instance passed to the service is the same instance used to handle the request so each time you are binding a service to the container and that service is expecting an instance of the application or the container make sure that you use the instance pass to the call pack not the instance available on the service provider and this when using a regular binding however if we are using a singleton we cannot even use the application instance pass to the callback because if this instance was resolved while the application is being put strapped the instance will left to serve all the requests and if we pass the application instance to this singleton in the beginning it's going to be the instance of the container that started when the octane server started not the one used to serve every request and to solve this instead of passing an instance of the application we are going to pass a closure that returns the instance of the current container so we are going to use container get instance and inside the service and instead of using the application instance directly to get an instance of the application or the container we will have to invoke the callback invoking the callback will get us the current application instance or you can simply use container get instance and get rid of passing the application instance to the service so just use here replace this app with use container get instance you can choose whichever solution you like and a simpler solution is to simply not register the service as a singleton register it as a regular binding and that way each time you request this service from the container it's going to resolve a new instance which will receive the current application instance and similarly if you are passing an instance of the current request or an instance of the configuration repository don't pass it right away to a singleton pass an instance of the container and resolve the request or the config services from that instance and that way inside the service when you need to use the request or the configuration repository you are going to invoke the callback which will resolve an instance from the container the current instance not the one the original one that's created when octane starts and this instance knows how to get the current configuration repository or the current request i know it's a bit complicated when you think about it by by time you will get used to these practices and it will not be a problem at all now to wrap this video up let me explain the features that swool adds that's not available when you are running roadrunner basically the most wonderful feature is that swoles ad is synchronous code execution to laravel octane this example in the documentation here show you how you can run multiple database queries concurrently by using octane concurrently so here we are loading all users from the database and all servers from the database and we are telling octane to do it concurrently what happens behind the scenes is that swool is going to start a group of worker servers these workers do not handle http requests they are only here to run tasks asynchronously when you need to so here when we call octane concurrently and we pass these closures swool is going to take these two tasks and assign them to multiple workers that are available at all times these workers are going to run these database queries and return the result back to the main worker that's handling the http request and that's why using swool is absolutely amazing you can run php asynchronously another thing that swool offers is sticks and intervals basically it allows you to run code every x seconds in this example here this function is going to be called every 10 seconds this is like a small scheduler that you can run in the background of the octane server to do some simple tasks it's quite handy when you don't need to use the full power of the larval scheduler just simple tasks that you can run every x seconds another powerful thing that swool on octane offers is the octane cache now swool offers something called swool tables which is an n-memory data store that's very fast incredibly fast octane uses swool tables to store data and read data from them in the form of a new cache driver that's only available when you are running laravel octane this cache driver also has an incredible feature that's not available in any other cache driver which is the intervals in this example here the value of the random cache attribute is going to be refreshed every 5 seconds in the background in other cache drivers you cannot do that and these are all the incredible things that octane provides to the laravel ecosystem i'm not sure about you but actually octane is one of the most interesting components of laravel besides the q component of course let me know what you think about octane and if you have any questions please reach out to me in the comments section down below or you can contact me on twitter and i'll do my best to answer your questions hope you learned something in this video

Channel: Mohamed Said

Views: 10,890

Keywords: laravel

Id: T5lkBHyypu8

Length: 15min 38sec (938 seconds)

Published: Wed May 26 2021

Reddit Comments

[u/ThatDamnShikachu]

So if I understand correctly I can literally store the number of requests and other metrics in the Octane cache driver and serve a Prometheus endpoints from it.

Sounds cool, yet I have some worries about horizontal scalability.

[u/serenityphp]

Well done. Very useful. Any chance you can cover swoole websockets? I’m very interested in leveraging these websockets for broadcasting.

[u/devourment77]

I know I have some singletons that assume clean initial state on each request, stuff like that bit me with node APIs and I suspect they would need to become stateless first.

[u/penguin_digital]

Thank you for the explanation Mohamed