Atomic UI / API Pattern

One of the main issues that UI Products face when it deals with a MicroService backend is the need to coordinate API calls and successfully commit all changes (when made by the user) in a Atomic level. It's tricky to do this as individual API calls can fail or be slow to respond and the UI might will probably maintain an interim Data State/Store (basically an object in memory) which then needs to be remapped to the API schema and saved over REST.

Let's look at an example:

• Our UI Screen needs to render something (trigged by a Client side Route Change on the Single Page App - SPA)
• The screen requires data from multiple MicroServices as the Screen is composed of different object elements, it makes multiple MicroService calls to gather all data needed to generate the Screen Content and Input Forms
• User interacts with the data (adds something, edits something etc) - the UI App has to maintain these changes locally using an interim, browser based Data State/Store
• User commits to publishing the data in the screen (which they have edited via a form) and "Saves" it. Business Logic in the UI needs to coordinate and remap the local Data State/Store to the various MicroService endpoints and SAVE/PUT

There are multiple failure points to this approach:

• If the local Data State/Store is not handled with immutability then there will possibly be side-effects to that data (caused by bad coding)
• On saving, some API calls may fail whilst some may succeed. This will cause a disconnect in the UI level as to what the server knows to be the correct data and what the UI believes to be the correct data (as the local UI will be bound to the interim data state)

One approach around this is to follow an atomic API -> UI relationship.

Where ONE Screen gets all it's content from ONE API and saves back to ONE API.

I'm not sure if there is a term that describes this pattern (if there is please correct me in the comments), but I'm calling this the Atomic UI/API Pattern.

This seems to be a common practice followed by the large UI Products in the world (Netflix, Facebook etc) using tools such as GraphGL.

I'll write more on this soon...