How do I integrate the backend into the frontend

How you should (not) organize your next web project

Nowadays there are probably only a few whom we have to convince of the importance of a modern, high-performance front end for the quality and overall impression of a website. At the same time, it should be well known by now that a horizontal division of your development (in our case frontend and backend) and the completely independent provision of these layers will hardly lead to good results. But then what is the most effective organizational approach?

Let's assume it's time to implement a new web project or relaunch. You have already selected the right underlying platform (e-commerce or content management solution) that meets all the requirements of the 21st century. Everything is well planned and now all you have to do is make sure that your actual project is implemented successfully. Fortunately, you've already hired the team of your choice of platform - so everything should work fine, right?

One moment! How about the implementation of the front-end part of your project? All of these chic, thoughtful designs need to be translated into a powerful trio of HTML, CSS, and JS. There is a possibility that you will be tempted to choose a separate team for this - be it to avoid dependency on individual service providers or because you have already selected a separate creative agency, which of course also offers you front-end development. After all, frontend technology is pretty standardized these days and there shouldn't be any problems for other developers working with third-party code, right? The short answer is no.

In our experience, that's a pretty bad idea (we've seen this more than once on the service provider side). In the end, this almost always leads to more effort (and of course corresponding costs) or to lower quality — or (in most cases) even to both. Let's talk about some of the reasons why:

  • Platforms have their own specifics and are not really agnostic about the front end (or the technology behind it).

  • Independent front-end developers simply lack the context in which the code is used.

  • The API between backend and frontend is often not clearly defined, usually project-specific in detail or generally platform-specific and can change continuously.

  • Then there are the usual organizational problems that are by no means uncommon, but just as often are not really addressed - such as fuzzy responsibility of those involved in the project (especially when non-technicians are supposed to separate technical teams from one another), communication effort, differences in coding standards and much more.

1. Platforms have their special features

Even though platform vendors often try to offer a free choice of preferred front-end frameworks (or even the entire front-end approach - by offering a headless API), the basic question still remains, how is the easiest way to get your front-end into the platform can be integrated. Yes, I consciously say 'integrate' because in most cases the front end is not only responsible for simply displaying information 1: 1 that is provided by the platform of your choice. Let me give you a few examples to explain what I mean. Your editorial environment most likely offers mechanisms and tools with which editors can more or less freely create pages consisting of reusable function blocks and agree on how to call these components. They are often automatically surrounded by additional HTML containers that are required for display in edit mode. This can mean adding HTML tags that break your style sheet logic, causing the page to display incorrectly. Another example: You optimize the content in the visual editing mode of the editorial platform. Once you've changed the properties of just a single component, you might expect that only that part of your website will actually need to be updated (that one component). However, if your component is "dynamic" and uses JavaScript events, for example to ensure that the page is fully loaded, it will display incorrectly in edit mode because the "onLoad" event is simply not raised. All of these problems mean that in edit mode there are often minor problems up to and including completely unusable pages.

2. Lack of context

Front-end developers can easily translate designs into a product that appears to be directly deliverable using a browser (or a nice-looking click dummy). The problem is that it is almost impossible to design all possible cases for, for example, product detail pages (imagine the number of combinations of product names, general information, feature lists, and marketing materials associated with a product, product gallery, etc.). This means that front-end developers only ever work with a very small subset of real content (combinations) of your website. This is a real problem, especially with larger websites. If there is no detailed communication about the elements that will later be used in variants or recombined, there is a very high chance that many values ​​will be hardcoded or designed in a way that later makes the required recombination impossible. The more information about the intended use of the front end is passed on to the front end development team, the less work this problem will later cause. Another real-life example: Assuming you forgot to mention to the creative agency's front-end developers that you are not just implementing drafts 1: 1 and considering reuse or recombination, then you may have problems insert an accordion component twice on one side. We have seen implementations where by clicking the first element of an accordion you expanded the first elements of all the accordion components on that page. Assuming you now claim that a separate team of front-end developers can only implement the look and feel (HTML and CSS) and not necessarily the front-end logic of a website, this problem area is probably still valid. In addition, we would then not get a fully implemented front end. And one last example that falls into the same category: If you forget to explicitly pass this information on to your front-end developers, there will almost certainly be problems with the implementation of language variants on your website. An otherwise good UX / UI design may even be downright destroyed in the end (e.g. based on different word lengths depending on the language) and a large part of the fronted code must then be subjected to a complex and expensive refactoring in order to add support for multiple languages.

3. Frontend, backend and API

