A Practical Approach to Front-end First

Some time ago, I got the chance to boot up a NodeJs website for tracking shipments for Namshi. The approach that was suggested was to build up fine-tuned front-end before/during delving into the API design/implementation that was supposed to feed this website with shipment data. Shipment information comes from various sources of all shipment companies that Namshi is working with. In short, finishing up the API was a lengthy project. After the API is finished, the front-end application was supposed to be built and passed on to the designers to finish it up. Discussions were still going on regarding how the website will look/function.

What was suggested was to launch the development for both the front-end and backend in parallel and that was the motivation for following a front-end first approach.

Front-end-first allows for the following:–

  1. Working offline
  2. Quicker response to change (no backend)
  3. More frequent reviews
  4. Fine-tuned front-end

Teams following different strategies in developing and reviewing their application will notice a significant time saving using this approach as most of the time is spent while stakeholders present their change requests mostly on the front-end.


In order to start working, we needed to identify the required tools to mock API responses, for that, we built a simple server mocking utility returning plain HTTP responses and named it Mockserver, check it out.

First off, start by installing Mockserver, it is hosted on the amazing NPM.

npm install -g mockserver

You should see the following on your CLI:–

Mockserver serving mocks under "./mocks" at http://localhost:9001

In a directory on your machine (home directory, for example), create a folder name ‘mocks’

mkdir mocks

Boot Mockserver on port 9001.

mockserver -p 9001 -m './mocks'

Going back to your mocks folder, start creating files with ‘.mock’ extension in directories representing the request path.

  1. For a plain GET request (‘GET /shipments/list’) for example, would lie in mocks/shipemnts/list/GET.mock

Sample content of ‘GET.mock’:–

HTTP/1.0 200 OK
Content-Type: application/json

{"id": ['12345', '67890']}
  1. For a GET request with query parameters (‘GET /shipments/detail?id=12345’), would lie in mocks/shipments/detail/GET--id=12345.mock

Sample content of ‘GET—id=12345.mock’:–

HTTP/1.0 200 OK
Content-Type: application/json

{"country": "UAE","Emirate": "Dubai","Area": "X", "Street": "Street 1", "items": [{"id": "12", "name": "Test"}]}
  1. For a GET request with a specific header (‘Device: mobile’), would be mocks/shipments/detail/GET_Device=mobile--id=12345.mock

  2. For a POST request with a body (‘{“street”: {“Street 15”}}’) to ‘shipments/address/new’, would be `mocks/shipments/address/new/POST_{“street”:{“Street 15”}}.mock

Sample content of ‘POST_{“street”:{“Street 15”}}.mock’:–

HTTP/1.0 201 OK

The idea here is that no matter how complicated your application is, you must end up with plain HTTP at some point. Simplicity is key with Mockserver.

Best practices

Now that you have your mockserver up and running, you can start building your application, some guidelines:–

  1. Make sure that your application is very well tested with automatic testing and good coverage.

    This will come in handy as the change requests start pouring in as you start presenting your application for review. It will also help in keeping the backend API design and implementation in-check of the requirements.

  2. Identify pieces of the HTML in your templates that should not be changed or renamed for the designers so that your tests won’t fail.

    Designers will start adding the required CSS, HTML classes/IDs in order to give the application its shape. Your tests are probably rely on some HTML tags to make sure that everything is as it is supposed to be.

  3. Keep a line of communication between you and the backend API project manager in case of any changes are required on the data to be presented.

  4. Make sure that your project timeline is tracked in such a way that the backend development is completed by the time the designers are done with their work and the front-end reached its final review stage.

The last step would boil down to just switching the backend URL on your front-end application to point to the actual API, and Voila.