Written by Hari Krishnan
on 

Inside Out vs Outside In

Inside Out vs Outside In

Starting with the DB/Backend vs Starting with the UI/User

As a Developer, it is useful to have a repertoire of metaphors to better articulate our thoughts. This post is about a parallel in supply chain management I thought was useful to me in explaining my approach to implementing features both to myself and to others.

At a high level there are two ways you could implement a feature.

Inside Out/Backend First approach — Begin with database design. And then the backend classes (read domain) and services. UI is usually the last bit to get built.

Outside In/UI first approach — Like the name suggests, we start with UI, then build the APIs and then the DB schema.

This can look like a matter of preference at the surface. However we can try and explain which approach is better with some theoretical backing.

Let us look at how each approach sequences the tasks.

Inside Out/Database First approach

  1. Database — Build schema based on the feature.
  2. Domain — Build abstraction over schema
  3. Services — Build functionality on domain
  4. API — Expose functionality
  5. UI- Build UI with API

This is typical of a “Push Strategy” where we forecast demand (read demand as in “Demand and Supply”). The demand here being what the UI needs.

Outside In/UI first approach

  1. UI — Build UI with API stub
  2. API — Build API that satisfies the stub in above step. API itself now depends on Stubbed out Services.
  3. Services — Build Services that satisfy the stub in above step. Stub out Domain and DB
  4. Domain and DB — Build Domain and DB to satisfy the stub in above step

This is a “Pull Strategy” where we generate demand. See how UI creates the demand for what it needs from the API. And the API does just enough to satisfy the demand of the UI.

Push vs Pull

A complete comparison is out of scope of this post.

In short, push strategy is suitable when the problem at hand is well known and so is easily predictable. If you have already built the same feature a 100 times over, you have historical data and you know exactly what fields to include in the DB, what domain objects are involved etc. However this is hardly the case in Software. If you are building a feature more than twice, you extract a re-usable component.

Pull strategy is suitable when there is no historical data. So prediction errors can be large. UX is evolving fast and the experiences we are building requires a complete re-thinking of how we build backends.

Inventory and shortage

Inside Out approach, as already mentioned requires us to forecast/predict what we will need. For example: We are architecting the DB schema to fit the overall feature at a point in time when we have not built the UI.

With no historical data, forecasting errors can occur.

  1. Shortage: The schema does have all the necessary fields the UI needs. This leads to rework. While rework is bad, shortage is a visible problem and we know how much time and effort was wasted. What is worse is how we usually handle shortage.
  2. Inventory: To overcompensate shortage scenario we may include additional fields in the schema (Overproduction). So when UI does not consume it, there will be inventory or dead code. Inventory in manufacturing actually consumes warehouse space. Since that is visible and measurable it is monitored closely. In Software, inventory problem is not as visible as shortage. Dead code does not take up physical space, it only consumes valuable cognitive space in the Developers mind. So there may not be a measurable loss. Only an inkling that we are lugging some unnecessary weight.

I personally prefer “Outside In” approach. Starting with components that are close to end consumer helps us build features with minimum design errors. This goes for “API First” approach also. While being API Centric is good, it does not mean we design APIs in a void without actual demand. If an API has more than one client, they can all generate the demand.

With network style architecture like MicroServices, it is easier to go with “Outside In” approach to trace changes.

I have only scratched the surface of Push and Pull strategies in this post to justify my preference of approaching feature implementation. Once you get past the initial theory this topic can get immersive.

Originally published on Medium on July 2, 2019.