TIQETS.ENGINEERING
Backend-Driven App Development
How the Tiqets App team iterates fast and autonomously
Developing apps is a tricky business if you want a consistent experience on both iOS and Android. There is an overwhelming amount of ways to share code: which is the best for you? Early on in the app project, you must make architectural decisions that will have long-lasting consequences: what can help you make the right choices?
In this blog post, we are going to discuss two design patterns we use at the Tiqets mobile app: Backend for Frontend, and Backend-driven UI.
Backend for Frontend
The Tiqets Apps team follows the Backend for Frontend pattern. BFF tightly couples backend-side and client-side app development, and brings us three main benefits:
Code ownership: The team is composed of backend as well as mobile apps engineers, and has full control of the experience from the backend to the app.
Fast iteration: The team can add new features without depending on external engineers.
Less duplication: Most shared logic between iOS and Android stays in the backend. If this were not so, both apps would need to duplicate the same logic. Also, parsing and interpreting backend responses become simpler when using a dedicated backend.
Why can’t we just use a single backend for both web and apps?
Why do we need separate backend logic for the apps? After all, our business seems to involve quite simple operations: searching venues, ordering tickets, and presenting them at the venue.
Looking closely, however, the app and web experiences differ significantly. For example:
- We can offer location-based recommendations on the app and also store tickets offline.
- Optimizing battery and data usage is especially important on the app side: our customers may have a spotty connection and may not be able to charge their phones until they get back to the hotel in the evening.
For more information about this pattern, check out “Pattern: Backends For Frontends” by Sam Newman & Associates.
Backend-driven UI
We take BFF a step further applying the Backend-driven UI pattern: because the components and layouts of our iOS and Android apps are identical, we handle the layout in the backend.
The idea behind component-based Backend-driven UI is:
- The backend is responsible for communicating the UI to the apps. Specifically, which components they should render, in which order, and with what data.
- The apps are responsible for rendering these components. The app logic is unaware of what each component represents.
Below you can see an example of how the Van Gogh Museum’s venue page is built using components. Each red box represents an instance of a component. The order and content of the components is defined by the components list of the API response. We could easily change their order or add other components by only changing the backend’s API response.
Upsides of Backend-driven UI
Backend-driven UI has three main strong points for us:
Unified app experience: Both iOS and Android receive the same set of components in the same order, and thus provide an almost identical experience.
Rapid app changes: Changes that do not involve new components are made in the backend. We go live without having to modify the apps and re-submit them to the app stores.
More efficient development: Most shared logic stays in the backend, and the app code becomes simpler: it just needs to render the layout.
Downsides of Backend-driven UI
One downside is that understanding the big picture often requires looking at both the client and the backend code. This becomes especially apparent during debugging.
Also, while it’s possible to change the app experience by backend changes only, most non-trivial changes require app changes as well as backend.
Lastly, analytics becomes complex: because the apps are unaware of what each piece of layout represents, tracking user actions needs to happen both on the app and backend sides.
Nevertheless, we find this pattern useful since unified app experience is essential for us. For more information about this pattern, see the following slide deck from SoundCloud.
Conclusion
Fast iteration and team autonomy are crucial to our success. The Backend for Frontend pattern enables us to iterate quickly and simplify mobile development through responses tailored to the apps’ needs. Backend-driven UI helps us provide identical experiences across client devices.
We hope that you also will find these patterns useful in your next app project!
