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.
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.
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.
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.
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.
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".
-front_grid.jpg)
-=-{-axios.get('apiabilities')-.then(response-=-{-front_grid.jpg)
;-(1)-front_grid.jpg)
No comments or questions yet...