Front End Architecture — Part 1.5

Putting things in places… more theory

4 min readMay 30, 2020

Story time

I love sourdough, so I decided to visit a small bakery that was supposed to have the best bread in London. It was not close, but honestly, what is in such a big city. I felt good about the place as far as first impressions go and so I finally ordered what I came for.

And then something strange happened. Instead of being handed some crispy carb-bonanza that I was really looking forward to, I got some organic wheat and some water accompanied by a bit of yeast in a little container. Before I could ask what is going on, was I perhaps being punk’d, I received a piece of paper with instructions. It said I should go to this other place on the other side of town with my ingredients. Depending on which day it is, I should present some of my things I got in a specified order and say the magic word 3.14 times. Needless to say, I never went back.

So what does this little tale have to do with front end architecture you ask? And my answer is: everything. Every time I have a discussion with an API provider or the owner of a microservice, essentially it’s the same as the story above, only the details are a bit different. Exchange sourdough with data, small bakery with microservice, travel with latency, ingredients with parts of the information I asked for and the other place I need to visit with multiple new API calls I need to make. Probably you would not recommend that service to anyone as much as I would never visit such bakery.

Example time

Over time I developed a bit of an OCD for useless information on the client side, so here are some “real world” examples that make my toes curl.

Magical Strings

// get my items from the server
const items = fetch(...)const magicalStringsThatMeanHidden = ["HIDDEN", "DONT_SHOW", "DONT_DISPLAY", "WOULDNT_DISPLAY_THIS_IF_I_WERE_YOU"]const itemsToDisplay = items.forEach(i => !magicalStringsThatMeanHidden.includes(i.status))// and then display them

In the above example it would be preferred to fetch itemsToDisplay directly from the server instead. The magicalStringsThatMeanHidden is a hidden and quite fragile contract between the API and its consumer. The owner of the service might think that he is in full control of it, but he is not.

This pattern is also referred to as napkin driven development (NDD), as there must be a napkin somewhere that says: here are my statuses that mean the item is hidden.

Data Links

const items = fetch(...)const itemsWithDetails = Promise.all(items.map(i => fetchItemDetails(i.id)))

Even though in the above example all promises are executed in parallel, this still adds quite a lot of performance problems to the client. It is always more efficient when servers do the communication directly (clients paying quite an overhead to make requests, especially on mobile networks). Not to mention that the client shouldn’t even know about how to make such a request as they don’t “own” the items’ domain. The same logic can be applied to extending the original API (or moving it to GraphQL).

This time we wrote something else on our napkin, but it still exists and it is still unnecessary.

Rule of thumb

So what exactly is business logic and what are the implementation details that the front end shouldn’t know about? When it comes to data, I think the answer is that the consumer should know as little as possible about how the data is kept, handled and distributed. Ideally you have a gateway that you can talk to as opposed to remembering all the API endpoints. These would have to be named intuitively and could never change (naming is hard, backward compatibility is even harder). When using a gateway, you can easily describe the data you want with a “query”, like tell me the user’s name and address and some of their orders’ details.

Next up in Part 2

In the next article I will try to push this idea of a front end architecture even further. I will describe a way to load only the things that the user needs, when they need them, keeping the system as lean as possible. Good luck to me I guess…