Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Published : Apr 13, 2021
NOT ON THE CURRENT EDITION
This blip is not on the current edition of the Radar. If it was on one of the last few editions, it is likely that it is still relevant. If the blip is older, it might no longer be relevant and our assessment might be different today. Unfortunately, we simply don't have the bandwidth to continuously review blips from previous editions of the Radar. Understand more
Apr 2021
Trial ?

With TypeScript becoming a common language for front-end development and Node.js becoming the preferred BFF technology, we're seeing increasing use of UI/BFF shared types. In this technique, a single set of type definitions is used to define both the data objects returned by front-end queries and the data served to satisfy those queries by the back-end server. Ordinarily, we would be cautious about this practice because of the unnecessarily tight coupling it creates across process boundaries. However, many teams are finding that the benefits of this approach outweigh any risks of tight coupling. Since the BFF pattern works best when the same team owns both the UI code and the BFF, often storing both components in the same repository, the UI/BFF pair can be viewed as a single cohesive system. When the BFF offers strongly typed queries, the results can be tailored to the specific needs of the frontend rather than reusing a single, general-purpose entity that must serve the needs of many consumers and contain more fields than actually required. This reduces the risk of accidentally exposing data that the user shouldn't see, prevents incorrect interpretation of the returned data object and makes the query more expressive. This practice is particularly useful when implemented with io-ts to enforce the run-time type safety.

Download the PDF

 

 

English | Español | Português | 中文

Sign up for the Technology Radar newsletter

 

Subscribe now

Visit our archive to read previous volumes