Selecting user interface patterns and integrate with APIs

Abstract

Continuous improvement is the buzz word in the IT world today. First, you introduce possible options for user interface (UI) and accessibility to web applications. Thereafter, you continue to analyze appropriate UI and solutions to offer. With a clear separation between frontend and backend, developers can work in parallel and not interfere with each other. The result is a higher speed of development, as Controllers are not attached to any specific Views anymore.

In an era of digital transformation and journey to cloud offerings, the current IT world is faced with challenges and is also reaping benefits. By embracing digital transformation, distributed business model processes and services are brought together. The underlying IT systems engage with different technologies to work together in a seamless way by adapting the API-led connectivity approach. This is where API integration comes in and aligns with different UI or any external system integration patterns.

Purpose

Over time, the digital ecosystem has adhered to the demand to adapt to the relevant UI space. Also, the pace in which technology is evolving (which usually understands web accessibility as an improvement and not just a requirement) and business needs to adapt to these latest technologies, makes it difficult to choose an appropriate UI for developers. This article will categorize the UI patterns based on different scenarios, limitations, and the list of considerations to type of backend applications.

Getting Started

Amid different technologies, proprietaries, and open source, these are the two most relevant, broader, and fundamental UI characteristics:

1. High user interactivity: On demand availability of interactive elements beyond the static desktop application environments (such as menus, trees, sliders, and so on) which can be programmed under any user events (such as click of a mouse, pressing a key, drag and drop, and so on) and with complete personalization.
2. High speed response to the user’s interaction: Systems must have the capability to handle user responsiveness on higher throughputs and lower latency. It could be on any level as in-tag, table, or even the whole webpage which is decided and implemented by the developer. Here is a list of the available UI patterns relevant to the present-day digital- world and their significance.

User interface patterns

• Embedded UI in monolithic web application: The conventional menu navigation also known as two-way architecture or MVC architecture pattern-based monolith UI is still a good choice based on a small set of requirements, and no rapid development and change requirements. This monolithic application has a clear separation of concern layered with MVC pattern. One major drawback of this pattern is that it is bulky in nature and it changes anything and retests everything. Common utilities of UI can be shared across UI pages and multiple databases can be handled with this monolithic design approach. While writing a cloud-native microservices app, to start with, monolithic is one among the many recommended approaches. With time, there is a chance to decompose it later.
• RIA interface: Rich internet applications (RIA) may substantially improve the user’s experience on web based on two aspects usability and web accessibility. It has a distinct isolated area known as the sandbox where the client’s serving of RIA is executed. One special feature of RIA is a client engine that intermediates between the user and the application server. The client engine downloads when RIA launches. In order to understand the problems of accessibility presented by RIA, broadly, there are two technology models where the RIA may be created:

1. With standardized technologies such as (X) HTML, CSS, or JavaScript
2. With embedded technologies, using specific (X) HTML tags that allow the execution of external applications within the user agent
3. For example, Adobe Flash and Microsoft Silverlight follow such models

From a development point of view, to implement an RIA, it must have three distinguishable layers:

1. The structure and content layer: This layer define different blocks of webpages such as header, content, footer, browser and so on.
2. The presentation layer: This is the layer on which the elegance of visual appearance is usually designed along with the layout of structural blocks using CSS.
3. The behavior layer: This layer is designed to be an event-driven aspect that programs how the page must react based on the user’s actions by directly interacting with the document object model (DOM) using JavaScript. The information updates are encoded by applying a combination of technologies known as AJAX, where you can perform asynchronous data requests to the server (that is, without reloading the page) and immediately present them to a section of the webpage.

• SPA Interface: Single page applications (SPAs) are thin client and normal web-based UI applications. In today’s digital world, a robust SPA is designed by reducing monolithic complexities. (For example – page-switch time, server-roundtrips, and so on.) There are many open source JavaScript frameworks, such as Angular 2+, React, Vue, Backbone.js, EXT.js, and so on, that can provide a SPA solution. There are some practical scenarios where SPA makes a good fitment:

