User Interface (UI) & Application Programming Interface (API)

Table Of Contents

User Interface (UI) is the point/space of connection between the user (e.g. human, end user) and machine (e.g. computer, application). Examples of UI devices are computer keyboard (end user and computer) and microphone (singer and speaker)

Application Programming Interface (API) is the point/space of connection between two interfaces/applications such as user (e.g. human, end user) and machine (e.g. computer).

Software can be API .

REpresentational State Transfer (REST) are architecture styles to ensure interoperability between services/systems


Monolithic is where an app’s source code is built to a single unit such as appname.ap. Monolithic approach is where any changes/error made to an app require the entire app to be inactive/offline to perform the change/fix.


Service-oriented Architecture

<below to improvise>

Enter the service-oriented architecture, which structures apps into discrete, reusable services that communicate through an enterprise service bus (ESB). In this architecture, individual services, each organized around a specific business process, adhere to a communication protocol (like SOAPActiveMQ, or Apache Thrift) to share themselves through the ESB. Taken together, this suite of services, integrated through an ESB, comprises an application.

On the one hand, this allows services to be built, tested, and tweaked simultaneously—no more monolithic development cycles. On the other hand, though, the ESB represents a single point of failure for the entire system—so in a way, the effort to eliminate the monolith only created a new one: the ESB, which could potentially bottleneck the whole organization.


An app built from several core functions interacting with each other.

App broken down into its core functions called services, each independent of each other. For example, YouTube app is made up of services: search service, recommended videos service, …

Achieved with adapting technicalities of SOA (service-oriented architecture)

<below to improvise>

What’s the difference? Microservices can communicate with each other, usually statelessly, so apps built in this way can be more fault tolerant, less reliant on a single ESB. This also allows dev teams to choose their own tools, since microservices can communicate through language-agnostic application programming interfaces (APIs).

Given the history of SOA, microservices are not actually all that new of an idea. However, microservices have become more viable thanks to advancements in containerization technologies. With Linux containers, you’re now able to run multiple parts of an app independently, on the same hardware, with much greater control over their individual pieces and life cycles. Along with APIs and DevOps teams, containerized microservices are the foundation for cloud-native applications.



--- :: Skyferia Tech's Related Posts :: ---