There is a common game in our industry:
Imagine a triangle with "fast delivery", "good quality", and "low price" each written on each corner. Choose any two corners at the expense of the third.
Well I've found that this game can be adapted to fit my experience with local development environments, especially running something like Magento 2. I'm a long time and well known Apple fan. (My first Mac a PowerBook 520, and I think it ran MacOS 8.1. That's impressive if you also know that I was born in 1994. It was a hand-me-down, and I played SimCity 2000 and used Claris.)
In my struggle to run Magento 2 locally, I came up with three demands:
- Be as fast as possible. The benchmark here is PHP running natively.
- Be as correct as possible. The benchmark here is a real server.
- Be as convenient as possible. I'll know it when I see it, but if I have to worry about the kind of synced folder I'm using, you probably blew it.
What I concluded is that if you're on a Mac, you can pick any two of these. And the way I was doing development for a long time was really only one of those, but worked for me because I'm an extremely broken and twisted individual. So let's go through a few examples.
MAMP was updated a little while ago, and it now ships with MySQL 5.6. Happy days! You can now use MAMP to run Magento 2. This will be mostly fine if you don't need to integrate with too many other services, and it's what I recommend to front end developers to get set up with quickly.
But in my latest M2 development work, we've been making extensive use of the Message Queue Framework, and I've always liked to use Redis as my caching & session back end. If I'm working on a project on which we are using Varnish, I also like to test it with that.
And for crying out loud, I want a bloody error if I write a lower case letter where there should be an upper case letter. And vice fucking versa.
So MAMP is not a goer for me, but it should definitely be a goer for a large class of people who need to run Magento 2 locally.
Vagrant is certainly correct. I have spent countless hours configuring Vagrant boxes that are as similar as I can get to a production server.
It falls down somewhat calamitously on the other counts, though. Vagrant through VirtualBox pays a fairly hefty CPU penalty, and if you need to share a folder from your host, then you're totally screwed. Sorry, bud. The native shared folders inside VirtualBox are compliant and good with permissions, etc, but they are proper slow. And NFS is optimised for fast reads and slow writes. That sounds like it makes sense until you realise that Magento 2 often creates a metric butt-tonne of files on any given request. Also, NFS and permissions are a nightmare. I know it's possible to exclude certain frequently written to directories from the NFS, but that's docked serious convenience points.
Furthermore, maintaining an entire Linux server is Not Fun unless you are a specific kind of person. I enjoy it, but not when I'm trying to write code. I ain't get paid for setting up a site locally.
Docker for Mac
Yeah, its volume mounting isn't even slightly useful on a large project. And while the virtualisation is better than VirtualBox, it's not perfect.
But the volume mounting. Did you even try this before suggesting it to me?
Docker for Mac, but with Some Other Volume Mounting Thing
I'm immediately docking convenience points for getting me to install some other utility. And if it's NFS, then we already discussed some of the issues. I never really did a deep dive into trying it, because these techniques were developed after I did the thing I did to make all of these problems go away.
All of the drawbacks of "Vagrant" and "Docker for Mac, but with Some Other Volume Mounting Thing", but with the added fun of a VM that sometimes runs out of space and kills everything. Haha.
So What Did I Do?
When I was faced with this choice, I sacrificed convenience points. For my Magento projects, I used a Vagrant machine that I managed myself, and I had synced folders like this:
- An rsync synced folder around my entire project. I used the vagrant-rsync-back Vagrant plugin to allow me to rsync changes from the VM back onto my host. I didn't use the rsync-auto command, I just ran it when stuff changed. And later, I even stopped using the vagrant rsync and vagrant rsync-back commands in favour of native rsync commands with custom options.
- I then used an NFS share around the vendor directory. This gave me some problems around permissions when I did an rsync run, but kept performance issues to a minimum.
Later, I realised that I could dump PHPStorm in favour of my beloved Vim, and drop synced folders altogether. Just vagrant ssh followed by tmux attach -t work, and I was good to go. I got my debugging, my templates, I'm truly a pig in muck with Vim by my side.
I realise that the above is totally ridiculous, but I got passable (but not great) performance, and when my code worked locally, it fucking well worked on dev as well.
But this wasn't ideal.
So I switched to Linux. I nuked my macOS installation, and just went for it. The results were surprisingly not terrible. I went with Ubuntu. After ditching Unity, which is bad at retina, I jumped into bed with i3, which is still bad at retina, but at least you could configure your way out of about 70% of the problem. I then received a tip from someone to try out GNOME, and that was the end of the road. I installed Ubuntu-GNOME, and I'm extremely happy.
The installation process was a dream. Everything works, including keyboard backlights, volume, screen brightness, wifi, and my entire keyboard layout (except for one key). My scrolling is smooth, and the only app I truly miss is Monodraw, which is truly a treasure.
And my local development environment is a dream. It's correct, it's fast, and it's a dream to use. I start and stop it with one command, it doesn't pollute my host computer, and I can debug without issue. Yes, in Vim.
My local set up is Docker based, and Linux only. If that sounds applicable to you, I encourage you to check it out when I release it later this month. It was developed in tandem with a few other developers at Redbox, and it's pretty great. But we've still got a few "fixed for us locally" type bugs that we need to iron out before sharing it completely.
Anyway. Performance; Correctness; Mac: pick any two.
I haven't tried DevBox. I switched to Linux before it was released, and now have neither need nor ability to use it. But it's a project that intrigues me, and one that I am rooting for. Since they are aiming for Mac and Windows compatibility, though, they still have to play this game.
I asked Alan Kent about this, and he said that they chose convenience and correctness, and punted on performance. That's not to say that they didn't try their best, but that's the nature of the game.