[SDK и UI-библиотеки] Backend-Driven UI

This is chapter 46 of the “SDK and UI Libraries” section of my books “API”. The second edition of the book will contain three new sections: “API Patterns”, “HTTP API and REST”, “SDK and UI Libraries”. If you found this work useful, please rate the book on GitHub, Amazon or GoodReads. English version on Substack.

In the previous chapter, we discussed how we can simplify the development of complex components using the model pattern. Another way to get around the complexity of “bridges” between several subject areas that we have to bring together within a single UI component is to remove one of them. As a rule, we are talking about business logic: we can design components completely abstract, and hide all translations of UI events into useful actions outside the control of the developer.

In such a paradigm, the sentence search code would look like this:

class SearchBox {
  …
  search(query) {
    const markup = await api.search(query);
    this.render(markup);
  }
  …
}

That is, instead of receiving machine-readable search results, we receive their ready-made representation from the server in the form of HTML code or another (possibly developed specifically for our SDK) markup language.

This approach can be generalized even further:

class SearchBox {
  constructor (…) {…}
  stateChange (patch) {
    // Получаем от сервера
    // список действий, которые
    // необходимо выполнить при
    // запрошенном изменении
    let actions = await api
      .getActions(
        this.model,
        patch
      );
    // Применяем действия
    …
  }
}

This example assumes that SearchBox does not contain any other logic at all, except for sending to the server events that happened to it (user or developer actions) and displaying content sent from the server.

(An example of the implementation of this idea can be considered the so-called “Web 1.0” – the server sends ready-made page content, and all interactivity comes down to following links.)

Although Backend-Driven UI has the obvious disadvantage of being demanding on the quality of the connection to the server, it has two very important advantages:

  • the ability to regulate client behavior from the server, including eliminating possible errors in business logic in real time without the need to update the application;

  • the opportunity to save on developing a consistent and readable nomenclature of public SDK entities by limiting ourselves to the minimum set of available functionality.

However, we cannot help but note: given that any large IT company goes through this phase – the development of Backend-Driven UI (aka “thin clients”) for their applications or their public SDKs – we do not know either there is only one noticeable product on the market developed in this paradigm (except, perhaps, remote terminal protocols), although in many cases the resulting network delays could be completely neglected. We would venture to say that the reasons for the current state of affairs are as follows:

  • developing a server-side UI control code is no easier than developing a client-side one;

  • modern client devices provide a wide range of functionality available only to the client developer, from caches to animations;

    • hybrid code, which partially receives state from the server and partially enriches it on the client, is much more difficult to write than pure client code (due to the fact that in the Backend-Driven UI the contents of the server response for the client is a “black box”, with which to interact additional protocols have to be invented);

    • refusal of hybrid code, firstly, narrows the capabilities of the application and, secondly, actually switches the client device to “cloud gaming” mode, which today is very expensive and not very convenient for the user;

  • The prevailing practice is that backend and client code development are different specializations that require different expertise and different approaches to writing code.

N.B.: A distinction should be made between Backend-Driven UI and Server-Side Rendering (SSR) technology. The second implies that the same UI state (usually in the form of HTML markup or similar declarative description) can be generated by both the server and the client. SSR, however, assumes that the client can interpret the server’s response and extract semantic data from it.

In terms of offering an SDK to third party developers, Backend-Driven UI effectively forces the development of hybrid code (since the practice of allowing partners to build into the server-side rendering functionality of the API provider seems to be a very unviable idea), and thus will suffer from the same opacity problems – the developer cannot, for his part, determine the current state of the visual component. Oddly enough, this drawback is also an advantage, since the API vendor retains the ability on its side to perform any manipulations with the content without breaking backward compatibility (we will discuss this issue in the chapter “Line of API services“). There are quite a lot of such client APIs in the world (primarily, various widgets, advertising APIs, etc.), but they can hardly be called full-fledged SDKs.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *