Sometimes boring is the right choice. PostgreSQL has worked for decades now, and seems to have regained much of the performance that MySQL once boasted.
If you do this for the money, investing in tried and true (but boring) software should be the default solution.
I watched with dread how the MongoDB fiasco played out a decade ago. Meanwhile, I kept using PostgreSQL and had a good ride.
IMHO MySQL becoming boring (fast, pretty reliable, non-compliant quirks being ironed out, decent backup tool availability, credible admin tools, JSON and CTE support) is one of the most important long term trends on the internet.
Along with the parallel evolution of PHP.
All the PHP+MySQL I've worked with has been horribly bespoke and brittle.
Want to significantly change a URL? Need to refactor every path in the .PHP file, because it's importing something from ../.. Or get in the spaghetti business with path aliasing on the webserver.
Want to refactor the database schema? Difficulty: Impossible, because raw SQL strings are scattered everywhere, including on other systems.
Want to add/modify a new internal CRUD form? Gonna be several hours of work to RE what the last guy did to keep things consistent, while tiptoeing into the SQL to not break anything. With a proper framework, this is a 5 minute task and a few LOC into the "admin interface".
It works, and you can do a lot with just a few php files and a basic Linux system, but there are downsides.
Laravel is, IMO, among the best web frameworks available full stop. Certainly one of the most maturely documented.
It addresses all the points you make.
Eventually some blade template error resulted in an impossible stack trace due to the insane amount of magic behind the scenes in Laravel, and while debugging that I decided to stop relying on such black magic hack of a framework. Around the same time Go gained in popularity and I have been working with Go since and are very happy with it.
This was Laravel 5 days and I'm sure much has changed.
I completely adored the laracasts made by Jeffrey Way. I wish every framework had a guy like that do produce learning materials.
Frameworks solves a general problem, you on the other hand has a specific problem. To be able to accommodate your specific problem and everyone else specific problems frameworks has tendency to heavily rely on magic.
* magic classes - using PHP magic methods for everything, the actual class is usually empty and things happening elsewhere.
* magic files - put a file with the correct name in folder somewhere and things happen
* magic configuration - put a hard coded string in some config file and you change the entire behaviour of the app.
* magic layers - if you follow the execution path with the debugger you spend the majority of time circling around in different layers and very little time in your own code.
All of these things are considered bad practice when doing it in your own code, but for some bizarre reason it is considered good practice in frameworks.
I think that’s because that kind of code has a much higher maintenance burden. It’s much more difficult to get up to speed on what’s going on in complex magical code. But you can probably trust a framework that’s achieved critical mass to make reasonable decisions and stay alive for a while.
And if I'm gonna deploy a new framework greenfield, I'll just go with Django since Python has more mindshare in my industry.
I have created many on-the-fly mini-PHP frameworks to use within existing legacy code bases to avoid all of this.
Easiest way to avoid manually requiring files is to use classes with the auto loader. Done.
The second easiest solution is to have different constants that has the full path to a directory and then just you use the correct constant when doing a require. No relative paths required.
You can even have one require constant per file if that is your game.
Raw sql is fine, just don’t scatter it in every file, instead put sql in specific repositories, e.g ArticleRepository, and do all article queries in there. Now it is easy.
An ORM actually creates more problems when refactoring because entities are spread out everywhere.
If you use something like Phpstorm IDE it can help refactor raw sql too.
Problem is that many developers doesn’t think this thru and even worse they accept the situation and don’t do anything about even if they can. Instead they go to forums and complain. I’m sorry but I have zero tolerance for that.
Laravel has an excellent ORM, a great query builder (I write almost no SQL), an effective database migrations system, a solid class hierarchy (no include statements anywhere), a really useful job queuing system, and it is built around Composer (one of the best package managers anywhere).
Lighthouse is really a first-class, schema-first GraphQL binding with a very logical code interface.
I don't see any code maintenance problems in Laravel that can't be mitigated by the same discipline you need anywhere else.
If you have a solid team and some people with a good background in the framework and PHP that can mentor effectively, then it probably won’t be bad. It still would not be my first choice though.
When you want to deviate from the boring software and technology, there must be a very sound 'business case' for it.
If you are building a planetary scale business, OK, maybe that warrants something more fancy.
But how many companies really need that? I'm not limiting myself to the HN unicorns, but looking at the whole market.
> If you do this for the money, investing in tried and true (but boring) software should be the default solution.
Meaning if you are just playing around, then by all means evaluate new and shiny stuff.
Things are complex, especially in data, I think it’s important to evaluate use cases rather than going with generic assumptions like “use boring tech”.
Could you elaborate on this? MongoDB as a company is worth $30B, so it looks like they did at least some things right.
There was a Slack competitor using MongoDB that was snappy and js hipster trendy that ultimately failed because of unreliable database IIRC.
It also works well for early stage Consumer Internet startups that haven't yet achieved huge growth but care a lot about developer productivity while churning features at high velocity.
But it gets blamed for reliability issues suffered by highly successful Consumer Internet companies that have achieved scale and have DAU, MAU in > 10M and have lot more than 4TB of data in a single cluster.
But that's basically a good problem to have at that stage. Usually such a company would have many more problems – monolithic application with monolithic database with huge unmanageable schema and indexes gone wild etc. Usual solution at that stage would be some sort of rearchitecture towards Microservices with multiple specialized databases for different use-cases – usually cloud hosted managed databases with horizontal scalability dedicated for online user-path workloads and separate OLAP tech stack for offline ETL/analytics workloads.