1. Hybrid solutions: Though SPA architecture is more complex, and dependent on AJAX, WebSocket, and so on. for server communication, it is very useful to help develop hybrid UI application. Mobile applications are mostly hybrid in nature and can be accessed on any desktop browser as well.
2. Offline solutions: Web apps such as SPAs can handle many interactions on the client-side without even contacting the server(s). This feature allows for cutting short multiple server interactions and offers the ability to offline process to an extent.
3. Native-like experience: SPA allows offering a rich set of native-like features such as back or forward button, dynamic data loading from the server side, richer compatibility with RESTful web services, interaction with web components, and a fluid transition between page state and rich user experience.

• Monolith UI consuming microservices: Modern digital world has clearly separated UI applications from the backend and middleware system. A set of UI components are responsible to maintain the roundtrip with microservices architecture style-based backend services. In this scenario, a single monolith client-side application with an MVC-like pattern is designed to focus on logic and data to be displayed over the UI and not targeting any specific design layout of a consuming microservice.
• Micro frontends generated by microservices: A composite UI dashboard driven by microservices can be challenging. It is yet another way of writing a SPA. Here, each microservice provides its own small composite UI and each UI component is like a small API gateway. If composite UI techniques are different from techniques followed in building the traditional UI, it could pose a challenge when building a mobile native-app. However, if all microservices components are micro frontend-enabled within their own space, it becomes easier to transport, deploy, scale out and access independently. When you use a group of SPAs or self-contained executable microservices to suffice one larger business capability, circuit breaker (CB) pattern is mandatory to design the resilience and high-availability. This way, without discontinuing the entire ecosystem, as a group, you achieve something from the timeout situation that occurred within a single SPA or microservices.
• Dynamic lightweight UI components – Plug and play web components: The pieces of UI as a component are designed to be technology agnostic and dynamically a lightweight utility. This UI pattern is a cross-browser, cross-platform and cross-device to make it happen with specific plugins and dynamically make it readily available for download. Furthermore, it gives the UI designer the ability to rewrite any brownfield or write a greenfield application afresh and this offers a powerful way to enhance the UI of a website or webpage.
• For example, Tiny scrollbar is a cross-browser lightweight JavaScript or jQuery scrollbar that comes with different plugins. It is a nice and elegant way to enable content scrolling on mobile and desktop devices.
• Google polymer and web-components backed by Google API is another such option that takes interoperability and encapsulation within itself.

Progressive web application (PWAs), responsive web-design and data-driven UIs are also relevant to the digital UI architecture design age.

• Menu or icon-based CLI: The command-language interface (CLI) pattern frames the appropriate commands in the language and enters them appropriately when required. But it is not always possible to remember each command when the pace of change in the ecosystem is quite fast. Similarly, you have a direct manipulation interface that presents the interface to a user in the form of a visual model (icon, object, and so on) usually referred to as an iconic interface. In this type of interface, the user issues commands by performing actions on the visual representation. For example, pull the file to open, trace a box to delete a file, and so on. Menu-based or icon-based CLI is the best alternative to trigger commands in certain contexts. For example, open a popup window, delete any file or execute any service.
• No UI: Today, web browsers act as a rest client tool as well. It is enabled with the scope of the desired payload (user inputs) to be sent while calling a backend API endpoint. The rest client browser has a certain level of UI which generates a response preferably in JSON structure. This means you do not need a dedicated UI to some extent. This is very helpful when you just need to check the status and health of the backend API compatibility with UI responsiveness without considering the proper shape and design of the content to showcase.

Integration patterns

