Sign in

CEO, Perry Street Software. Developer. 🏳️‍🌈

The pattern you need — or probably had but didn’t realize

We started this 6-part series on how to build web APIs by introducing the variety of architectures that have been proposed or put into use by various languages and frameworks over the years. Among the most commonly discussed architectures online is the Clean architecture, which aspires to produce a separation of concerns by subdividing a project into layers. Each layer abides by the Single Responsibility Principle, ensuring each class is only handling one part of the process, and is more easily and thoroughly unit tested.


Classes you’ll want and need when coding that API

It’s time to see what a Clean API endpoint actually looks like in practice. Per our earlier blog post about the Endpoint Responsibility Checklist, we know that the steps in an execution path in response to an HTTP request are:

🔵Receive→🟢Validate→🔴Validate→🟢Enqueue→🟢Respond

Note the line above — we are going to be repeating it throughout this blog post so we always know where we are.

For write requests, we have the additional steps in response to an enqueued SQS message:

🟢Dequeue→🔴Mutate→🟢Notify

These execution paths map to our architectural diagram:


What API frameworks all (should) do

What does an API endpoint do?

In our series on Clean API Architecture, we have explained how there are multiple layers involved in responding to an HTTP request. Broadly speaking, there are two kinds of requests — the kind that mutate state by writing to a database (POST/DELETE/PUT), and the kind that merely return state from a database (GET).

(For brevity, when we say POST from now on, we implicitly mean POST/DELETE/PUT).

For both GET and POST endpoints, you must fulfill the following responsibilities:

Endpoint responsibility checklist

  • 🔲 RESTful Routing (Which endpoint should we execute based on verb and URL pattern?)
  • 🔲 Control Flow (Order our execution, also handle…


When code is executed, how does it respond?

In this series we are exploring patterns for web API architecture. In order to build our case, we must first take a detour to explore common patterns of code execution whenever you call a remote API endpoint.

Computation 101


If you’re still throwing exceptions, you’re probably doing it wrong

In order to have an “architecture” to your code, you need a map and a path, a diagram and some arrows. But what, exactly, do we mean by a “path” — what is the nature of the arrows and how do they behave?

Put another way — as we pass data between the layers, what are we passing? In a simple architecture, it is likely that you would be passing a parameters hash down the layers:


Spoiler: Still 🤷 after 30 years

So, what’s the architecture of your web application? It sounds like a deceptively simple question — maybe even a softball first-round interview question.


Learn this now or spend 🤷‍♂️ in Crashlytics later

In this series, we spoke at length about how Android process death can trigger crashing on apps that do not follow a Clean MVVM Application lifecycle pattern. In order to debug Android process death, you need to first trigger a process death, and then you need to restore your application to see how it behaves.

Step 1: Trigger process death

Method A: Use adb

Put your app into the background by pressing the home button

Kill the app using adb:

adb shell am kill <YOUR APPLICATION ID>

DON’T use the “Stop” button of Android Studio to kill the process. This will not simulate a process death and it…


Every developer will ask herself these questions when writing a new activity — here are quick answers when doing so using our Clean MVVM Activity Lifecycle:

Where do I initialize my ViewModel?

→ Lazily as a member variable:

private val viewModelFactory: FeatureViewModelFactory by inject()
private val viewModel: FeatureViewModel by viewModels { viewModelFactory }

Where do I set up the views and the click listeners?

onSetupViews(), one of our custom Clean MVVM Lifecycle methods

Where do I set up the state change subscription? (LiveData)

onSetupLiveDataEventSubscriptions(), one of our custom Clean MVVM Lifecycle methods

Where do I set up the events subscription? (RxJava)

onSetupAliveActivityRxJavaEventSubscriptions() for subscriptions that we want to retain even if the app is backgrounded (most of the cases)

onSetupVisibleActivityRxJavaEventSubscriptions() for subscriptions that we want to cancel when the app is backgrounded

Where do I handle deep links?


Initializing your app’s database at startup — easier said than done!

How do you initialize a repository? More precisely, how do you initialize application-scoped classes with database dependencies?

If you’re an iOS developer, the answer to the question about is probably “synchronously on the main thread, in my Application delegate during didFinishLaunchingWithOptions, what’s the big deal?” On iOS, because of the strong guarantees about startup sequencing and fast nominal performance of devices, this answer usually works, even if you are *technically* doing blocking I/O on a UI thread.

If you’re an Android developer, if you provide the same answer, you know that you are committing a Strict Mode Violation, but, given…


The missing lifecycle diagram for reactive Android Apps

Every Android developer working with an MVVM architecture faces the choice of how and when to configure views and subscriptions. Do this incorrectly and you will experience seemingly impossible NullPointerExceptions, as we documented earlier in this series.

To avoid these consequences, simplify your code and streamline your architecture, our company has developed its own proposed Activity and Fragment lifecycle that we have dubbed the Clean MVVM Activity Lifecycle:

Eric Silverberg

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store