Accelerating delivery, reliability and process efficiencies

When it comes to my engineering, architecture and strategy work, the first thing I ask is: “how can I make this easier/better?”

What follows is the narrative of how my team and I simplified and improved one of the most monotonous aspects of Back End (BE) to Front End (FE) relationships to make it quicker, easier, and more effective all around. 

It boils down to one thing:

Contracts.

The ‘90s, when GB and France met in the middle whilst drilling the Channel Tunnel (I refer to this image frequently when explaining this approach).

I really like the photo above. The two teams meeting in the middle as they drill through the tunnel reminds me of the astonishing feat of engineering that took place.

Luckily for me and my team, software engineering isn’t quite as complex. 

But there are some similarities. 

Software engineers can often find themselves staring into the unknown, especially when building FE applications that rely on APIs and the like. Even detailed planning and pre-alignment doesn’t always light the way. 

Here’s an anecdote of how we tackled such a challenge. I’ve also thrown in a few extra positives that came out of the experience for good measure. 

How we did things before 

Picture this.

A project begins, The BE team works on its API endpoint and sends it to the FE team who run it and use the response to construct their code. 

It’s a common approach; one that involves the two teams working synchronously, but not necessarily in harmony. There’s a lot of back and forth which inevitably leads to issues and blockages.

You know the drill: waiting for BE to provide mock objects so that you can build out FE features, all the time unsure of what will be optional and what won’t. Countless other problems are liable to crop up along the way too. 

I’ve been there. In fact, I was using this approach last year. The alternative – and in my opinion, better – approach takes a lot of companies a long time to embrace. Persuading people can feel like a mammoth challenge. 

But once you have the new techniques in place, like we did, you’ll never look back. 

How we do things now 

The main component of our new approach isn’t anything mindblowing. 

It’s planning. 

The initial step is to get the project leads to work in tandem to plan and figure out the required data. We use designs and minimum requirements, among other things. Usually, the product and design team will have scoped and specced the majority of the feature.  

Then we define our contracts. 

Our contracts are our single source of truth that informs all the work. 

You might decide to call it something else, but we use the term “contract” because when you think about it, it is one: an agreement both parties agree to. 

The contracts are the middle point – the point at which the two teams meet.

When the contract is in place, the two teams can work in parallel but constant communication just isn’t necessary. As a result, delivery is accelerated: we converge at a predetermined point, thus cutting weeks or months off the delivery time. 

You can start this approach straightaway without any technical changes. However, the technical changes do make a difference. This relies on:

• Documentation

• Type generation

• Atomic/molecular components

The pieces of the jigsaw

From a BE perspective, all APIs will need documentation. At Funding Options, we use Swagger/OpenAPI (other mechanisms are available).

Next, we use the docs to generate TypeScript types using DtsGenerator. These are used throughout the FE application. 

When the types are available, this is your cue to start building out the components.

Our approach is an atomic/molecular one. 

We use Storybook to develop the components and variants. In conjunction with type-driven functions, the components match the designs. They’re subsequently tested based on the types we have, so there’s no need for a working API. 

(For example, an object has an optional prop that may affect the way the component looks or works. The types dictate the way the code works and the tests/stories back these up.)

Ultimately, our approach enables us to keep various teams running in parallel and accelerate the delivery. All potential variances of our components can be handled because we use the automated types based on the documentation.

The reliability of our codebase is improved as a result.

But above all, the new process has eliminated a great deal of needlessly complicated communication between teams. By working out the middle, or the “single source of truth”, everyone knows what everything should look like. 

It’s safe to say that the FE and BE teams have never got on so well as they do now.

Possible hurdles

I’d be lying if I said the approach is problem-proof, however a solid QA process will help pull up any potential roadblocks. 

One such roadblock is the need to extend the APIs; this could obstruct the FE development and cause setbacks. In my opinion though, the positives far outweigh any negatives. Go on – give it a go!

If you’re excited about finding interesting and innovative solutions from large pools of data, check out our open roles and explore a tech career at Funding Options.