• Server-side page fragment composition: Backend systems may have series of fine-grained APIs available to be consumed. As we progress, we need some business capabilities to get the aggregation of data consumed. Coarse-grained APIs or pages can collaborate and include all the distributed APIs grouped as one single subdomain or business capability. This way, the API client will be required to make only a single call to such a group. When you need a front-end service to compose the pages, each API (or microservice) can have its own HTML fragments. All these fragments can have the same vocabulary for CSS, JS and so on. This approach may take more time initially but will be a more versatile and easily deployable API. This way, an independent API will be treated as a separate component or product and Angular Universal, Next.js, Nuxt.js, and so on are a couple popular tools used to develop such deliverables
• Client-side UI composition: As the API services are fragmented, UI is responsible to group them using page-skeletons that builds UI pages by composing multiple, service-specific UI components. The UI components directive (for example, Angular 2+, React.js, Vue.js) will call all APIs or series of APIs and set the priority order before it is available to the end user. The UI components can create fa?ade edge services internally which can integrate with the backend API.
• Hybrid (server + client-side) UI composition: Alternatively, a complete UI application can be built on top of the backend APIs. This will lead to a monolithic UI application with tighter UI but a better flow. GraphQL has emerged as a technique which directly calls to REST. This means it may eliminate the need for REST while calling backend APIs in some cases. Angular GraphQL, Apollo GraphQL, React Relay are some tools that simplify App development by combining APIs, databases, and microservices into a single data graph.
• API gateway: Single entry point in the backend from different types of clients or any external request to consume any API, the API gateway is most popular pattern. To promote the mobile-first aspect in cloud concept, the IT ecosystem receives a request to integrate with one single API in many ways and from many clients or devices. API gateway is the standard that handles all types of requests and as per the policy, routing, and security-key enablement, API or microservices receive the request to execute. For the API gateway to achieve better throughput, highly cohesive, low coupling and distributed architecture, is preferred so that each API service can accomplish something as expected.
• Backend for frontend (BFF): The segregation of API calls or client requests strategy are managed at the intermediate layer before calling out any fine-grained APIs to execute and serve the response usually referred to as BFF. This could be for many scenario-based segregations, but it is primarily categorized by web API, mobile API, third-party public API, and so on. This is an extension of the API gateway by separating concerns based on the type of requests.
• Client-side service discovery: When dealing with several microservices across the ecosystem, you usually register all fine-grained APIs with the service registry. The client-side as well as the server-side service registry ensures uninterrupted integration with UI even if the UI changes rapidly within the same microservices or APIs. While making a request to API services, the client obtains the real URI and location of such API services by querying a service registry.
• REST client: Nowadays, as there are more mature web browsers to perform and interact with the backend services, many web browsers work as a REST client tool. This browser is compatible to send the desired payload while making an API call. This way the API integration model is achieved, and the API status and health check are tested.
• Point-to-point Integration using REST template (low-level APIs): When using REST based communication and integration model, UI typically focuses on one API, but the same API calls another one internally. It is point-to-point integration over the REST template methods and communication protocols. Note that, this model is least recommended and superseded by messaging channel model.
• Messaging channel: As enterprises grow, the demand for business capabilities to be mapped with the IT ecosystem grows simultaneously. Multiple microservices collaboration can be achieved via the pub-sub model and event-driven architecture style. This leads to define event-driven architecture (EDA) underlined with event sourcing and event bus strategy. This way, any two APIs or microservices can collaborate and communicate seamlessly after one-time subscribing to the event bus. This messaging model also promotes the asynchronous way of communication between one publisher and many subscribers.

Similarly, there is the messaging-queue based two-way direct communication protocol model that fits in one-to-one asynchronous full-duplex communication between a client and a server. Unlike typical HTTP connections, web socket protocol is long-lived. Web browser exposes all the necessary client-side functionalities through the Web Socket object.

• Enterprise to API integration: Today’s enterprises need to reduce complexity, particularly at the IT integration level. API comes in handy here; as each API provides a code that enables communication between software programs. API integration is a way to connect enterprise private cloud, enterprise to enterprise public cloud, mobile chatter or SaaS and on premises applications as well as third-party applications. This is to achieve end-to-end communications seamlessly using the integration platform as a service (iPaaS) or middleware integration tool bounded by firewalls.
• Expose on premises assets with APIs: APIs enable legacy assets that are difficult to be cloud-enabled. To proceed with hybrid infrastructure where the client-facing applications can be modernized and switched to cloud deployment but need to establish the communication with legacy on premises applications at the same time. This way, end-to-end integration needs to interact with external firewalls or DMZ as well as internal firewalls along with the secret key tooling concept.
• System of record (SOR) designed to be a system of engagement (SOE): System of engagement is a collaborating system which ensures the required data availability is underlined by backend API integration. The system of interaction (SOI) or insight exposes API endpoints and integrates SOR with SOE. One cohesive offering serving all integration needs that is connect seamlessly, develop rapidly, and scale efficiently. For example, over time, legacy mainframe green screen (SOR) concept is now being replaced by workday (SOE) tool. This shift is to collaborate the user data directly to engage with the user’s format and demand. Here, client facing app or social media applications interact with the SAP-based backend system over the API-led connectivity approach and gets engaged to fetch the information as needed.

What Next

To meet with businesses and discuss strategical versus tactical solution plans for to-be architecture based on models and patterns appropriately identified and selected UI patterns, as guidance given here.