DEV Community: Onakoya Korede

5 Software Patterns You Should Know As a Software Engineer - Part 1

Onakoya Korede — Mon, 10 Jul 2023 12:22:38 +0000

We are currently in an exciting new era of technology, where software-defined systems have revolutionized the way we live and work. With digitalization enabling us to connect more easily than ever before and cloud hosting making it possible for us to access data from anywhere, we are on the cusp of a new age of innovation.

This era is characterized by context-awareness, which will allow us to tailor our experiences to our individual needs and preferences. Services are now more people-centric, designed to improve the lives of individuals and communities alike. Event-driven technology enables us to automate processes and respond to changes in real-time, while cognitive software provides insights and analysis that shape our decisions and drive innovation.

To meet the identified goals for the future of knowledge, we require highly responsive, reliable, scalable, adaptive, and secure software suites and libraries. We also need a range of innovative and promising architectural, design, deployment, delivery, and integration patterns to simplify the increasingly complex processes involved in designing, debugging, and delivering robust and rewarding software applications.

Using software patterns is very helpful in this case. Their utilization is becoming increasingly widespread and common as their popularity and usage grow over time.

Software architecture patterns provide a way to simplify the complex processes involved in designing, debugging, and delivering software applications. They are a set of well-known solutions to common problems in software design, architecture, and development. By using software patterns, developers can save time and effort while creating software that is easy to scale, maintain, and efficient.

This is the first part of a two-part series. In this issue, we will discuss the client-server architecture, the pipe-filter architecture, and the service-oriented architecture. Understanding these architectures can help us build robust and scalable applications that function well both now and in the future.

Client-Server Architecture

Client-server architecture is a common system design that separates an application into two main parts: the client and the server. The client, which is usually a user interface, sends requests to the server. The server then processes these requests, creates responses, and sends them back to the client.

The client-server pattern is an old way of organizing computer systems. The client (your computer or device) asks the server (another computer) for a service or information. The server then provides the service or information to the client. This happens over and over again as the client keeps making requests.

Messages are sent back and forth between the client and server in a request-response format. In this model, the client initiates contact with the server by submitting a request for the service in question.

The server is usually a database with procedures that have application logic. This makes it possible to perform complex actions on the data. This way, the server can handle many requests at the same time without affecting the effectiveness of other system components. The client-server model is widely used in software development today because it's effective and adaptable.

Web and application servers act as servers by receiving requests from clients, handling them, and sending responses back to the clients. In contrast, peer-to-peer (P2P) application design allows clients and servers to switch roles so that files and information can be shared and kept in sync across multiple clients. However, each participating system can play both client and server roles. Ultimately, they are individuals who work together to ensure business operations run smoothly.

The client-server architectural pattern has the capability of storing all of its data on the server, which, in general, provides a higher level of control over the system's security than client machines do.

Additionally, during the whole of the application's lifespan, centralized data access is provided through the client-server design pattern. Access to the data and modifications to the data are much simpler to handle than they are in other architectural patterns since the data is only kept on the server.

Lastly, there is the convenience of upkeep. The server may be a single computer or a group of computers working together as a cluster. It is possible to configure the server application as well as the database to operate on a single system or to replicate them over numerous servers in order to provide simple scaling and high availability.

A similar thing happens in business-grade server applications. An enterprise app has many parts called subsystems or microservices. Each part runs on its own server machine within the cluster.

Executing server programs and databases using one or more server machines provides protection to clients from interruptions caused by server unavailability, upgrades, or relocations. This means that clients can continue to access and use the system without experiencing any interruptions or delays due to server issues.

The insistence on centralizing data and applications on a single server is a potential drawback that might prevent the system from growing as needed.

In addition to this, the server is a potential lone weak spot in the system. The major problem at hand is one of dependability. The client-server design has developed into the more generic three-tier (n-tier) architecture in order to overcome these challenges.

DNS as a Client-Server Architecture

The Domain Name Server (DNS) is able to function thanks to the client-server approach, which is based on the notion of distributed databases. Clients of the Domain Name System (DNS) are entities that need name resolution, or the mapping of host names to Internet Protocol (IP) addresses. The Domain Name System (DNS) server is responsible for maintaining the data necessary for name resolution.

