Do I need a web app or just a microservice?

web app icon

First, let’s dive into the differences between the two. A web app is a web-based application that is reachable, and often configurable, via a web address. In general, it’s a website that you can log into to run processes, manage content and configuration, and check on the behavior of the application. SaaS apps like DropBox would fall into this definition, but it could be something as simple as a homegrown Human Resources portal that a company creates to manage their quarterly review process.

A microservice, on the other hand, is an independent application that performs a focused task, often with little-to-no human interaction. An example would be a weekly process that pulls your latest blog posts from your website and pushes them into your email platform to fill out your newsletter. It could be built into your website, or it could run untethered as a Lumen app or an AWS Lambda.

For the purposes of this article, let’s leave SaaS apps out of it and focus on internal toolsets (since, spoiler alert, if it’s a SaaS app, it’s a web app). Choosing between a web app and a microservice comes down to several factors, and we’ll also discuss how to go about building microservices that will eventually become a web app.

It needs consistent tweaks, configuration, and observation

If what you need requires as much care and attention as a tamagotchi, then you probably need a web app. This includes functionality like login, user management, and some level of administration and reporting. Let’s look at our newsletter content sync example:

newsletter microservice

  • Can run automatically through a scheduled process.
  • Simply selects the 5 most recent blog posts and needs no content changes.
  • The sync is simple enough that developer check-ins are sufficient.
  • It’s obvious if it didn’t work correctly, and easy to re-run (and there’s a developer available to do that).

newsletter web app

  • The sync needs to be run manually by a human.
  • Different newsletters for different groups need to be managed.
  • Pulls blog posts based on specific criteria, and a content editor can make changes before the sync runs.
  • The sync is complex and the team requires ongoing proof that it’s working correctly.

You have access to ongoing developer support

If, once the project is done, you’ll be left without developer support to keep things running smoothly, then a larger investment up front in a web app probably makes more sense. Why? Because a web app can be built with more capabilities and visibility into the inner workings on your processes. Maybe the sync runs automatically, but there’s a button you can press to run it manually for some last minute content updates. With a microservice, upkeep and diagnostics will be fully in the hands of a developer. Let’s look at our example again:

newsletter microservice

  • A background process that a developer accesses through ssh (the terminal) or through an AWS administration panel.
  • Configuration changes happen in code.
  • Processes either work or they don’t.

newsletter web app

  • A website that developers and end-users can log into.
  • Configuration changes happen through an online form.
  • Processes can be setup to run manually and/or automatically.

Microservice now, web app later

web graph icon

In many cases, it makes sense to start with a microservice. But as time goes by, and more and more functionality becomes necessary, you might need to convert to a microservice. Wringing our newsletter example out one more time, we might start with one newsletter that moves content directly. But eventually lead management develops a strategy that serves up different newsletters to different lead segments, and also wants to work in a few resource articles as well. Now that segmentation criteria needs to be managed, multiple syncs need to run, and other types of content need to be synced as well. Rather than manage all this in code, the marketing team would like to be able to add new segments and edit the existing ones, as well as promote specific pieces in some newsletters even when they aren’t the newest (i.e., that fancy Gartner or Forrester piece).

It’s for situations like this that we usually develop microservices in Lumen. Lumen is a micro-framework based on the larger, more robust Laravel framework. There is a direct conversion process from Lumen to Laravel, and Laravel has tons of goodies that make app configuration and user management a breeze (see the ever-so-lovely administration add-on, Nova).

This approach let’s us develop and deploy microservices quickly, with little bloat and server overhead. But once it’s time to upgrade to a web app, all the previous work isn’t lost. We simply add on the new pieces (like user management) without starting from scratch.

If you’ve got a microservice or web app you need help with, we’d love to talk.

Scroll to Top