Is Laravel Right For Enterprise Development

Access all articles in sprocket icon.

Published May 12, 2017 by Bill Keck.

Is Laravel Right For Enterprise Development

In the most recent episode of the Laravel Podcast, they spend some time talking about whether or not Laravel is right for enterprise development.

The question, as I see it, breaks out across handling two main points:

  • Scale
  • Complexity

We’ll start with the scale issue.  In the podcast, Jeffery Way makes the argument that most applications will never scale to the point of running into scalability issues with Laravel.

Let me just say upfront, I’m a huge fan of Jeffery Way and watch Laracasts religiously.  At the same time, I disagree with his thinking on scale for the same reason I wouldn’t recommend ignoring n+1 problem simply because there aren’t enough users on the application to create a problem.

In most cases, everyone involved in an enterprise will do everything they can to drive as much traffic to the app as possible, so it’s much better to be ready for it than not.

As I see it, this question is really not about Laravel, but about PHP in general and how you handle state. Personally, I love handling state through sessions, it’s just so easy to work with.  By using AWS and Redis, you should be able to handle quite a lot of scale, without having to go to stateless auth.  I should also note that Laravel does support stateless auth, though I have never personally used it.

Exactly how much scale you can get to using sessions is beyond my level of experience, but it’s worth noting that Facebook was built with PHP, and they have certainly achieved an amazing level scale.  But like I said, I’m not an expert on their architecture, so I’ll just point to a reddit post, and you can check out some opinions about PHP there.

Since PHP 7 was released, it alleviate a lot of the anxiety around using PHP because of the improved speed and performance.

In terms of handling complexity, I know from personal experience that Laravel is a pleasure to work with.  Imagine you have an application with over 500 tables, numerous apis, cron jobs, and extremely dynamic frontend requirements that lean heavily on javascript.

Laravel is perfect for that.  Laravel has a super-solid architecture that is easy to comprehend and work with.  It is so well thought out as a framework that it touches nearly every requirement you are going to come across.  And the thing is it doesn’t just provide all of your foundational code, it does it extremely well.

In the Podcast, Taylor Otwell, the author and founder of Laravel, talked about some reasons why someone might not like the framework, including:

  • objecting to the marketing of an open source project
  • personal dislike of Taylor himself

Let’s deal with the personal dislike of Taylor.  I’ve been following Laravel for 4+ years.  In that time, I’ve never heard Taylor Otwell make anything resembling an unprofessional statement of any kind.  So personal dislike of the founder, which is probably rooted in jealousy,  seems like a petty reason not to use a framework.

Business that make decisions based on pettiness tend to not do well in the market.

I also don’t understand why someone would object to a highly successful open source project having a commercial ecosystem around it.

Would you rather not have Laracasts or Envoyer to work with?  Honestly, I wouldn’t enjoy programming as much as I do if it weren’t for Jeffery Way and Laracasts.  Just think about how much he brings to the space.  Is it really that objectionable that he makes a living from it?

My company uses both Laracasts and Envoyer extensively.  Laracasts also turned us onto Vue.js, which is a great Javascript framework that is used extensively by the Laravel community, and for good reason.

Envoyer provides seamless deployments of your projects, and we have found it invaluable for our releases.  We’re more than happy that Taylor Otwell is compensated in some way for providing both the service and the phenomenal Laravel framework to start with.

Laravel provides first-class documentation, as if it were a commercial product, and yet it’s free.  As the leader of a company that relies on Laravel, I’m very excited and grateful for everything they do.

Another point I’ve heard from people is that Laravel updates too often, with big releases twice a year.  That means you have to migrate if you want to keep up to date, and that can be a pain.  But would you rather update less often and incur technical debt?  Who in their right mind would want that?  Eventually you will have to address technical debt and nothing is more ugly than that…

Laravel, and it’s supporting ecosystem, is capable of powering enterprise applications.   Recently, I mentioned a cliche in one of my books, 100 Patterns For Success, where I talk about the joke from the show Silicon Valley, where an engineer says:

“I want to change the world with a beautiful architecture that maximizes code reuse and extensibility.”

Everyone says that.  Taylor Otwell actually did it with Laravel.

Thanks again to everyone who is following my work, and thanks again for all the great reviews on Laravel 5.4 For Beginners, I really appreciate it.

Laraboot Laravel 5 Bonus Material Released

November 22, 2015 By Bill Keck

Laraboot: Laravel 5* For Beginners Bonus Material Released.

