In the My Vodafone NL app, we’re using the BFF pattern. BFF stands for Backend for Frontend and is a software pattern where all the business logic of the app is moved to the backend.
Blueprints
In the mobile app, we’re working with blueprints. A blueprint is a view that is defined in the app, for example a slider. In the iOS app, the SliderView is defined, which must contain a min, max and current value. The backend will return a JSON object, which include the type of view that should be displayed (SliderView), and contains the values that are needed to display the slider.
In the My Vodafone app, we’ve got over 30 blueprints, which are custom views like a card, a slider or a simple label. For every custom situation, there should be developed a new blueprint.
Navigation
Each clickable blueprint already contains a destination. That destination object already contains the title for the NavigationBar and also the new API call which needs to be called as soon as the user pressed on the blueprint.
By doing this, users can press directly on a blueprint and there will be no delay in the transition to the next page. On the next page, a spinner can be displayed to indicate a backend call is currently done. As soon as the data is received by the mobile app, the blueprint views will be visible.
Benefits
By using the BFF pattern, it allows us to share logic between the iOS and Android apps and make functional changes without needing to release a new update for the apps itself. All logic is handled by the backend, so if the backend will deploy new functionalities for existing views, this can be directly visible!
Also, all the business logic is done in the backend. For apps that may need many business logic, this may be a great solution to prevent multiple business logic implementations between Android & iOS apps.
Another benefit is that developing in the future will be very fast if use is made by already defined blueprints. Only backend development is needed, because the blueprints are already available in the app.
Disadvantages
Every design pattern may bring some disadvantages with it, as also BFF does. One of them is the ‘generic’ style that is needed. Every component needs a generic name, because it can be used in different situations, on different pages with different content. Because of this, new developers in the team will need some time to understand the the possibilities of all the different views, including the locations where there used.
Also updating ViewControllers in the stack is very tricky, because every page is generic and does not know that much about itself. Currently we’re using unique ID’s for each page to listen for changes, which is explained in the video.