Frontend Integration with REST API's
3 methods we see commonly used for modelling
Almost every project we work on has some form of web screen that interacts with our back-end via a REST API. One common observation is that everyone has a slightly different method for mapping between the API Resource (JSON) and a Domain Model inside our Front End. Below are three variations we’ve come across together with our observations. Having read this – you should be able to decide what works for you and understand benefits and trade-offs. For our examples we’ll be using Angular 8 with HttpClient.
1. Separate API Resources an Internal Model and a Mapper
This approach is commonly visible when Backend Developers first start developing in the Front End. In Backend Development we may have one domain object and multiple API Resource. For each version of the resource the developer would usually have a Data Transport Object (DTO) and they would be expected to be able to map between both. Whilst this would be important if the Front End had to integrate with multiple versions of the backend at the same time this is extremely unlikely.
2. Resource Wrapped by A Domain Model
This one is more common; In principle the Api Resource Model is stored as a private variable inside the Domain Model. By using Accessors we can then view / mutate this and then extract the private variable when we need to send it back to the API. Some common issues is the amount of time writing these User classes and dealing with nested resources. Also – when creating MVP’s we utilise premade designed component libraries like Material and sometimes these wrapper objects require additional work to make them compatible.
3. Domain Model Only
This approach is very close to Method 1 – except instead of writing a mapper for every object – we write a generic function that allows us to map all our objects in the same way. This is our favoured method as it requires by far the least amount of boiler plate code and allows the Domain Layer to have no knowledge of the API Layer.
So what does this mean for you? In my next post we’ll have some code samples of these ideas in practice.