Why I’m rewriting my SaaS

I think services are a useful tool but for most problems you can get incredibly far with a monolith. I think a solid approach is to identify where there's a bottleneck in your monolith and extract that instead of splitting the application up for the sake of having separate services.

Serverless costs you money. Running a low-volume db in the same VM you serve the site and the web api costs you zero.

Interesting choice of phrase. What would you say is the difference between refactoring and rewriting, assuming we’re talking about keeping the externally observable behaviour of the affected part of the system the same in each case?

This shouldn't be happening in a sufficiently tested or sufficiently understood system

Perhaps, but as systems and the teams that develop them evolve over time, it is all but inevitable that some knowledge and understanding are lost. You’ll never have perfect documentation. You’ll never have tests for every possible case. You’ll never have an unambiguous and readily located comment for every subtle detail in the code that someone seven years ago spent a couple of hours thinking about before they put finger to keyboard, when three other people have since refactored that code, generalised its interface, and fixed a performance glitch in a dependency so some aspects of the original design became unnecessary. Preserving knowledge and understanding as well as possible is one of the challenges facing any team with a long-lived system.

Those losses are a form of technical debt, and as it accumulates, two things happen. First, the original code becomes harder to maintain and develop. Second, the original code becomes more risky to rewrite. So unfortunately, there’s a fairly high probability in practice that a part of a system that has become sufficiently difficult that a large-scale rewrite is being considered will also be a part of the system where the current development team have incomplete understanding of the current implementation.

If you can't figure out a peicemeal way to refactor what you have into what you want you want, you have no business discussing what a rewrite should entail.

But how do you do a piecemeal refactoring exercise if, say, you’re moving to a new programming language? I had to rewrite a large part of a relatively complicated web UI a few years ago, like for like. Although it had been working reasonably well to that point and the design was quite clean and had stood the test of time, it was built around a Java applet. That design made sense when we were first implementing that system, at a time when JS was slow and many features we take for granted in browsers today weren’t yet widely supported. It was less helpful when the great and the good of the browser world decided that Java applets were a liability and they were going to make them harder and harder to use until eventually they killed them off completely. Now, we did have a clean, careful interface between the applet and the various other parts of the page that were written in JS, so we only had to redo that part of the system. However, we had no choice but to reimplement everything the applet did, using alternatives like JS and SVG, starting from scratch. This is the sort of scenario I was talking about before when I mentioned changes in the foundations of a system.

Remember Friendster from 2003? It's quite possible that it would have not lost to Tribe/Myspace/Facebook if it didn't take minutes to connect before eventually timing out.

There are things that are worse than wasted effort, and one of them is a hockey stick that slips right through your fingers. By the time the curve is inflecting, if you can't keep up, you're burning customers and inviting competition. If you have to rewrite at that point, you are going to lose to competitors with deeper pockets and no PR baggage.

What you want to do is break your WordPress application into classes containing the business logic and turn WordPress into a dumb wrapper for those classes. At that point, you can move those new classes over to Laravel when you are ready to make the switch.

For example, you can switch your customer dashboard views over to be written in Laravel. You can use either nginx/apache to route, or have a base index.php file that either includes the WordPress index.php or the Laravel index.php based upon PHP code. Within your new Laravel routes, you will be boostrapping WordPress from Laravel and calling WordPress code from within Laravel.

For example the WordPress users. You could create a new class and interface to encapsulate all of the WordPress user code inside your WordPressUser class that implements MyAppUserInterface. Eventually, you will create a new class that implements that interface for Laravel once you are ready to switch out WordPress for user management and use Laravel. With that said, I would likely leave users to be the very last thing you change. And quite possibly, think about leaving WordPress around solely for user auth and management.

The same idea works for posts and other entities you are currently using within WordPress.

On the WordPress side you can implement hooks that can call methods on the Laravel side as you move through the transition.

Rewrites are so often deadly. Please put some serious thought into it. No one knows your business better than you do, so I'll just leave you with that friendly advice.

Also, writing this makes me chuckle as I can't even get a response from a single resume I've sent out over the last two weeks. Sigh...