At GDF we are always talking about developing and designing very customer centric solutions, which are very „pretty“ and very easy to use for Allianz Entities worldwide. 

Mostly we focus on the design of the applications but not on the development or what happens in the backend. 

Backend Development at GDF focuses on frontend facing backend solutions the so-called Backend For Frontends or BFFs. A BFF purpose is to provide relevant data to a specific frontend journey application in a clean and well documented way. To make the ownership, the code and the documentation clean, one BFF should only serve one frontend application. Having this clean separation is essential to be able to make independent product design decisions in the customer facing frontend layer.

Creating a BFF solution relies on intensive communication between different knowledge experts like product owners, frontend and internal service experts. This close collaboration is essential to fully understand how a frontend application collects and visualizes data provided by the customers. 

You remember our NDBX library? Or Sketch? Or Building Blocks? All tools used at the GDF to design customer centric digital solutions. Now we want to have a look on the development related tools and workflows: 

A BFF solution has two communication aspects: the frontend application facing and the internal service facing communication. The frontend facing channel is the interface or the API that communicates with the frontend application while the internal channel communicates with Allianz internal business systems. A key responsibility in the BFF layer is to fit together these communication layers to exchange the correct data.

During the API design phase, frontend and backend experts work closely together to understand and specify every piece of information that is exchanged between frontend and backend. To comfortably support the collaborative work between engineers we follow the API first approach using the OpenAPI specification. With this we can describe the endpoints as well as the API models. By adding working examples, the API documentation can be made live and executable with a tool called Swagger-UI. The benefit of the API description in this case is that it gives the consumer the frontend and the provider the BFF service the same API contract that both must follow. Another advantage is, that frontend can use the API description during test or local execution as a mock server while the APIs in the BFF can be generated. Generating code out of OpenAPI description helps to work exactly on the same API on the Java code level.

The data collected from the frontend needs to be transferred to internal Allianz software systems where it will be processed and stored permanently and securely. To craft the unambiguous data exchange solution between frontend and internal software systems is the fundamental part of GDF development experts’ job. 

For more Open Source check out how we first open sourced our GDF UI Component Library.

To ship backend solutions, we rely on well-known programing languages, software tools and practices. Java and Kotlin are the two main programing languages which were used to develop backend services. Java is a well-established and widely used language where developers from different experience background can work effectively. Kotlin on the other hand is a new, state of the art and quickly evolving language. It’s like a modern Java where you need to type less still get the same functionality. With these languages and with modern developer environment like IntelliJ, coding is fun. But programing languages alone are not enough to develop backend services effectively. Frameworks are needed which provide quality solutions for technical requirements like REST API, external service connection, security, caching, logging and so on. We rely on the Spring framework as well as on Spring Boot which helps to deliver faster and focus on features and functionalities. 

With quality product in mind we also make quality part of the product development process by considering different level of automated testing. All tests that which were created are automatically executed and provide immediate feedback about the code under test. Unit testing is on every day’s agenda where we verify that the details, the most important parts work as expected. Then we also test how the details work together by providing component tests that verify that a BFF works from the API until the external service call. These automated tests give confidence to constantly refactor and evolve solutions to meet new requirements and apply new architectural changes.