When you are making big changes to your current stack, or even start with developing an entirely new stack, you’ll immediately hit a familiar discussion. What technology will we use.
Some choose to take an ostrich approach by sticking the head in the sand and pretending this isn’t a relevant topic. Usually this means that the first one that rushed to the scene will either start in his or her favourite language, or the most promising exotic new language they know. We repeat what we know, and therefore act like sheep.
Is this a bad thing? Well, not necessarily because the prime goal is getting the job done, but with making a choice you take the good and the bad, and it’s relevant your choices are as much as possible in line with your goals.
This post aims on giving some considerations regarding valuable technologies for a web-based Backend For Frontend ( BFF, not to confuse with Best Friends Forever 😉 ).
What is the bare minimum?
At the moment of writing, we are simply bound to some technology standards.
- HTML as a structured data source
- CSS to style that data
And then we need:
- A browser (let’s call it client), able to combine these three to convey an ‘experience’ to the visitor
- Something that generates or relays the content towards the client (let’s call this server)
Whatever we generate in our backend, it will (almost) always be converted to these technologies, and transferred from a server to a client. Since we have a minimal dependency on this, we should take this into consideration when we start making choices down the line for tiers that provide for this output.
On the other hand we need to be able to provide at least the content through the conventional model of server sided rendering. That is important for e.g. crawlers but equally relevant for clients that are less enabled to receive the intended experience (think of accessibility).
Front or Back-end, who cares, really..
The bigger your application grows, the more repetition of elements you’ll find. We’ll need to address that as well. Ideally we want to isolate these interface elements and all that belongs to them. It’s important to parameterise them, isolate all style, data, and interaction for them so they are easy to comprehend and adjust.
We want to be concise. We can do this by reducing the amount of characters we have on our screens and giving the ones we do see more value. This means more bang for buck. Think of things like:
- utilise the whitespace, don’t make it a preference, make it meaningful (what e.g. Python is praised for)
- remove as many special characters as can be done and make the written words more descriptive
- abstract away all compatibility with older versions
- close knowledge gaps as good as possible
- isolate as much as possible to the subject at hand
- and when all the above is done, there should be no need for type definitions. They provide a false sense of safety and often add more confusion and fluffiness than they yield any benefit. Remove as much characters from the solution as possible.
So when all the above would be translated to languages or technologies, the following would be my preference:
- Write your data structures in Pug
- Write your style in Sass
- Write your code in CoffeeScript
Because all of these adhere exactly to the previously stated requirements.
Then we can leverage:
- Vue for component isolation
- and Nuxt on Node.js for front / back end rendering.
which will take care of the isolation and utilising a single source of code for client as wel as server rendering of our solution.
And maybe that’s the beauty as well. As long as you accept that JS as server sided language and having isolated components makes most sense, you have the correct outlines. The higher level programming languages used can take all the time they need to prove or disprove themselves. But whatever you do, don’t act like sheep and do what’s done so many times before. Reconsider the options whenever you start something new.
This article is a cross-post from my original post @ https://medium.com/jumbo-tech-campus/the-obvious-bff-an-old-friend-4fdc1ad1e6d for Jumbo Supermarkets NL.