Just a quick post today to let everyone know that I’ve added the first bonus chapter to Laraboot.  With this chapter, it brings the total page count up to 433.

In this bonus chapter, we work with image management and build a dynamically populated bootstrap carousel, also known as a slider.

Working with images can be a bit of a pain, you have to deal with the file management as well as the models in the DB. Fortunately, we get some great help with this within the Laravel framework as well as from the Intervention Image package.

The Laraboot template is straight bootstrap, which means its easy to work with and modify to suit your needs. We use a bootstrap carousel as a slider, and then populate it with images that are managed from the backend admin dashboard. That means you can hand to your clients the ability to manage their own marketing images, which is something they will love.

Thanks to everyone who is supporting this blog and the book with positive comments, I really appreciate it.

Laravel Forge is a Great Tool for Deploying your Application

Access all tutorials in sprocket icon.

October 24, 2015 from author Bill Keck.

Laravel Forge

One of the truly amazing things about the Laravel Framework is the amount of supporting products that are out there in addition to the wonderful free Laravel php framework. I had some interesting insight and discovery with Laravel Forge that I would like to share.

So, I developed my first production app with Laravel,, which is a fairly simple tool for finding “key” comic books, those worth investing in. Yes, people invest in comic books, but let’s not get into that, you can check out the site if you want to know more about that. It’s actually a fun little site.

Now to deploy it, I had some choices available to me that a lot of people don’t have. I went to our company’s network specialist, the one in charge of provisioning servers, and asked him if he could allocate the necessary resources and show me how to deploy my site. He told me he could do it, but that it would have to wait behind some other priorities. Another programmer at work chimed in and suggested I try Digital Ocean in combination with Forge.

I said, “You want me to do it myself?”

It’s one of those moments when you realize you are about to jump into the deep end, without really knowing how to swim. I think that’s an appropriate metaphor considering the name of the hosting company, Digital Ocean.

So just to be clear, Digital Ocean is a cloud hosting platform and Forge is Laravel’s deployment tool. I didn’t have any prior hands-on experience working with production environments, so this just seemed like it was going to be a grind. On the other hand, I could see the wisdom in jumping in full force, there really is no better way to learn. So that time had come.

I created my Digital Ocean account within about 2 minutes, there wasn’t much to it. I went for the $20 per month plan, which was sufficient for my needs, probably more than sufficient, but I always like to leave room in the resources. So getting that setup was a snap, but then the idea of provisioning everything I needed, PHP, MySql, Composer, Apache (in this case ngnix), node and whatever else just seemed way over my head.

So I opted to try Laravel Forge, which builds and helps you manage your server. Just a quick note, I’m going more in the review direction with this post as opposed to a step by step tutorial. I’m not authoritative enough at this point to give you that. But I can describe the process and tell you how it went for me, and I have to say up front, it was fairly smooth and I love Forge. It is well worth the $10 per month in saved time.

Once you signup for Forge, you link it to your Digital Ocean account, which is fairly simple. It’s a few fields in a form with placeholders that make it intuitive. Then you push a button and it configures your server. This is just awesome.

Next you have to link it to your repository, which again is very simple, but to get it to work, you do have to provide a public key for access from your terminal. I had no idea how to do this, but a little Googling got me on the right path. I was able to generate a public key from my mac and provide that to Forge.

In reality, as a complete newbie, this took about 20 minutes, the most time being spent away from Forge and working on the public key generation, and making the typical mistakes, like copying the private key instead of the public one. But once I cleared that hurdle, I was able to deploy my code to the server.

Did the site function out of the box? No. I had to run the migrations. This means you have to ssh into your server and get into the correct directory and run php artisan migrate. So it took me a few minutes to figure out how to do that the first time.

Then that failed because I didn’t have my server environment file set, so no DB connection. Your .env file does not get uploaded into your repository, so the application has no knowledge of the DB. Luckily, the .env file on the server is really easy to edit via Forge, and it only took a minute to update the DB info.

So then I tried my site and of course uncovered a few bugs I didn’t anticipate. I had an error in my navigation bar that was testing for the presence of a profile, but of course while I was coding I had a profile, but now, with a fresh install, I did not, so this was an untested and overlooked problem. It was a simple fix, and again, pulling in the latest code via Forge is a one click prospect. It’s an awesome flow.

But I still had another problem. I ran into the dreaded token mismatch error. This happens when inside the session.php file, which is in the config directory, the domain is not set to the current url. It took me a while to track that down. I felt really dumb because I had run into this before and forgot about it. So I was covering ground I should have already been aware of. This is one reason why I document so much, I just can’t remember everything, and chasing down bugs like that can consume a lot of time.

