You don't need a frontend

Should I use angular, react or insert-framework-of-the-month for my next project?

prospective web developer in 2019

What framework should I use for web development in insert-exciting-new-language?

unsuspecting developer encountering an exciting new language

Web has become the default UI layer in recent years. Most projects grow around either a web or native mobile app. I myself usually start prototyping a new product by cobbling together a web app and hooking it up to a backend service.

However, what if that web (or mobile) app was not the right choice? Can we get away without building it at all? Here are a few interesting results I've come across while exploring this premise.

War Frontend, what is it good for?

Let's see what we'll be getting rid of. Web app frontend serves 2 basic functions:

  1. Present information to the user.
  2. Collect input from the user.

Any substitute replacement will need to serve those 2 functions.

Drawbacks of writing a web app:

  1. You have to build it in the first place. Code you don't have to write is the best code.
  2. You need to teach your users where to find it and how to use it. Using conventions such as Material design helps with usability, but discovery is still an issue.
  3. It can get hard to satisfy power users. Think about users who want to do everything without lifting their fingers away from the keyboard, or write python scripts to crawl your web app.
  4. You might be more interested in backend development. This one becomes more important in case of a side project, or Google stye 20% project.

Having these drawbacks in mind, here are a few projects that I've worked on lately and how I've gotten away without writing a web app frontend for them.

Internal framework support tool

Use case

At my job I lead an API infrastructure team. We develop a framework that other dev teams in the company (~20 teams) use to expose their public APIs. We also maintain the application that runs those APIs. It's something like an in-house implementation of Amazon lambda and API gateway in one service. We've noticed that developers from other teams had low visibility into current state of our production system. I decided to build a dashboard-like tool for them to monitor and manage their APIs.

Failed attempt

First I envisioned the solution like a web app dashboard that collected data from production instances of API service and provided some management operations. Looking for a learning opportunity on this pet project I picked Angular Dart framework to built it with. Few weeks later I built a really nice generic table component (which lagged terribly if populated by more than 5 rows) and lost interest in the project. Count this as 1th and 4th drawback taking their toll.

Success story

Few months later, inspired by the frontendless idea, and after discovering wonderful systems programming language Go, I decided to revisit the project. For my second attempt I decided to build a command line app instead of web frontend.

I actually finished this time, and have discovered new and interesting use-cases in the process. Writing a CLI tool allowed me to easily implement scaffolding features that help developers build their API scripts locally. This is something that would have been difficult to implement in web app, and would have probably never crossed my mind.

Since target audience for this project were other developers, having a CLI instead of a web app did not hurt usability. If anything, it was easier to make power users happy, as they can integrate the CLI into their CI pipelines, and other scripts. So this approach countered the 3rd drawback (in addition to 1st and 4th).

Client hash lookup tool

Use case

API platform I work on uses hashids to generate short ids for out clients. Occasionally folks from support or sales departments needed to find the hash id that belongs to a given client, or reverse. They used to ping my team each time. We decided to build a simple tool they could use to do the lookup themselves.

Roads not taken

We abandoned few ideas right away. For example, building a CLI like in the previous example wouldn't have worked because our users, support and sales people, were not tech savvy enough. We also decided not to go the web app route because it seemed like an overkill for such a simple functionality.

Solution

One tool that all departments within the company use is Slack. So we decided to implement this lookup tool as a slack bot. We used the Hubot framework and I ended up finally learning basics of CoffeeScript. I guess there's no escaping web technologies, even in a frontendless project.

Unexpected benefit of using a Slack bot was ease of discovery. Since our bots participates in public channels, every time a user interacts with it all other channel members see it happen. Every usage is simultaneously a feature demo for potential new users.

Projects registry

Use case

My team recently decided to invest more time into API governance. One thing that become clear immediately was that we needed a registry of all existing APIs. We needed to know which in-house team exposes which APIs and what platform features they use.

You guessed it, frontendless

For this one we didn't even consider building a web app. We already use Confluence to store our internal project documentation. That's the place our product owner and other stakeholders go to find information. However, API projects grow dynamically as developers work on them on daily bases. Manually updating a Confluence page every time a dev in the company adds a new feature to their API wasn't sustainable.

In the end we created a script that can crawl through our git server, find all API projects, collect relevant info and update the Confluence page with it. Both Confluence and Bitbucket (our git server of choice) provide detailed enough APIs, so this wasn't hard to pull off. We set the script to run every night and that was it.

Using existing wiki platform to display our data allowed us to skip entire categories of features, like access permissions, user mentions and comments. And in the end it was easier for our users to find the information they need because they were already used to looking for it on Confluence.

Takeaways

There's one common thing in all three of these examples:

Web app was replaced by a tool that's “closer” to intended users.

In case of developers that was a CLI app. In case of employees from other departments that was Slack. In case of stakeholders that seek project information that was internal wiki. Each time the end product was either easier to discover and learn for new users, or more flexible or power users.

Stepping out of the web app mindset has also had some interesting side effects:

Granted, there are still many situations when picking a classic software as a service approach and building a web app is the right call. However, when you find yourself starting a new project ask yourself if there is another model better suited to your users.

And then share your #frontendless success story with me!