I found it particularly interesting because there are many similarities between Spectrum's tech stack and Cake's. We faced some of the same choices while developing Cake, so I thought it might be informative to compare and contrast our choices and how things have worked out so far.
Regret: Building Cake before Next.js existed
Next.js is a framework that makes this pretty easy. Unfortunately it didn't exist yet when we started building Cake. In fact, at the time it seemed like we were blazing new trails that not many people had even written about.
We ended up building our own universal routing layer and data fetching layer. It works well, but it took a lot of time and effort. If Next.js had existed then it could have saved us a lot of headaches.
Regret: Trying to manage our own frontend infrastructure on AWS EC2
I wasted tons of time early on by trying to self-manage all of Cake's web infrastructure on Amazon EC2. This included using Terraform to provision AWS resources, using Ansible and Packer to build and configure EC2 machine images, using AWS CodeDeploy to deploy code to our web servers, and more.
I spent weeks and weeks deep-diving and learning all of these things, setting up infrastructure, coming up with plans for how to manage and scale that infrastructure, and so on. I was miserable. I constantly felt like my brain couldn't possibly absorb new information, yet there was no end to how much more I needed to learn to do things right. Even worse, I somehow needed to figure out how to efficiently share all that knowledge with other engineers. And if I did something wrong, we might regret it for years.
Finally I realized this just wasn't a smart use of my time. I should have been building Cake, but instead I was building infrastructure and it was stressing me out. So I scrapped it all and switched to Heroku.
We still use other cloud services, including AWS, for various parts of our infrastructure, but Heroku runs our web servers and makes deployments and frontend scaling dead simple. Now, instead of worrying about that stuff, we can focus on building Cake. I wish I had done it sooner.
Regret: Building full-text search on Elasticsearch
We spent a ton of time and engineering effort building full-text search functionality on top of Elasticsearch. What we built actually works really well and overall we're pretty happy with how it turned out, feature-wise, but it took way longer to build than we expected, and the knowledge and time required to keep it running well and to add new functionality is, in hindsight, more of a burden than our tiny engineering team should have taken on.
Elasticsearch is great, but for our current needs and at our current scale, it's a little like building a car factory instead of calling a taxi.
If I had it to do over again, I'd probably outsource our search functionality to a cloud service like Algolia. I think that could have saved us a lot of time and a lot of headaches and would have simplified our infrastructure.
Don't Regret: Switching from RethinkDB to MySQL early on
We originally used RethinkDB as Cake's primary data store, just like Spectrum did. It's a very promising database with some great features, and overall I really like it. But about five months into developing Cake, we realized it just wasn't going to be right for us. We weren't live yet so we didn't experience the operational issues Max wrote about, but we found that RethinkDB had several limitations that made it a bad fit for some of the things we needed to do.
Here's a Stack Overflow question I posted back then about one of the problems we ran into:
So we made the hard choice to switch to MySQL. It's old and boring, but we knew it well, we knew it could do what we needed, and we knew it could scale. We haven't regretted that choice.
Don't Regret: Switching from Markdown to a WYSIWYG editor
Originally Cake's post editor was a plain text editor that relied on Markdown for formatting. This worked well, but it made it difficult to support features we knew we wanted (like rich embeds and mentions) and we also knew that non-technical users weren't likely to be familiar with Markdown.
So after evaluating several options including Draft.js, we switched to a WYSIWYG editor based on Slate. This allows us to have near-complete control over the editing experience, and it means users don't need to be comfortable with Markdown to use links, formatting, and other features in their posts.
Behind the scenes we store post content in an XML format we call Cakedoc. This gives us a lot of flexibility to add new editing features that would be difficult to support well with Markdown alone, such as rich link embeds and other features that are still in the works. It also makes it easier to render posts consistently on different platforms, whereas Markdown parsers tend to vary widely in their behavior and features and are often focused on converting Markdown to HTML, which isn't the best format for every rendering environment.
It's not without its challenges: rich text editing on the web is incredibly complicated, so we've invested a lot of time in contributing improvements and bug fixes to Slate. Slate and other rich text editors (including Draft.js) still don't work very well on Android devices at the moment due to some limitations of the Android platform, which means that right now Android users don't get the WYSIWYG editing experience on Cake. This is a big problem, but it's one we think can eventually be solved.
What we've learned
It's still early days for Cake so we're far from having learned all we can learn. But like Max, I've learned that flexibility and speed of iteration are incredibly important, and boring tech is often a smarter choice than something cutting edge that's likely to be full of surprises.
Outsourcing hard or non-core stuff to cloud services and open source tools while leaving pathways open to bring it in house in the future if necessary has so far worked out well for us.
When in doubt, make the choice that allows you and your team to spend more time focusing on improving your product and meeting the needs of your users, as opposed to scratching an engineering itch or satisfying a desire to play with cool new tech.