Front End Architecture — Part 1.5
Published: 2021-11-23 14:00:20

![bakery display](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9qul7f105lnsmjzd52n6.jpeg)

## 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
```javascript
// 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
```javascript
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.

## Random quotes
> My mind is made up, don’t confuse me with the facts!
> Eternity is a long time, especially towards the end. — Woody Allen