Juggling the multi-service dependent frontend 🤹‍♂️
Tags: webdev, javascript, productivity
Published: 2020-05-07 13:49:43

---
title: Juggling the multi-service dependent frontend 🤹‍♂️
published: true
description: Architectures are moving towards separation, what does that mean for frontend engineers and how you could go about tackling it.
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/ohacatlinjqouxstb2hn.jpg
tags: #webdev, #javascript, #productivity
---
_Architectures are moving towards separation, what does that mean for frontend engineers in the way you develop and test and how you could go about tackling it_

## The age of Separation
In the last couple of years, system architectures independent of actual scale, have shifted towards __separation__. Separation, in many production-grade applications we see today, means a mix of different (micro-)services which aim to model the different _bounded contexts_, if you may, of a system and its interactions with the world.

Especially in larger organizations, separation translates into diverse, more specialized and efficient teams that focus and are responsible for their domain service. Naturally each of these teams will be developing one or more services to interface with the rest of the system. 

![Services](https://dev-to-uploads.s3.amazonaws.com/i/4o4aco6vpm2bl5o8l3bd.png)

This approach has expectedly lead to re-evaluating the way the frontend part of a system is architected and how many _tenants_ it needs to communicate to, to reason about its behaviour.

### A typical modern frontend
What the shift towards separation meant for modern frontend applications and the way we as frontend engineers work on them? 
_Let's first establish the basic responsibilities of a common "frontend"._

The frontend part of a system is having the least responsibilities to:
\- Present a normalized state of the system to the user.
\- Dispatch service actions that are generated from the user completing the application goals _for example creating an account or booking a hotel room_.

Especially for creating a presentable and solid view layer, a frontend application needs to reach for the system services _(which could be many)_ and retrieve the required data to generate the state for the interface.

![frontend architecture](https://dev-to-uploads.s3.amazonaws.com/i/ux0ockl68bmze8hmsciy.png)

Probably your application will need to reach also external services for concerns like translations, authentication and other third-party data APIs (_e.g. Google Maps_).

_Remember that all the above are just the ones that we pull data from._

Consequently, when we start developing our part of the application, we would require some of these data sources to be available even partly as a _sample_ to build upon.
Then afterwards will come styling, optimizations, broader compatibility efforts and all the other nice stuff we love working against.

### Frontend development and testing for those environments
While working (or planning to work) in an environment like that, you will quickly understand that in order to create a new feature or subsystem in isolation, you must not depend on external services being available. Cause there are times when they will not be or if they are, they might not be up-to-date.

#### Developing in isolation 👨‍💻
Some common ways that teams choose to deal with service dependencies* during development are:

1. Using staging environment API endpoints for their services.
2. Running a local copy of their backend monolith.
3. Using Docker to spin-up multiple local services.

_* External data-fetching services are some times not even available at staging/development environments._

If some of the above are done meticulously with a light setup, that is a great place to be. But sadly this is __rarely the case__.
Most people will need to fight their way through setting up their development environment, with lots of "hacks" that are to be _maintained ad infinitum_. 

![hacks](https://dev-to-uploads.s3.amazonaws.com/i/hz8rgcsk7bm8k5otnywf.png)

This processes is even becoming a part of the onboarding for a new member. A pretty poor initiation ritual if you ask me 🤦.

#### Testing your feature against the system 🔧
On the testing aspect, except for unit or integration tests, there should also be tests in place that really validate the application level workflows that your feature is contributing to. These are mostly mentioned as _end to end_ tests. As the definition implies, the way to write and reason about those tests is tightly related to the external services the system depends.

Furthermore, this type of testing and how it should be conducted can still become a heated matter 🔥 in conversations between technical members of a team.

_Should/Could it be run during development ?_
_Should we only run these tests in the CI server where all system components are built independently ?_
_Should the QA or the engineers be writting and validating these tests ?_
_..._

All the above concerns are valid but it is not up to an individual or the community to define what best suits __your system__. Go with what suits __your team__.

One common caveat (_and misconception in my opinion_) around these tests is that they require a full-blown backend/service system to be up and running. Due to the nature of our modern architectures we discussed, this is becoming more and more complex, "heavy" or sometimes impossible to fully set up. 
As a result, teams are drawn away from end-to-end tests and not validate how the whole application is behaving with the new addition, not up until the final step of the build pipeline. _So much lost potential for improvement._

<hr/>

After all the hurdles mentioned, what is something that a team can experiment with and eventually adopt in order to alleviate the pains that multi-service dependent frontend applications bring to engineers ? 
_I will go about with my proposal here... just mock it off!_

### Mock it off 🤷‍♂️
A tried and true solution to these issues, chosen by many teams, is __mocking__ or otherwise __stubbing__ those service API responses that your frontend application requires.
_API Mocking is the process of simulating a set of endpoints and replaying their expected responses to the caller, without the refered API system actually being present._
By doing that, you can have a defined API schema with example responses bundled up for the services you depend on and available for consumption during development and testing.

The consumption of these "fake" responses usually happens from a static server that, provided the endpoints, gives you back the matching payloads. The mocking schemas could either be hosted and updated by different members of the team, being stored in another application like [Postman](https://www.postman.com/) or even be part of the frontend repository.
As a frontend engineer, you just want to open your development server and see the interface you will be tasked to work on. Now the weird parts of setting up and consuming a service, which at the end of the day you just needed the API response, are abstracted away from you.

![serving from mock](https://dev-to-uploads.s3.amazonaws.com/i/qu7nm033duomt9r2skek.png)

Depending on the needs and the mocking server implementation, you should have the ability to also tweak the payloads and validate your frontend against _special cases_.
_What if a service returns a different "Content-type" header? Or decides to randomly start streaming "video/mp4" data?_ Sounds unlikely but you can experiment with many cases that might break your implementation. It will surely leave it in a more flexible and reliable state than before.

Additionally the setup for a new frontend engineer will become a breeze. Just clone the repository, start the API mock server and you can just start working. This can also hold true for backend engineers that are working on these separated service architectures, having the set of endpoints readily-available for all the connected services. Sounds sweet 🍰!

Going a step further, think of all the nice things we have nowdays, by using something like [Google's Puppeteer](https://github.com/puppeteer/puppeteer), you can run even _end to end_ tests really fast with our mock server supporting us by filling up all those services that would otherwise needed to be present.

Most of all the benefits though, in my opinion the one that holds the largest stake is __reliability of your development environment__. It becomes portable and independent of the availability of external systems. _You can even code on a plane without internet connection!_

#### For sure there are tradeoffs
As in most things we juggle with every day, there is not silver bullet, and __mocking does not claim to be one__. It proves to be immensely helpful abstracting away many intricacies of the system but there are maintainance costs and communication costs when trying to introduce it to a team workflow.

### So should you ?
Considering all the benefits and expected drawbacks, you can hopefully make your informed decision if and when it is the right time to try out _API mocking_ in similar environments. The tools available are many, with approachable offerings and successful track records. In my opinion it is definitely worth the try.

_If you feel like it, I have written about a way that I have found makes mocking a breeze for some use-cases_
{% link https://dev.to/igneel64/how-to-mock-your-frontend-application-environment-in-about-a-minute-2oa4 %}

_Drawings made in the amazing [excalidraw](https://excalidraw.com/)_