The obvious BFF, an old friend
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
- JavaScript to provide interaction
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.
User expectations
Web Applications tend to be more and more interactive nowadays. Where we once navigated between pages and expected a load-time in between, we now expect a seamless integration of each feature or information source without constantly reloading. More and more interactivity is demanded. From adding an item to your basket to playing a song while navigating for the next one directly in the browser, it’s all a demand on interaction, and thus our old friend, JavaScript.
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).
With the rapidly increasing movement towards Progressive Web Apps (PWA) we start an enablement of even more features. Think of accessing the camera, working offline, sending push messages, doing payments, obtaining GPS data, storing data locally — all in the browser with app-like behaviour. Mastering JavaScript is more than a nice-to-have skill for your next colleague; it’s a necessary skill.
Front or Back-end, who cares, really..
Because we wish to enrich and invest on all that is happening in the client that directly interfaces with the user, we basically would like the server side of things to follow suit. All effort that is focussed on keeping these experiences in sync is a waste of time, energy and money. Since we are bound to JavaScript in the client, but can choose everything in the backend, why not just choose Javascript for the backend and leverage a framework that enables the code to be written only once?
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.
Conclusion
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.
At Jumbo we are transitioning to a Javascript Backend For Frontend (BFF) running Nuxt with Vue already. Even though we don’t have a policy on the higher level languages we use to compile towards JS, CSS and HTML, we are well on our way in our revolution towards a JS BFF separated from any datasources with a Service Oriented Architecture.
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.