It is really tempting to separate frontend and backend development from one another — and there are certainly projects where this is possible and useful. However, this is hardly the case with projects that are based on the common e-commerce or content management platforms. In our experience, the API between frontend and backend in most of the established company-oriented platforms is defined exclusively in terms of HTML, CSS and JS. Changing one of these elements will most likely also affect the integration. Why is that important? Most importantly, because you cannot simply adopt the HTML, which was created by a (separate) front-end development team, into your platform project. There is very likely a (hopefully not too proprietary) system-specific templating engine that comes with the platform and that ultimately converts the data maintained by the editors into HTML. Since front-end developers often do not have direct development access to the platform, these parts are usually carried out by back-end / platform developers. Now imagine a long list of changes (change requests, bug fixes) applied by front-end developers (in HTML, CSS and JS). Once the changes are implemented, the platform developers must apply these changes to all templates and components. In our experience, this step is one of the most error-prone parts of the whole process. It's very easy to overlook just one additional attribute added by the front-end team, or overlook a slightly changed order of HTML elements. And it's extremely frustrating for the business department — especially when the front-end developers managed to get their part right, but it still shows up on the production website due to a small template bug. Version systems like Git don't really solve this problem either. They certainly make it easier to understand the scope of any changes, but since the front-end code is duplicated due to the principle separation, the automated merging of changes does not really work beyond that. Platform developers therefore often have to manually and individually each change in their Trace the code part.

4. Organizational problems

First and foremost, we strongly recommend that you do not implement your project in phases in which an allegedly completed part of a system (backend / platform integration) follows another (frontend). In general, none of the finished parts can be used as a simple plug-in solution for the other, even under ideal conditions without any change requests (which is really more unlikely than ever due to the lack of detailed specification documentation). Nowadays, changes must always be made so that a product or a solution actually works in the end (technically, functionally and visually) and becomes a real customer experience. In addition, the sequential execution of the front-end and back-end work means that the entire system remains unusable until the other part is finished. It not only postpones a 'Go Live "into the future, but also makes it difficult to set priorities across an entire project and to update them continuously, since each part is more or less self-contained. It is also worth mentioning that that working first on the front end and then on the back end (or vice versa) could not be further from the agile working method mindset. If you are considering your project to follow Scrum (or another agile framework), any approach that separates from Frontend and backend development is clearly off the table.

So what is to be expected from an approach of front-end development (e.g. when creating a static click dummy) first and back-end development afterwards?

  • Long discussions and modifications of the frontend code before the backend team can actually take over the work done by the frontend team in the backend system.

  • Problems with the implementation of any kind of changes - they have to be processed by both teams and possibly introduced into two completely different code bases (front-end code is duplicated for the click dummy and the actual templates of the content or commerce platform )

  • Unclear responsibilities for troubleshooting: If something is not included in the static click dummy, but turns out to be a frontend error, which team is then responsible for resolving the problem? And then, of course, remember that bug fixes are also changes (see previous point).

Nor is it that the 'front end first' approach is the only problematic approach — building the back end beforehand is also extremely problematic. The most important problem is certainly the lack of any (meaningful) visual representation — and that for a long time in the project. This can be really nerve-wracking for the business unit wanting to see implementation progress. Since larger e-commerce or content management implementations usually take some time, it can also be extremely difficult to decide when exactly to stop working on backend features and move on to frontend development .

Even if you choose to have your front-end and back-end teams working together, there are still some organizational challenges to overcome. First and foremost, communication between the teams. It is imperative that you define a simple and productive way of working together. In addition, our experience suggests another key factor for successful teamwork. It is important that the teams are on a similar technical level to easily communicate and understand problems, suggestions, and solutions. To make a team setup effective, you should define a clear workflow between front-end and back-end teams that ensures that changes can be introduced quickly and that duplication between teams is minimized.

Conclusion

Working completely independently on the backend code and on the presentation layer (e.g. by having two service providers concentrate on it independently) is difficult. There may be advantages to such an approach, but the disadvantages generally far outweigh them. We recommend that you avoid this approach altogether, in the interests of the success of your project and for the smoothest possible implementation during the project.

Here are 3 premises that can lead to a more successful project in this regard. This checklist is intended as a guide and we understand that not every project is the same.

  • Make sure that the service partner responsible for implementing your e-commerce or content management solution has a competent front-end development team. By competence we mean that the partner is really able to deliver successful digital customer experiences that deserve the name. A partner who is up to date with the latest (also proven) web technologies can also use them in relevant projects in practice. From our point of view, all other criteria pale in comparison to this one criterion.

  • If, for whatever reason, you are looking for independent front-end and platform integration teams, make sure that your platform and front-end teams are compatible with each other and, in the end, work as one team towards a common goal instead of parties working independently of one another. There should be no front-end development phase before a backend development phase. The teams should work in parallel and immediately evaluate and integrate their work. It can take some time to get the teams to work productively, but it is definitely worth the effort if you want or have to work in this setup.

  • Make sure that the interface between frontend and backend is clearly defined for everyone involved in the overall project. This is a major factor in terms of productivity. Ideally, back-end and front-end teams can exchange data that corresponds to an agreed scheme. In this way, back-end developers concentrate on expanding the platform and making the agreed data available, which is needed to create the user interface in the front-end part of the team. One possibility is also to work on the basis of REST or GraphQL as an API. By using such APIs, you gain a lot compared to the classic HTML templating approach, and that too quickly. You can also benefit from some useful tools for learning, documenting and testing APIs - Swagger, Postman or GraphiQL to name a few.

If you want to learn more about this topic - better interfaces and thus better collaboration between front-end and back-end development in e-commerce and content management projects - stay tuned! We'll talk about this in more blog posts. And if you don't want to miss that, the best thing to do is subscribe to our newsletter.