I also ran into problems where I had to clear my cache for my routes. So once I got all that done, I had a working site. But there was just one more problem. I did not have access to the backend, and since I could only sign up as a regular user, there was no way for me to create an admin user. One way to handle that might be to create a migration that creates the user with admin status.

But I figured I needed to understand how to interact via Mysql directly on the server anyway, so I updated the user record directly from my terminal. So I had to learn how to access MySql from the command line as opposed to using PhpMyAdmin, which is how I typically work with it. None of that has anything to do with Forge. I’m only mentioning these things because you need to have realistic expectations when deploying. You will probably have to do some refining with your app as well.

After getting my install operating correctly, I started reviewing the site and found things that weren’t right. So now I was changing code, pushing it to the repository, then deploying via Forge. Well Forge had one more feature that made this even easier. It can listen for changes to your repository and automatically push them for you. So I switched that on and it works beautifully.

The automatic update did fail for a period, and I imagine behind the scenes that either BitBucket was having problems, which would not surprise me because that has happened before or Forge’s node server quit or something. Anyway, the problem was temporary and I love how it pulls the code automatically. I just push from my IDE, which is PHP Storm, and in less than a minute the code is both in the repository and live on the server. Very cool.

From my personal experience with Forge, I can say it has been extremely positive. I would be hopelessly lost without it, and at a minimum, it would take a lot of work to learn how to provision manually. There’s wisdom in learning how to do it manually, but my focus is not on environments, and I just don’t have the time now to commit to it. For beginner to intermediate programmers, Forge is just a great tool to work with. Eventually I’ll get some feedback from advanced environment guys to see what they think of it as well.

There’s an indicator button in Forge that shows you the status of deployment. Sometimes deployment can take a few minutes, so it’s really cool to be able to see the progress. I love watching it kick over and show me that my changes are live. It’s a good feeling.

In conclusion, I’m giving Laravel Forge the highest possible recommendation. I don’t feel like I’m drowning any more. I’m actually having fun deploying the application. It doesn’t get any better than that.

How to Use @inject in Blade in Laravel 5.1

Access all tutorials in sprocket icon.

June 12, 2015 from author Bill Keck.

In a previous tutorial, we looked at creating a laravel service provider for Laravel. A service provider is a beautiful aspect of the Laravel architecture, but in some cases, when you want to re-use a class in your views, you don’t need it.

Instead, you can use the @inject method in blade. It could work like this:


@inject('boom', 'App\Helpers\Contracts\RocketShipContract')

    {{ $boom->blastOff() }}


Ok, so @section and @endsection are typical blade syntax to define where in the master page the ‘content’ will be placed. Then we can see we have the @inject method. The first parameter is the name of the local variable to hold the object, in this case I called it boom. You can call yours any name that falls within variable naming rules.

The next parameter is the class or contract you are instantiating. In this case, I’m calling a contract, because I have a service provider binding the contract to a concrete class. You can refer to that service provider tutorial for the exact reference.

Then in the dual curly brackets, which is again blade syntax to echo php, you see we are calling the blastOff method from the object instance variable $boom. The blastOff method simply returns a string of text. If you are curious why I chose boom, blastOff, and RocketShipContract, these were examples I was using in my service provider tutorial, which is a related subject. Check that out when you have a chance.

There’s an interesting example of @inject in a Laracast’s video where they use stats as an example, which is perhaps a closer to a real-world example.

Anyway, @inject offers you an easy alternative to service providers, allowing you to bring in reusable code that is not tied to a controller. As I’ve explained above, you can also use @inject in tandem with a service provider, when you want to call a contract instead of a concrete class.

Also note that you can place @inject outside of the @section where the object is being used. So if you want to perhaps place it at the top of the file, above the @extends line, you could do so. That might be more intuitive.

@inject('boom', 'App\Helpers\Contracts\RocketShipContract')



    {{ $boom->blastOff() }}


This looks really clean to me. That kind of flexibility is yet another reason to love the Laravel Framework.

I hope you have enjoyed this tutorial and found it useful. Click on the sprocket icon at the top of the page to see all tutorials. Please comment, share, and like if you can, thanks!

I don’t have a donate button, but If you would like to support my work and learn more about Laravel, you can do so by buying one of my books, Laraboot: laravel 5* For Beginners, I really appreciate it.