Take the following as an example: In the web browser of the DNS client (the user's computer), the address (URL) www.example.com is typed in. The browser establishes a connection to a DNS server so that it can obtain the relevant IP address. In order to complete this task, the DNS server will first establish a connection with one of the root DNS servers. The IP addresses of all DNS servers that are responsible for top-level domains, such as .org and .com, will be stored on the root servers. The root servers will also store any other top-level domains that are managed.

To visit a website, your computer needs to know its IP address. The process starts when you type in the website address. The root server then asks the top-level server for the IP address of the website. The top-level server replies with the IP addresses of the name servers for that website. The name server then asks the DNS server associated with the website for its IP address. The DNS server sends the IP address to the name server, which then sends it back to the root server. Finally, your computer gets the IP address and can visit the website.

Pipe-Filter Architecture

Enterprises in the modern era are made up of thousands of different apps. A good number of them are commercial, ready-to-use apps; some of them are applications developed in-house; and some of the others are heritage programs that have been a component of the business for an extremely extended period of time. This is due to the fact that each company performs hundreds of different business operations, many of which are hard to carry out with only a single application.

Spreading different functions over several applications gives a higher level of business continuity. This is because even if one application fails, the others will continue to operate without creating any obstructions to the functions that are necessary for business. Another rationale for numerous apps is that spreading various functions across multiple applications guarantees a better level of business continuity.

All of these factors justify the need for an appropriate integration mechanism across the many apps that are components of a corporate ecosystem. Because of the wide variety of application types, businesses now have a pressing need to develop a comprehensive collection of capabilities for their integration platform. This is necessary for them to continue to be competitive in the present-day dynamics of agile enterprises, which are constantly shifting to meet the requirements and anticipations of their customers.

The message integration technique is a parent of the pipe-filter pattern. In this specific instance, the integration of programs is accomplished through the use of messaging. If one of the apps publishes a message to a message channel based on a set of pre-defined agreements and message formats, then all of the other applications are able to access that message.

The pipe and filter, as a sub-section of messaging, is an architectural pattern for stream processing. It is made up of a single or more filters as its constituent parts. Before sending the data via connections known as pipes, these filters will modify or filter it. These filters, whose only purpose is to consume and output data, can be understood as performing business logical functions such as sorting and counting.

Each of these filters is capable of operating concurrently with the others. Additionally, the operation of a filter is dependent on the contribution of each and every pipe that is linked to it. Data travels from the source (the pump) to the sink after passing through pipelines and filters en route. The pump may either be a static text file or an input from the keyboard. A file, a database, or even just the screen of a computer might serve as the sink.

Pipe and filter designs may have their size readily increased during implementation by having more pipes and filters added to the system. However, if both the data and the architectural size are increased to extremely high levels, the overall performance of the system may become sluggish, and buffer overflow may take place.

Pipe-Filter: Use case

Pipe and filter is an architectural design that is useful for programs that need a predetermined sequence of separate calculations to be carried out on data. Because filters do not exchange states with one another, it is not necessary for them to know the identities of the filters that come before or after them in the processing chain. In other words, filters are capable of operating on their own.

Shell scripts and compilers written for the Unix operating system provide an illustration of the pipe and filter architectural design. It is possible for the output of one program to be connected to the input of another program when working with Unix programs; this is referred to as linking Unix processes via pipes.

A compiler is a program that performs a crucial function in computer science. It is responsible for translating input in one language into output in another language. The input language is usually referred to as language A, while the output language is called language B. The process of transforming language A into language B is called language transformation.

To perform language transformation, the input goes through various stages inside the compiler, which is called a pipeline. The pipeline is made up of different stages, each of which has a specific function and purpose. The most commonly used pipeline division consists of three stages: front-end, middle-end, and back-end.

The front-end is responsible for parsing the input language and performing syntax and semantic analysis on it. The front-end is also responsible for generating an intermediate representation of the input language. This intermediate representation is usually in the form of a data structure that is easier for the compiler to work with.

The middle end is where most of the optimization steps take place. The middle-end performs several optimization steps on the intermediate representation that the front-end generates. The optimization steps are aimed at improving the performance of the output program and reducing the number of instructions needed to execute it.

The back-end is responsible for transforming the optimized intermediate representation into the output language, which is language B. The back-end is also responsible for generating the machine code that can be executed on the target platform.

Overall, a compiler is an essential tool for software development. It converts high-level code into computer-executable low-level machine code. Without compilers, software development would be much more difficult and time-consuming.

Systems that make use of pipe and filter patterns are very simple to maintain and improve with regard to the expansion of already existing architectures. Since the filters are isolated from one another and only communicate with one another through explicit connections, it is possible to include more filters in already operational systems.

Pipes and filters have some significant drawbacks.

A filter may have an indefinite number of input and output pipes. If any of these pipes only permit one data type to pass through, the filter will need to perform some sort of internal parsing, such as transforming particular data types so that they can fit within the pipe's one allowed data type. This behavior may cause the filters to move more slowly.

Pipes and filters are also a lot like black boxes. We don't know how they're put into place. For example, we give an input to a pipe, and the pipe sends this input to the filter. When the filter is done with the input, it makes an output, but we don't know what it did inside.

When an error is transferred from a pipe to a filter, there is a higher likelihood that it will also be transmitted unfettered to the next filter since this behavior is the default setting.

Service-Oriented Architecture (SOA)

If you’ve ever been on different websites, you may have seen dashboards that show different important information. These dashboards have everything you need to get things done or reach your goals. You might wonder how a sales report and stock market quotes can be shown together. Service-oriented architecture makes this possible.

SOA is a proven and highly favorable architectural design style that helps modern software systems efficiently handle ever-changing user expectations by solving key problems.

SOA plays a significant role in the background of real-world applications, providing virtualization, event processing, business process management, and much more.

We can create a software system that combines different data sources and systems in a cost-effective way.

What are Web Services and SOA?

The initial step in designing any web service is to strictly adhere to the characteristics and principles of Service-Oriented Architecture (SOA). The fundamental building blocks and stepping stones for any web service design are the SOA architecture patterns.

A web service is a type of software architecture that enables different applications, often developed by different organizations, to communicate with each other. This communication is made easier by bespoke software code, which, in addition to being reusable, is also intended to be as cost-effective as possible. Essentially, a web service acts as an intermediary between disparate systems, enabling them to integrate with one another in a seamless and efficient manner. This allows businesses to streamline their operations, reduce costs, and improve their overall efficiency.

A service should be able to work by itself. In SOA, this is called being autonomous. A product's service should not depend on other services. Another SOA principle, composability, suggests combining services to add business value. You can place an order by combining customer service and product service.

In essence, SOA is a set of services that communicate with each other. A service is an operation or function that is well-defined, self-contained, and independent of other service contexts and states.

A service is made available to use without being tied to any specific technology. One of the biggest advantages of services is that they hide the technology being used underneath. One team can create their services with Golang, while another uses Python or NodeJS. The way the backend is developed doesn't affect whether one team can use the other's service. Being able to share services is possible because SOA encourages the idea of a standard service agreement. In the beginning, SOAP and WSDL were the standard contracts for SOA.

Life Cycle of SOA

The development of software for SOA goes through four cycles, which are as follows:

Discover and define: Any service that has a clear set of communication standards, such as WSDL, SOAP, REST, and so on, can be found and used.

Model and Availability: The next important thing is service design. We need to find a good pattern and offer services that are model-driven, specific to business functions, can be tested on their own, and so on.

Deploy and Manage: After the phase of functional design, it is essential for any company or organization to have services that are produced, deployed, and consumed in order to go on to the next step, which is the deployment and management phase. On the other hand, in contrast to the waterfall technique, it is preferable for the development of the service to occur in an iterative and agile manner so that customers may satisfy ROI in the near term.

Governance and Feedback: these two components are essential for any developing service, as they both play an important part in the adoption of the service and assist businesses in achieving a return on investment (ROI) as quickly as possible.

Principles of SOA

There are some tenets that can be defined as core principles of SOA that help to realize all the characteristics of SOA mentioned above.

Standardized Service Contract

Standardization is important in SOA. It requires services to have clear and defined functions and capabilities in a service contract. This helps SOA designers focus on things like service granularity, data types, service optimization, service versions, service endpoints, and more.

Service level agreements (SLA) are agreements that clearly define how services are consumed, governed, secured, versioned, and responded to. By standardizing service contracts, these agreements provide direction and pave the way for easier service consumption.

When it comes to standardization efforts for sending data between applications, two prominent options emerge from the crowd: DCE/RPC and CORBA. These two approaches have proven to be reliable ways to allow applications, regardless of the programming language used or the operating system they run on, to communicate with one another.

Simply put, DCE, RPC, and CORBA assist in addressing a frequent problem in software development by enabling various programs to communicate data and functionality without being restricted by language or operating system boundaries. This is a problem that affects almost all software development projects. By offering a set of standardized protocols and interfaces, these technologies allow developers to create efficient and interoperable systems that can be easily maintained and expanded over time.

Service Interoperability

One key principle of Service-Oriented Architecture (SOA) is interoperability, which is the ability of services to share information and communicate efficiently across different software platforms. This principle applies at various levels, including operational (i.e., business process), informational, and technical architecture stages.

At each level, interoperability ensures that systems can communicate with each other effectively, allowing for the efficient exchange of information between different services. By adhering to this principle, developers can create software that is scalable, maintainable, and efficient, making it easier to design, debug, and deliver robust and rewarding software applications.

Service Abstraction

Making services simpler to understand by hiding internal complexities can improve the way they are explained and operated, help consumers focus on their core logic, and prevent accidental changes to internal processes.

Abstractions can be used at different levels, such as language implementation or server management. For instance, the sales report only focuses on generating a sales report and does not cover how it relates to the customer's platform, how it connects to the sales database server, or how new sales details are added to the system.

What they all need to know as customers of a service is whether the service can show the reports effectively and correctly.

Service Statelessness

Services should try to avoid maintaining states. Statelessness is a vital principle that can help services use fewer resources, be tested independently, and increase reusability.

To implement statelessness in the email service, it is necessary to ensure that all the necessary information required for sending emails is explicitly provided. This means that the email service should not rely on any additional information from a database or any other resources. The primary focus of the email service should be on the business logic of setting up schedules to send emails.

The schema of the email service can have more details, such as message, email IDs, and subject, explicitly provided, rather than just a booking ID. Making this information explicit can help the email service pick up all the necessary information required to send emails without having to rely on other resources and, in turn, help it function more effectively.

Is SOA still relevant?

The principles of SOA are still important today, even though they were created a while ago. This is because it can share services that work with any technology. However, it was hard for developers to use because it needed a lot of skilled developers to create the basic parts of an application.

One of the challenges of SOA is its high dependence on skilled developers. This is especially true when it comes to ensuring security, as application-managed security is not suitable for SOA. Separate technologies and standards must be followed for this purpose. Additionally, as the specifications for SOA and Web Services are constantly changing, there is a shortage of manpower for the integration and construction of service infrastructure, making it more challenging for businesses.

Roy Fielding, however, introduced REST web services in 2000. REST allows for lightweight and resource-centric web service calls, which completely changed how businesses approached application development. This further diverted attention from service-oriented architecture.

This is the end of the first part of this series. Look for the second part of this series next week. We will discuss event-driven and microservice architectures. Be sure to subscribe here to be one of the first people to receive this in your email.

You can also reach me on LinkedIn or Twitter.

Happy Learning!

Back To Basics: Tiers in Software Architecture

Onakoya Korede — Tue, 27 Jun 2023 11:08:44 +0000

The architecture upon which a business constructs its application has a substantial impact on its success or failure in software engineering. This seems obvious until you have to be the person making the choice for a million-dollar project from the beginning.

In this issue, we'll go back to the fundamentals to explain what software architecture is, what software architecture tiers are, how many there are, and when we utilize each of them.

A software architecture is a system that represents the collection of components that perform a certain function or set of operations. An architecture's foundation may have one or more components upon which software can be developed. A software architecture assists in defining and representing the component(s) and their connections.

We can understand software architecture with an example. Consider that in order to build a duplex on undeveloped property, we will need an architect to design a home plan. He collects various forms of information from us and creates a floor plan on paper. If all of the prerequisites are completed, the civil engineer can begin building. Similarly, a software architect creates a plan based on the requirements. He creates a high-level framework that fits all of the software's technical and operational needs. The developer team creates software in accordance with the software architecture and delivers it to the client.

There are three fundamental layers that are important steps to having a grasp of software architecture tiers. They are the presentation layer, the application layer, and the data layer.

The Presentation Layer, also known as the User Interface, passes the information that is given by the user in terms of keyboard actions and mouse clicks to the Application Layer. The main function of this layer is basically to communicate with the next layer below—the Application Layer. For example, on the login page of an application, where the user may interact with the inputs and buttons, enter their credentials such as user ID, email, and password, and then click the sign-in button, The Presentation Layer manages and categorizes the whole process.

The Application Layer, often known as the business Layer, comprises all of the models and logic that allow the application to run. It also serves as a bridge between the user interface and the database layer. Consider the sign-in instance from previously. When a user hits the sign-in button, the Application Layer communicates with the Data Layer and transmits the necessary information to the Presentation Layer.

The Data Layer interfaces with the application's database to retrieve data and deliver it back to the Application Layer. It's where the application's data is kept. It includes methods for connecting the database to the application and performing database operations like insert, UPDATE, DELETE, and so on. It saves all data passed to it after the Application Layer has manipulated it.

Tiers Architecture

One-Tier Architecture

A single-tier application is one in which the backend logic, database, and user interface are all located on the same server. It entails hosting all of the essential components of a software application or technology on a single server or platform, such as the interface, middleware, and back-end data. Some also refer to it as any program that can be installed and executed on a single computer.

There are no network latency concerns because the application components all reside on the same single server. The data is readily available, and there is no need to request it from a database server. Furthermore, unlike a three-tier or multi-tier architecture, the attraction of a single architecture might be related to the expenses involved, where it may make more sense to have simpler applications confined to one basic platform.

However, unlike more advanced systems, it cannot transmit information from one client machine to another.

Two-Tier Architecture

The client is on the first tier of a two-tier architecture, while the database server is on the same server machine, which is on the second layer. This second layer provides the data and conducts the web application's business logic.

The user system interface is often hosted in the user's desktop environment in two-tier client/server systems, while the database management services are typically located on a server that is a more powerful computer that handles numerous clients.

To put things into perspective, in a two-tier design, the display layer and application layer run on a client, while the data layer is stored on a server. Organizations that use this design often desire to integrate their application and database server capabilities on a single layer. Languages such as C, C++, Java, Python, PHP, Rails, and others can be used to build the Client-Application layer.

Data storage (a database or file system) and techniques for storing and retrieving data from storage comprise the data management layer. Databases that are often used include MySQL, MongoDB, PostgreSQL, and SQLITE. Desktop programs, games, and music players are examples of two-tiered apps.

The advantages of using two-tier apps include their speed and ease of implementation, as well as faster communication between the client and server. It's also best suited for environments with unchanging business rules or logic.

One of its drawbacks is that it is not easily scalable, so performance diminishes as the number of users increases. Furthermore, a data integrity issue might easily emerge as a result of the server responding to several requests at the same time.

Three-Tier Architecture

The three-tier architecture is a well-established software application architecture that organizes applications into three logical and physical computing tiers: the presentation, or user interface; the application layer, where data is processed; and the data layer, where the data associated with the application is stored and managed.

The three-tier architecture offers a major advantage in that each tier can be developed and deployed independently on its own infrastructure. This means that separate teams can update or scale each tier as necessary without affecting the other tiers. Additionally, each tier can run on a dedicated operating system and server platform, whether it be a web server, an application server, or a database server, to best meet its functional needs.

And each tier runs on at least one dedicated server, whether hardware or virtual, so the services of each tier can be customized and optimized without impacting the other tiers.

Another benefit is faster development. By allowing different teams to develop each tier of the application simultaneously, an organization can bring it to market more quickly. Additionally, programmers can use the latest and best languages and tools for each tier, improving overall development efficiency.

Other benefits include improved reliability of the services. An outage in one tier is less likely to impact the availability or performance of the other tiers. Security is also important because the presentation tier and data tier can’t communicate directly; a well-designed application would function as a sort of internal firewall against its services, preventing SQL injections and other malicious exploits.

How Does The Three-Tier Relate To Web Development?

The web server is the presentation tier and provides the user interface. This is usually a web page or website, such as an e-commerce application, where the user adds products to the shopping cart, adds payment details, or creates an account. The content of this presentation tier could either be static or dynamic and is usually developed using HTML, CSS, and JavaScript.

Next, we move to the application server, which corresponds to the middle tier of the three-tier. It houses the business logic used to process user inputs. To continue the e-commerce example, this is the tier that queries the inventory database to return product availability or adds details to a customer’s profile. This layer is often developed using Python, Ruby, or PHP and also runs on frameworks like Django, Rails, Laravel, or ASP.NET.

The database server is the data or backend tier of a web application. It runs on database management software such as MySQL, Oracle, and PostgreSQL.

N-Tier Architecture

An N-tier application is one that is distributed over three or more machines in a distributed network. The n-tier is a three-tier composition comprising display, application, and database that may be further broken into multiple sub-layers depending on the requirements.

Furthermore, N-tier architecture is a popular choice for developing enterprise-level applications that can handle large volumes of data and traffic. By breaking down the application into smaller, independent components, it becomes easier to manage and scale the system as needed.

This architecture paradigm enables software developers to construct reusable programs that are as flexible as possible. The n-tier architecture is used in applications such as the Salesforce enterprise application, Amazon, Facebook, and Twitter.

N-tier architectures are also typically implemented as Infrastructure-as-a-service (IaaS) applications, with each tier running on a separate set of VMs.

N-tier is especially beneficial because it has a reduced learning curve for most developers. That is, developers may be assigned to certain microservices without having to learn about the entire application architecture.

On the other hand, it's common to end up with a middle tier that only performs basic CRUD operations on the database. While this may seem efficient at first glance, it can actually add extra latency without doing any significant work.

One solution to this problem is to introduce a caching layer between the application and the database. By caching frequently accessed data, the middle tier can quickly retrieve and serve this data to the user without needing to query the database each time.

Another option is to implement more advanced logic in the middle tier, such as data processing or analysis, which can provide additional value to the end user. By expanding the functionality of the middle tier, developers can ensure that it is doing meaningful work and contributing to the overall performance of the system.

N-tier architecture, also known as multi-tier architecture, separates application processing, data management, and presentation functions both physically and logically. This means that these functions are hosted on several machines or clusters, ensuring that services are provided without shared resources and are delivered at peak capacity.

Key Considerations For Using N-Tier Architecture

For n-tier architecture, it is imperative to have fast and responsive network bandwidth and hardware. Careful consideration of this factor is necessary to ensure that services are decoupled and communication between services does not suffer from noticeable lag. Failing to provide sufficient network bandwidth can significantly impact the performance of the architecture.

Furthermore, it is advisable to use as few tiers as possible in your software application. This is because adding more tiers can increase complexity, require additional server purchases, and result in higher maintenance and deployment expenses.

Finally, it is important to note that there is a minimum number of tiers required to ensure that your application is scalable, secure, and able to take full advantage of the benefits that this architecture provides.

In order to achieve the necessary scalability, for example, it may be necessary to add additional tiers to the architecture, such as an application server or a load balancer (read our last issue on load balancers here). Similarly, in order to ensure the security of each service, additional security measures may need to be implemented at each tier.

Finally, it is worth noting that using this architecture has many other benefits, such as improved performance, greater flexibility, and increased reliability. You can fully realize these benefits by carefully selecting the appropriate number and type of tiers for your application.

In the upcoming issue, we will provide an expansive overview of different types of software architectures. We will delve into Client-server architecture, which is used to separate clients and servers from each other and support efficient communication between them. We will also discuss peer-to-peer architecture, which is used to allow each node to act as both a client and a server. Additionally, we will cover event-driven architecture, which is used to respond to user events in real-time. Finally, we will explore micro-service architecture, which is used to develop software by breaking it down into modular components that can be independently developed and tested. By the end of the issue, you will have a comprehensive understanding of different software architectures and their applications.

I hope you found this week's issue useful! Our team puts a lot of effort into creating valuable content for our readers, and we're always looking for ways to improve.

If you enjoyed this issue, I invite you to subscribe to our newsletter here. We share this kind of content every week, covering a variety of topics related to software engineering, system design, and development. And if you know anyone who might find our newsletter helpful, feel free to invite them to subscribe too!

We appreciate your support and look forward to sharing more insights and knowledge with you in future issues.

Cheers.

Happy learning!

Load Balancers: Do We Actually Need Them?

Onakoya Korede — Sun, 18 Jun 2023 19:56:49 +0000

What is a load balancer? What problems does it actually solve?

Performance, availability, and economy are three significant issues that load balancers were primarily designed to address.

Performance is constrained by how much work a server can physically accomplish in a certain length of time. But, given the enormous amounts of user data that can be handled, consumers' desire for sophisticated software continues to grow exponentially beyond the capability of this technology. This can quickly lead to the failure of the server.

The server's probable failure due to a heavy load of requests leads to the availability issue. When you build your application on a single server with the possibility of exceeding its capacity, it leads to a single point of failure. Having your server duplicated is one way to address this problem. Making copies of your server would ensure that, in the event of a server failure, your complete application wouldn't fall offline. Customers should only notice a minimal amount.

This is the solution. Running a large number of servers and being able to re-route traffic away from the server in real-time.

This leaves us only two options for scaling: vertically or horizontally.

We can opt for vertical scaling, that is, by acquiring and upgrading server capacity as needed to meet the growing demand of our consumers. This may be a viable choice in some cases, but it is not a cost-effective option for the vast majority of application workloads.

And this leads to the third problem: how can we as a business build a high-performance, reliable product with little to no downtime while still optimizing our return on investment? Load balancers are the unambiguous solution.

A load balancer is a networking software device that aids in the distribution of incoming network traffic among various servers or resources. It guarantees that no one server or resource is overburdened with requests at any given moment.

A load balancer works as an intermediary between client devices and a collection of servers. This is accomplished by evenly spreading incoming network traffic among the servers.

Load Balancer: How It Works

The load balancer displays to the client a virtual IP address (VIP)—a virtual IP address that does not correspond to a real network interface — that represents an application server.

When a client connects to the VIP, the load balancer decides whether or not to route the connection to a certain application on the server using its algorithms and parameters.

Many criteria, including authentication, validation, and authorization, might prevent the load balancer from sending requests between the two parties if specified as some of its parameters. But regardless, the load balancer would continue to maintain and monitor the connection between both parties throughout the length of the connection.

Take the professional football business model as an analogy: imagine a sports agent like Roberto Calenda (the current agent for Victor Osimhen) negotiating a new contract for his star athlete, Victor Osimhen.

Calenda (the load balancer) takes a request from Osimhen (the client), who wants to leave Napoli, and sends it to different football teams that have their interest, like Manchester United (the server).

Manchester United responds with an offer, which Calenda then passes back to Osimhen, and this goes back and forth until they both come to a suitable offer.

In the process of back-and-forth communication between the server and the client, Calenda can also provide additional functionalities. He can decide to allow or deny some details (security) from one party to the other. He can validate whether the representative of Manchester is authentic or just a scam (authentication).

Load Balancer: Use Case

Content-based Routing

Content-based routing is the execution of established rules that govern the allocation and configuration of network traffic between users and web applications depending on the content being sent.

If your application is made up of many services, a load balancer can route a request to one of them based on the request's information, such as the host field, path URL, HTTP header, HTTP method, query string, or source IP address. Let’s talk briefly about some of them:

Host-based routing: You can route a client request based on the host field of the HTTP header, allowing you to route to multiple domains from the same load balancer.
Path-based routing: You can route a client request based on the URL path of the HTTP header.
HTTP header-based routing: You can route a client request based on the value of any standard or custom HTTP header.
HTTP method-based routing: You can route a client request based on any standard or custom HTTP method.
Query string parameter-based routing: You can route a client request based on a query string or query parameters.
Source IP address-based routing: You can direct traffic to a specific destination based on the source IP address or a combination of the source and destination IP addresses.

User Authentication

You can offload the application authentication functionality to a load balancer. It will securely authenticate users as they access your cloud applications. For example, you can use an AWS application load balancer to seamlessly build your application's authentication.

This is possible through the Amazon Cognito service, which allows end users to authenticate with social identity providers — Google, Facebook, and Amazon — and also with enterprise identity providers — Microsoft Active Directory via SAML or any OpenID Connect-compliant Identity Provider (idP).

Allowing the load balancer to handle some salient components of your application makes it easier to focus on features that will improve the core value of your application.

TLS/SSL Offloading

You can offload the extra burden that SSL/TLS — handshake and encryption/decryption — adds to your application by delegating the task to your load balancer. This way, it offloads additional tasks from your application servers so they can focus on their primary functions. And, depending on the load balancer, it should also aid with HTTPS inspection, reverse-proxying, cookie persistence, traffic control, and so on.

When you consider the fact that attackers might hide in your encrypted communication and enter your application, being able to analyze HTTPS traffic becomes virtually mandatory.

So, TLS/SSL offloading extends beyond encryption and decryption; some of the extra features listed above also play a significant role in determining the security of your application.

Load Balancer: Algorithms

Web applications are diverse, and the optimal method for load-balancing connections to them will depend on the infrastructure in place and the organization’s requirements.

Here are five algorithms used to load balance connections to application servers:

Round Robin

Round-robin is the simplest basic load-balancing algorithm. Client requests are routed to application servers in a simple cycle. If you have three application servers, the first client request goes to the first application server in the list, the second client request goes to the second application server, the third client request goes to the third application server, and so on.

It is best suited for predictable client requests that are distributed throughout a server pool with approximately equal processing capabilities and available resources (such as network bandwidth and storage).

Least Connections

Least connections load balancing is a dynamic load balancing mechanism that distributes client requests to the application server with the fewest active connections at the time the client request is received.

The algorithm places a special emphasis on dynamic connection loads. Simply because application servers have comparable specs and one server may get overwhelmed as a result of longer-lived connections.

When incoming requests have different connection delays and a group of servers with approximately equivalent processing power and resources is available, the least-connection load-balancing algorithm can be used. If clients can maintain connections for a lengthy period, a single server may wind up having all of its capacity used by many connections comparable to this.

Source IP Hash

The source IP hash load balancing technique generates a unique hash key from the client's source and destination IP addresses to attach the client to a specific server.

Because the key can be regenerated if the session disconnects, reconnection requests are sent to the same server as before. This is referred to as server affinity.

This load-balancing strategy is best suited when a client must always connect to the same server on each subsequent connection, such as in a shopping cart situation, where products placed in a cart on one server should be available when a user joins later.

URL Hash

This load balancing mechanism is similar to source IP hashing, except that the hash formed is dependent on the client request's URL. This guarantees that all client queries to the same URL are sent to the same back-end server.

A common use case would be to route traffic to an optimized media server capable of playing video or an optimized server for a certain purpose.

DNS

This method is widely used for simple load balancing as well as traffic distribution over numerous data centers, perhaps in various geographic locations. Instead of having separate hardware for detecting which server is in charge of traffic management, the DNS load balancer can distribute traffic across a group of server machines.

The name server keeps a list of IP addresses for the different servers to which requests can be directed. In essence, whenever someone requests the name server for a certain domain, the name server delivers this list of IP addresses and changes the order of the addresses.

Load Balancer: Types

In this part, we will take a brief look at how each load balancer type has evolved and what difficulties it seeks to solve.

Network Server Load Balancers

Load balancers hit the market in the mid-1990s, with the basic capability of managing connections based on packet headers such as source IP, destination IP, source port, destination port, and IP protocol.

This is the network server load balancer's entry point, also known as the Layer 4 load balancer. It operates similarly to a firewall, routing connections between servers and clients based on simple IP address and port information, as well as health checks.

It is a flow control that intelligently decides data transmission speed and sending goal amounts, ensuring that senders with faster connections do not overpower receivers with slower connections.

The most significant aspect of Layer 4 load balancing is that the application servers handle all of the work and build a direct relationship with the clients that is quick, transparent, and simple to comprehend.

Application Load Balancers

At this point, we have a Layer 7 load balancer that runs at the highest point possible and offers more context on application layer protocols like HTTP.

The Layer 7 load balancer, which operates at the application layer, could now use some of the new features to make more complex and informed decisions based on the payload's content and to apply optimizations and changes to the content (such as HTTP header manipulation, compression, and encryption) while monitoring the health of applications.

A layer 7 load balancer is sometimes known as a reverse proxy since it may maintain two TCP connections (one with the server and one with the client).

Global Server Load Balancer (GSLB)

GSLB is a dynamic DNS solution that appears and monitors many sites via configuration and health checks.

It allows multi-data center resiliency by utilizing service resource awareness and DNS to direct traffic across geographically distributed pools based on previously specified business logic.

Client traffic is routed to the location with the greatest application performance and client experience, based on the client's location and the observed availability of each site.

Hardware vs Software vs Virtual Load Balancing

Load balancers began as hardware solutions. They were efficient at the time because they supplied a basic appliance that combines functionality with a focus on performance.

While hardware-based load balancers are intended for installation within data centers, software-based load balancing solutions provide flexibility and the ability to interface with virtualization orchestration systems. DevOps and CI/CD techniques are commonly used in software-based workplaces. These are also some of the aspects that contribute to its ease of integration.

Elastic Load Balancer

Elastic load balancer (ELB) systems are significantly more complex, providing cloud computing operators with a scalable capacity based on traffic demands at any given time. It automatically adjusts traffic to an application as demand fluctuates over time.

It can achieve this by employing request routing algorithms to disperse incoming application traffic over several instances or grow them as needed, boosting the fault tolerance of your applications.

Hopefully, you found the article useful! Let's connect on Twitter and LinkedI

Three APIs to understand in 2023 as a Software Developer

Onakoya Korede — Tue, 14 Mar 2023 11:32:40 +0000

Introduction

The REST API principles were a perfect starting point for my foray into programming. Simply put, it appears to be the only option available. The basic answer is that every lesson I followed to learn either the backend or frontend implemented the REST API. It took me some time to begin to realize how many different options there were, and unexpectedly, the great majority of well-known businesses were already utilizing them.

As a backend engineer, it's crucial to have excellent knowledge of web API design. There are a lot of fine details that go into a successful web API. Once you design and build your web API, be it internal or external, it is extremely tedious to make significant changes to it over time. This is why, as a backend engineer, you have to have a really deep understanding of how to design and build a resilient, scalable web API.

In this article, I will be explaining three prominent Request-Response API paradigms that will help you become a solid backend engineer. Fundamentally, APIs can be broken down into request-response APIs or event-driven APIs.

When it comes to request-response APIs, there are three major standards: representational state transfer (REST), remote procedure call (RPC), and GraphQL. Each of these paradigms has its strengths and weaknesses. There is no good or bad among them; it all depends on the use case.

I will be covering each of these paradigms briefly, just enough to make you comfortable using them. I will make references to resources, should you want to go deeper than the scope of this article.

REST API

REST is a set of architectural constraints that stands for "representational state transfer," as described by Roy Fielding in his dissertation. REST is all about a client-server relationship, where server-side data is made available through simple representations of data in simple formats, such as JSON and XML. These representations for resources, or collections of resources, are then potentially modifiable with actions, and relationships are made discoverable via a method known as hypermedia, the concept of providing links to other resources.

Think of REST APIs as basically all about resources. Typically, you would name your resources using nouns. An example of a resource could be "products", with the URL "https://foobar.com/api/v1/products". It is considered incorrect to use verbs like "getProducts" to name your resource in REST APIs. Each resource would typically have two endpoints, one for the collection of resources, like products in this case, and the other for an entity in that collection by specifying the identifier of that entity so consumers would be allowed to use these resources through CRUD operations.

CRUD refers to the four basic operations a software application should be able to perform: create, read, update, and delete. These operations are perfectly suited for REST APIs, as they match the HTTP verbs: POST, PUT, PATCH, GET, and DELETE.

For an API to be considered a REST API, it has to conform to certain criteria:

A client-server architecture made up of clients, servers, and resources, with requests managed through HTTP.
Stateless client-server communication, meaning no client information is stored between get requests and each request is separated and unconnected.
Cacheable data that streamlines client-server interactions.
A uniform interface between components so that information is transferred in a standard form.
A layered system that organizes each type of server (those responsible for security, load balancing, etc.) involved the retrieval of requested information into hierarchies, invisible to the client.

Remote Procedure Call - RPC

If the REST API is all about resources, the RPC API is all about actions.

Remote Procedure Call is a methodology used for constructing distributed, client-server-based applications. It is also called a "sub-routine call" or a "function call." Because it is based on traditional local procedure calling, the called process does not necessarily need to be present in the same address space as the calling procedure. RPC works incredibly effectively for client-server interactions when control is sent back and forth. The thread of execution moves from the client to the server rather than running the client and the server simultaneously.

RPC is the earliest and most basic type of API communication. It works similarly to how JavaScript calls a function when given a method name and parameters. The distinction is that it becomes a Web API when used with HTTP or any messaging protocol, such as AMQP.

An API should ideally be created by opening up a set of public methods, which are then made available to the intended consumers via arguments. RPC is only a collection of functions, but they are used in the context of an HTTP API, where the method is contained in the URI and the arguments are contained in the query string or content.

An example of an endpoint would look like this:

https://example.com/api/chat.postMessage - POST Request

https://example.com/api/chat.scheduleMessage - GET Request

https://example.com/api/chat.deleteScheduleMessage - GET Request

The RPC API usually supports GET for read-only requests and POST for other operations.

RPC simply involves sending data fields back and forth when used for CRUD operations, but with a twist—the client is in command of everything. To build its workflow out of otherwise naïve and nondescriptive endpoints, the client must know which methods (endpoints) to call and when.

A modern RPC implementation is gRPC, which can easily be considered a drastically better SOAP. It uses a data format called ProtoBuf—Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data—which requires a schema as well as the data instance, much like the WSDL in SOAP.

I will be writing a detailed article on the gRPC API in the future. So watch out 😉

GraphQL

GraphQL is an RPC with a default process that offers a query language, a little like SQL—if that is something you are familiar with. You can request certain resources and fields, and the system will respond with the requested information.

GraphQL is a query language for APIs that was internally developed by Facebook but has now been widely adopted by leading API providers, including GitHub, Yelp, and Pinterest. You offer a single endpoint as an entry point, which is how it operates. The client specifies the desired data structure, and the server fulfills the request exactly. The GraphQL API only allows POST and GET operations, just like RPC.

An example request may look like this:

{
    Products {
        name,
        price
    }
}

This describes the structure needed to include the name and price fields for a group of products. The server simply provides the name and price fields for each product in the collection that was requested, not anything else.

{
    [
        {"name": "Apple airpods", "price": "5000"},
        {"name": "Samsung chargers", "price": "500"},
        {"name": "Xiaomi Redmi Note 9", "price": "15000"},
    ]
}

The primary selling point of GraphQL is that it reduces the amount of content that has to be downloaded during an HTTP request by default to provide the lowest possible answer from an API.

Summary

One thing is certain, these APIs all have different strengths and weaknesses. They are not to be put side-by-side to determine which is better or weaker. A REST API may boast high flexibility for hardware architecture, and RPC would argue because they are tied to actions directly, payloads tend to be associated with the action itself and therefore tends to be lightweight. GraphQL on the other hand would boast of its ability to retrieve many resources in a single request.

Decisions on the appropriate API paradigm to use for your project should be based on the fundamental architecture needed for the project.

One simple guideline I use is:

If an API is mostly actions, I should probably be using RPC.
If an API is mostly CRUD and is having to handle relationships between resources, maybe I should use REST.
When the project or API is becoming too complex, and too much data is being revealed to unrelated resources, then maybe it's time to convert the project to GraphQL.

I hope you found this article beneficial and that it helps give you more context for understanding some of the API paradigms we have in the modern market.

Let's connect. Follow me on Twitter and LinkedIn.