Thinking of Websites as a Series of Apps

Are you responsible for managing a website? If you are you probably know that what seems like every few years it is time to "refresh" the site and often that means reviewing everything that is there and trying to update or re-implement things in the site.

Quite often the project becomes overwhelming as you realize all of the features that have been added to the site over the years. A lot of things happen when a site is in "maintenance mode" and what seems like a small project can quickly become large when this is factored in.

A common question we were asked in the 2010s was "can't we just go part-way with this, upgrade one feature, and move onto the next" but in the early 2010s most CMS software would not allow this approach or would make it quite difficult. Each few years a new major version would come out and force a bunch of re-working to occur.

Enter the Microservices Era

In the late 2010s a new trend started: to split up the functions of a website into "microservices". This essentially means dividing up the functionality of a site into logical parts and dealing with them separately - either embedded in the page or hosted on a different domain.

The main idea is to isolate the development and testing of that "component" so that it is easier and less risky to make changes.

So what is an "app" exactly in this context?

For a typical brochure site you may have something like this in terms of "apps" running the site:

• Contact form
• Shopping cart

...but the rest of the site is largely static.

A microservices architecture would suggest a collection of apps that are presented together as one website. Our collection of apps for the above site would be the following:

• a CMS application - used for managing content and visual assets
• a static front-end application - used to generate static pages for content
• the contact form app
• the shopping cart app

The benefit of rendering a static site is that if any of these other services goes down the users may not even notice. CMS applications often require frequent security updates so rendering static files from the CMS acts as an extra layer of security by not exposing that part of the application to the public at all.

Another benefit of this strategy is that we could swap out different components of the site for different solutions, including commercial options. So unlike getting WooCommerce because you are using Wordpress, you could alternatively use a service like Snipcart or Shopify or many others.

Faster Dev With Some Additional Complexity

As you embrace microservices you will start to enjoy that each of your little "apps" is now self-contained and much smaller than the original beast of a project you were dealing with before. It is all rainbows from here on out, right? Well, not really. As is usual with programming tasks you are really just choosing to have a different problem to solve.

In this case the new problem to solve is how to make sure everything is always running together and running well.

Testing that the website is "up" is a great starting point. That might only test your static files though, so it is also important to note if our shopping cart widget loaded. What happens if it fails to load? Do the users see the contact form? Is everything available and functional?

All of the individual apps need to have their own tests to ensure they do what they are supposed to do. An additional layer of integration tests is necessary to ensure that the different apps are working together in the way you want them to.

Keeping Good Records

Once you have all of your tests in place things are going to start feeling really good and you're going to be able to iterate quickly on new challenges and deploy faster due to less scope of testing when you have made a change. That's great! With automated tests this gets even better.

What happens when you try to onboard a new team member though?

If you were doing CMS-based development there would be a "typical way" things are done and that would enable developers to get to work quickly without having to put much thought into the architecture. If you are developing multiple apps from scratch things can go awry really fast when a new developer isn't aware that part of your app already does something that they are in the process of re-implementing.

The way around this issue, of course, is to write documentation. Specifically to write good requirements even if it means documenting the software after it is written. It should be factual and to-the-point so other developers can rely on it to answer questions without involving the project architect for each change.

Some projects may opt to keep the documentation as part of the code repository, while others may want to keep it internal to their team on some form of wiki. Either way, getting a high-level overview of your project "in writing" will help you work with other developers so they can understand the intention of how your project is supposed to work.

Another tip on the documentation front: keep a changelog. For some of our smaller projects we manage the changelog as more of a "monthly report" that captures requests and bugs. This will help other developers see where project is being made so they can focus their energy appropriately.

Potential for Cost Reductions

One final word about microservices... as you embrace microservices your hosting costs will likely start trending downward, perhaps all the way to zero.

Going back to our list of services our site offers:

• the CMS (no longer serving data to the public - therefore could use "free" tier of some hosts)
• the front-end static rendering process - could be generated by a continuous deployment pipeline, some of these services offer a free tier as well, and deploy the files to a free static host like GitHub pages or others
• the contact form could use a hosted service (formspree.io, etc)
• the shopping cart could use a hosted service (snipcart, shopify, etc)

For those last two you might choose to pay for a service. Or perhaps you will set it up in a smaller more focused hosting account. Or... perhaps you design that part of your application to run once and be done, so you could make a "serverless" script that processes what you need which can cost a lot less than managing to run a server 24x7 and having to make sure it is always running. The best part of this is that you get to make the choice of what strategy will be best and if it isn't working for you it will be possible to swap out that one part for another service without disrupting the things that are already working and which you are happy with.