Matt Stauffer: “Is Laravel Enterprise-Ready?”

With Laravel Live UK 2018 being over (awesome event, thanks Jonty!), I want to share my recap of one particular talk. Matt Stauffer has expressed his thoughts about Laravel in enterprise world. Is Laravel good enough? Let’s find out and discuss.

Let’s start with the fact that I had already written about Laravel in enterprise, after Taylor shared his thoughts that Laravel is suitable for any project, as long as developers know what they’re doing.

In his talk at Laravel live UK, Matt has dug much deeper. With valid concerns answered, with success stories examples, with strong overall message. Let’s dive in.

Slides are available here, embedded below, but if you want to follow my summary and opinion, please read further.


Wait, so what is enterprise?

That was the first (big) part of the talk. Apparently, no one can answer that precisely, the only common word is BIG. Large customer base, big amount of data, huge consequences of any downtime etc.

But what struck me more, was the definition by John Corry on Twitter:

You know it’s enterprise if we spend more time in meetings than we do building things.

That led to the main point of Laravel in enterprise. It’s not about quality of code, or framework structure, it’s about convincing people in the big companies, responsible for important decisions and large budgets, to trust the future of the company to the previously unknown tech-stack.

They need proof. They need less uncertainty. They want to sleep well at night, feeling safe about their job. That’s what enterprise means – much more responsibility for all the decisions.

enterprise laravel


OK, so what does Laravel offer?

In his slides, Matt has answered a lot of valid questions about Laravel capabilities.

  • Dev-ops and deployment friendly? Yes.
  • Secure? Yes, with XSS/CSRF/Bcrypt etc out-of-the-box.
  • LTS? Yes-ish. That’s not exactly a typical LTS, but still supported well.
  • Flexible? Yes, you can change pretty much any driver.
  • Community and documentation? Hell yes.
  • Predictable future? Yes, roadmap is defined by Symfony releases, and Taylor’s, well, imagination.
  • etc.

laravel flexible

There was more to it in the talk, but main point that Laravel in itself is ready for big projects. But developers can perfectly screw it up.

So it’s pretty ironical, that Matt went on from the question of whether Laravel is enterprise ready, to giving tips to developers to make their code up to the standards.

That’s actually the main idea. It’s not about the framework, or any tool. It’s about architectural decisions developers make with that tool.


Tips on Writing Enterprise Laravel

Some advice from Matt was as follows:

  • In bigger teams, you never know who will touch your code. It should be predictable and consistent.
  • Write tests. If you have a question on what exactly to test, here’s a rule of thumb: search for the function which can make you lose your job, if it breaks. Go and write test for THAT.
  • Also about test: don’t (only) test individual components, test the app in its entirety.
  • If possible, optimize for performance later. You never know which part of the app will have problems with performance.
  • Stay away from buzzwords: don’t use things like DDD, Event Sourcing, Microservices, unless you actually need them and you understand what they are used for.
  • Third-party packages: avoid using Laravel wrappers (cause they are often become abandoned or not supported), also use packages from companies you trust, like Spatie or Tighten.

laravel third party packages


Enterprise is Process

Matt has skipped a lot of the slides, due to time constraints, but he talked quite a lot about process part of enterprise. In big companies, it’s all about (scalable) processes, like:

  • It should be easy to onboard new developers
  • Documentation should be good
  • Code conventions about patterns, folders, tools, config, naming etc.

Another problem about bigger companies is that usually developers are serving the business, they just deliver the features asked by management. It’s hard to convince the stakeholders to invest into things like Laravel version upgrade, adding ElasticSearch, reconfigure AWS stack etc. So developers need to find the language to explain the value to the clients or management in their (non-tech) language.

He also touched on dev-ops part of things, which is also related to the enterprise Laravel. Matt’s main messages was that deployment in bigger corporations is usually out of your hands, but as a developer, you need to make sure to help the dev-ops team as much as possible, prepare all the scripts for easier deployment.


Enterprise Success Stories

One of the most often questions in Laravel community historically is “Please give some examples of BIG projects written in Laravel”. So Matt did exactly that. He listed a dozen of huge companies, some of them wanted to rename unnamed.

laravel genentech

Some of the quotes from/about those companies were:

  • “We chose Laravel for its ease of use, features, and flexibility to integrate with our existing codebase”.
  • “Our experiences have been overwhelmingly positive”.
  • “People saying that Laravel isn’t enterprise ready simple have either no clue and/or have ulterior motives”.

What can you take out of those stories, is that there’s usually something on top of Laravel: server architecture, additional caching mechanisms, NoSQL database, so stuff not related directly to Laravel. So it’s more complicated than just being enterprise-ready or not, it’s not black and white.


Final Thoughts

The most interesting point of Matt’s talk was that he and his company, Tighten, want to help Laravel gain more enterprise-ready traction, so he’s offered his help, and you can get in touch with him and ask questions about your own app. I can assure you, he genuinely wants to help!

So go to EnterpriseLaravel.com, find a “Help me” section and write to Matt!

Also, follow Matt on Twitter and thank him there for this talk!

Want to generate Laravel adminpanel online?
You don't need any packages to do that!

Leave a Reply

Your email address will not be published. Required fields are marked *