Decoupling frontend and backend development — The easy way!
During a project cycle, there are always situations that feel like deadlocks or circular dependencies… only seen on an organisational level. To translate this into non-nerdy language, consider the following example:
Person A is waiting for person B to provide him with data structures so that person A can implement his work package in a meaningful way. Person B, however, has no time right now, so person A has to wait until person B finally finds the time and implements what person A expects.
This can sometimes cause quite a delay, which can have fatal consequences in already tight project schedules. Can’t it? Well, in this specific case, I want to talk about dependencies between the two areas of web programming — frontend and backend. As already outlined in the example, it often happens in everyday life that the frontend developer waits for the backend developer to provide valid data structures. If we were in a perfect world, the frontend developer could work directly with “real” data and thus also discover and implement various edge case scenarios. This would be efficient, effective and would also avoid waiting times. But… reality looks the way it does…!
If we break it down to the essentials, all the frontend developer really needs is a predefined data structure, an object or an array whose inner structure the developer can rely on to develop his template, functions or what else.
So why not just do it? In the following, I would like to show you how easy it can be to decouple frontend and backend from each other in order not to lose precious time and to reduce the risk of subsequent modifications.
1. Define the data structure contract
As we know from interfaces, programming often only makes sense with contracts. Contracts on which two parties, two subsystems, two classes or methods can rely.
So let’s pretend that frontend and backend are two different subsystems. If subsystem A were to make its own assumptions and implement code based on them, and if subsystem B were also to make its own assumptions and implement code based on these assumptions, it is highly likely that both subsystems would end up being unable to communicate with each other.
But what if both subsystems were to talk to each other in advance in order to define the necessary technical requirements? Well, probably the outcome would be more successful in any case than without reaching agreements.
So the first thing to do: Frontend and backend agree together on the data structure to be worked out. With the help of this data structure contract, the frontend developer now has the possibility to implement his work package with dummy data without having to wait for the backend developer. Vice versa, the backend developer now has concrete specifications on how to prepare the data structure in order to communicate it to the frontend at a later point in time.
2. Implement the data structure dummy
At this point, the backend developer is released from further tasks for the moment. The focus moves over to the frontend. All the frontend developer has to do now is prepare the previously defined data structure in a meaningful way. Meaningful? Well, after all, it is dummy data, nothing but a sketch, that will later be replaced by “real” data and thus go into the rubbish.
The simplest method I know to sketch a data structure? Create a JSON document. For example something like…
{
"products": [
{
"ordernumber": "1",
"name": "Converse Chucks"
},
{
"ordernumber": "2",
"name": "Vans Sk8"
}
...
]
}Store the JSON document somewhere you think it makes sense or simply place it directly in the folder next to your template file.
3. Load your dummy data into the template
Of course, depending on the project, programming language, template engine, etc., there are different requirements, rules and things to consider. I would therefore like to sketch the following example in the context of a PHP application with the use of the popular Symfony Framework as well as its Twig Template Engine.
To get our dummy data from JSON into our Twig template, we need to develop a Twig extension in advance. This is a basic requirement, otherwise we cannot convert the JSON string into an associative array within Twig. Finally, we only need to provide the PHP function “json_decode” in Twig. I have therefore outlined the PHP code for the Twig extension below:
<?php declare(strict_types=1);
namespace App\Twig;
use Twig\Extension\AbstractExtension;
use Twig\TwigFilter;
class TwigExtension extends AbstractExtension
{
public function getFilters(): array
{
return [
new TwigFilter('json_decode', 'json_decode'),
];
}
}More information on how to develop a Twig extension and use it in Symfony is described in detail in the official documentation:
In the documentation you will also find a useful console command to find out whether your extension is actually loaded:
php bin/console debug:twigOkay, maybe I lied above that the backend developer is released… have the extension implemented by a backend developer if you don’t have enough experience yourself. :-)
But… as soon as the extension is loaded successfully, you can finally get your dummy data into the template. I’ll show you below how easy it is!
// load the json from file
{% set json = include('path/to/your/dummy.json') %}// convert json string into associative array
{% set data = json|json_decode %}// access your data
{{ data.products.0.name }} // which should output: Converse Chucks
As you can see, you only need to do two things: First, you have to load the JSON file. This is done with the “include” command. Because there is a string in the variable “json”, it must then be converted into an associative array. For this we use the “json_decode” filter, which we now have at our disposal thanks to our Twig extension. And after we finally have an array, all you have to do is to consume it the way you like.
4. Let the magic happen
But now you are finally ready to work on your actual task package. The dummy data is available to you for this purpose. And hand on heart: could it be any simpler? New data structure required? No problem! Create a JSON file, load it anywhere in the template as shown in the example above and you are ready to go!
5. Final clean-up
As already mentioned, our dummy data serves two purposes!
On the one hand as a contract to be able to develop frontend and backend separately from each other. This means that the frontend can already build the template before the backend delivers the real data.
On the other hand, the frontend can be filled with life until the backend developer passes the data structure from the backend to the frontend in the agreed form.
Once real data is available, the JSON import in the template must be removed. And when it is no longer needed, the JSON file should also be deleted. That’s it!
Decoupling frontend and backend development — The easy way!
Have fun!
