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.
