Welcome back to another edition of Level Up Coding’s newsletter.

In today’s issue:

• Unraveling the Layers of N-Layer Architecture

• How SQL Injections Work, and How to Protect Your System from Them (Recap)

• What is the Pub/Sub Model? How Does it Work? (Recap)

• How Local Area Networks Work (Recap)

READ TIME: 8 MINUTES

Unraveling the Layers of N-Layer Architecture

Every time you browse social media, purchase something online, or even just log in to your email, you're interacting with the presentation layer of a larger system. Beneath the surface of these platforms, there's an orchestrated system ensuring that user interfaces, data processing, data storage, and many other operations all function harmoniously together.

How to effectively orchestrate these systems is the million-dollar question.

One of the most popular approaches is n-layer architecture. It’s a software design approach where the application is logically segregated into several distinct layers. Each layer has a specific responsibility and interacts with the layers directly above and below it.

Core Layers, Optional Layers, And How They Tie Together

A web application typically involves three layers — the presentation layer, business logic layer, and data access layer.

For more complex applications, you might have additional layers or sub-layers including; a service layer, API layer, infrastructure layer, and/or an authentication and authorization layer.

Let’s dive into the layers and how they work together.

The presentation Layer, or UI Layer, serves as the user's portal, it’s responsible for the user interface and user experience. It sits on top of the business logic layer.

The business logic layer, contains the core business logic, rules, and computations. It handles things like data processing, validation, and business rule enforcement.

Underneath the business logic layer is the data access layer, also known as the persistence layer. It can be seen as a negotiator, ensuring effective communication between the business logic and data storage systems. It’s responsible for storing and retrieving data, as well as, ensuring that the Business Logic Layer remains independent of the storage mechanisms.

We’ve just covered the core three, the following are optional layers that you may find/require depending on the complexity of the system you’re working with or building.

Sitting between the presentation and business logic layers is the service layer. It can be especially useful if your application’s logic is consumed by different clients.

Depending on system complexity, sometimes a dedicated API layer can make things simpler. This layer handles API endpoints, request/response transformation, and routing.

The infrastructure layer is often an essential aspect in more complex applications. This layer deals with operations that support the core functionality of the application but aren't directly related to a specific layer. It handles concerns that cut across multiple layers or components of the application (cross-cutting concerns). Operations such as logging, configuration management, caching, communication, and more.

The Good and The Bad of N-Layer Architecture

The logical division of responsibilities that n-layer architecture is based on provides several benefits, but there is one that it is most praised for — separation of concerns. This principle ensures that changes in one part of the system, such as switching a database system, can be made with minimal impact on other parts (layers) of the system.

The decoupled, modularized nature of this approach to software design leads to several other benefits including;

• Scalability: The decoupled, modularized nature of layers allows layers to be scaled independently.

• Maintainability: Modifications, bug tracking, and updates are a lot easier since changes in one layer have minimal impact on others.

• Reusability: Layers, particularly the business logic layer, can be reused across different projects.

• Flexibility: Decoupling parts of the system makes it easier to replace or upgrade an area of the system.

• Testability: Since there are fewer dependencies between components, testing becomes easier. Each layer can be tested independently.

Although there are strong benefits of n-layer architecture, every silver lining has its cloud.

For less intricate applications, the architecture can introduce unwarranted complexity, potentially complicating what could have been a straightforward design. The complexity of an application with a strict layered approach compared to a monolithic design, especially for smaller projects can also lead to longer development times. Another drawback of the multi-layer structure are potential performance costs associated with translating and passing data between layers. And lastly, new developers might find themselves facing a steep learning curve as they grapple with understanding the nuances and interplay of each distinct layer.

When and Where to Use N-Layer Architecture

The n-layer architecture works effectively in many different scenarios. From SaaS applications to enterprise applications, all the way to IoT systems. Essentially, this software design pattern is most beneficial in scenarios where there’s a need for modularity to manage complexity, different parts of the system have distinct responsibilities, the system needs to be scalable, and/or multiple teams work on the application, benefiting from having clear boundaries making parallel development simpler.

The main benefit of adopting an n-layered structure is the clear delineation of responsibilities. By ensuring each layer concentrates on a unique function, the software becomes more compartmentalized and easier to manage, scale, and adapt. Modifications in one part of the system, like transitioning to a different database, have limited repercussions on the other layers. N-layer architecture typically has three core layers, however, the exact number of layers and their responsibilities can vary based on the specific needs and complexity of the application. The key is to ensure that each layer has a clear and distinct responsibility.

How SQL Injections Work, and How to Protect Your System from Them (Recap)

SQL injection is a type of attack where the attacker runs damaging SQL commands by inserting malicious SQL code into an application input field or URL.

You can protect your system from SQL injections by doing the following:

1) Use prepared statements or parameterized queries
User input cannot be executed because prepared statements and parameterized queries ensure a distinct separation between user input and SQL code.

2) Validate and clean inputs
Use expected formats and constraints to validate user input, and clean inputs to get rid of characters that may be interpreted as SQL code.

3) Follow the least privilege principle
Limit the permissions for database accounts used by applications and services to only what is required for their functionality.

4) Set Web Application Firewalls (WAF)
By setting up WAFs, common threats and attacks from HTTP/S traffic like SQL injections can be identified and blocked before they ever reach your application.

Here is an animated visual representation of how SQL injections work, as well as an example.

What is the Pub/Sub Model? How Does it Work? (Recap)

The Publish/Subscribe Pattern is an approach to messaging that is commonly used in distributed systems.

There are three entities involved — publishers, topics, and subscribers.

Subscribers tell the system which messages they would like to be informed about by subscribing to a topic.

Publishers send messages to topics, without knowledge of who the message should be sent to.

A message broker or event bus then forwards these messages to the appropriate subscribers.

Message senders and receivers are heavily decoupled in a Pub/Sub model. This leads to improved scalability, flexibility, and fault tolerance.

Check out the full post here for an extended explanation including an animated visual of the Pub/Sub Model.

How Local Area Networks Work (Recap)

LANs are private networks that provide secure, high-speed connections to devices within the physical location where the LAN is set up.

How a LAN operates:

1) Hardware
At the center of a LAN is networking hardware such as switches or routers. They’re in charge of managing data traffic. Ethernet cables or Wi-Fi are used to make the connection between the hardware & devices.

2) Networking protocols
In any network, there needs to be a standardized way(s) for devices to communicate with each other. LANs use networking protocols, usually, TCP/IP to achieve this.

3) IP addressing
Every device on the LAN is assigned an IP address, allowing for identification in the network.

4) Data packets
Information sent between devices is done by dividing the information into smaller units called data packets. A data packet contains the sender’s address, the destination address, & the data itself.

5) Packet switching
Each packet is forwarded to the proper location by switches & routers once they have read its destination IP address.

6) Data reception
Once the recipient device receives all the packets, reassembles them to form the original data.

Learn more about the benefits and use cases of LAN as well as an animated visual of its process here.

That wraps up this week’s issue of Level Up Coding’s newsletter!

Join us again next week where we’ll explore Git branching strategies, Linux permissions, and effective debugging strategies.