Middleware exists at different levels — from low-level, system middleware (like network drivers and OS services) to the application-level middleware we’ll focus on here. Application-level middleware operates within a web framework to handle specific tasks as each HTTP request flows through the app.

You may wonder, What makes middleware so important? Middleware streamlines handling cross-cutting concerns, such as authentication, logging, and error management, without cluttering route logic. In this article, we’ll dive into how application-level middleware works across frameworks like Node.js Express, .NET, and Go Fiber. We’ll see how each framework handles middleware, the role of the next function in controlling request flow, and how middleware shapes the user experience in your web app.

What is Middleware, Anyway?

At its core, middleware is a function or series of functions that handle requests and responses in a web application. But middleware isn’t just about dealing with requests — it’s about shaping how those requests are processed. It can modify the request before it reaches your main handler or alter the response before it’s sent back to the client.

In simpler terms, middleware acts as the in-between layer that lets you process, inspect, or reject HTTP requests at various stages. It allows you to:

• Authentication/Authorization: Verifies that the user is allowed to access the resource.
• Logging: Tracks request details like IP, request time, and user actions for monitoring and debugging.
• Error Handling: Catches errors at a central point, ensuring consistent responses across routes.
• Compression: Compresses responses to reduce the amount of data transferred, improving load times.
• Rate Limiting: Limits the number of requests from a single user to prevent overuse or abuse.
• Caching: Stores the responses temporarily, so frequently requested data can be served faster.
• Request Validation: Checks that incoming requests meet specific requirements, like valid data formats or required fields.

Think of middleware like the security checkpoint at an airport. Each request (or passenger) goes through multiple layers of checks — authentication, validation, logging — before reaching the final gate (the route handler).

Order Matters: The Importance of Middleware Sequence

One critical aspect of middleware is that order matters. The sequence in which middleware is defined affects how requests are processed. Middleware functions are executed in the order they are registered, meaning that a misordered middleware can disrupt the application’s flow or even break functionality.

For example, imagine you have a user based rate limiting:

app.use(logRequest);       // Logs the request details
app.use(authenticateUser);  // Authenticates the user
app.use(rateLimit);         // Limits request rate per user

In this order, each request is logged first, then checked for authentication, and finally rate-limited before reaching the handler. However, if we mistakenly swap authentication and rate limiting:

app.use(logRequest);       // Logs the request details
app.use(rateLimit);         // Limits request rate per user
app.use(authenticateUser);  // Authenticates the user

If we use a credential like userId it won’t work as expected since the user information that we need is not registered yet. If we use the input, the middleware will act on all requests, even unauthenticated ones, potentially blocking access before a user’s credentials are checked. This could lead to user frustration and wasted resources if unauthenticated requests are rate-limited.

Ensuring the correct sequence for each middleware layer is key to building a smooth, secure, and reliable pipeline.

The “Next” Function

One of the most critical parts of understanding middleware is the concept of the `next` function. If you’ve worked with middleware before, you’ve probably seen this:

app.use((req, res, next) => {
    console.log("Middleware 1");
    next(); // Pass control to the next middleware
});

But what does `next()` do?

When a request enters a web server, it doesn’t just go straight to the route handler. Instead, it moves through a series of middleware functions. When you call next(), you’re saying, “Okay, this middleware has done its job – move the request to the next function in line.”

In short, middleware intervenes in the request-response pipeline, and the next() function ensures the flow continues.

Middleware in Action

Now, let’s explore how middleware works in three popular web frameworks: Node.js Express, ASP.NET, and Go Fiber. Each of these frameworks uses middleware, but their implementation looks a little different.

Middleware in Express

In express, middleware is everywhere. Here’s a basic example:

const express = require('express');
const compression = require('compression')
const app = express();

// Standart Middleware that compress every response 
app.use(compression())

// Custom Middleware that logs every request
app.use((req, res, next) => {
    const start = Date.now();
    next(); // Call the next middleware or route handler
    const duration = Date.now() - start;
    console.log(`Request to ${req.path} took ${duration}ms`);
});

// Route handler
app.get('/home', (req, res) => {
    res.send('Welcome to Home Page');
});

app.listen(3000);

Middleware in .NET

In .NET, middleware is used in a similar fashion, although the syntax and setup differ slightly. Here’s an example of how it works in an ASP.NET Core application:

using Microsoft.AspNetCore.Builder;

var builder = WebApplication.CreateBuilder(args);

// Enable response compression with default settings
builder.Services.AddResponseCompression();

var app = builder.Build();

// Standard Middleware that compresses every response
app.UseResponseCompression();

// Custom Middleware that logs every request
app.Use(async (context, next) =>
{
    var start = DateTime.Now;
    await next(); // Pass control to the next middleware or route handler
    var duration = DateTime.Now - start;
    Console.WriteLine($"Request to {context.Request.Path} took {duration.TotalMilliseconds}ms");
});

// Route handler
app.MapGet("/home", () => "Welcome to Home Page");

// Run the application
app.Run();

Middleware in Go Fiber

Now let’s move to Go Fiber, a web framework built on top of Fasthttp, offering performance similar to Express with a Go flavor.

Here’s an example:

package main

import (
    "github.com/gofiber/fiber/v2"
    "github.com/gofiber/fiber/v2/middleware/compress"
    "log"
    "time"
)

func main() {
    app := fiber.New()

    // Standard Middleware that compresses every response
    app.Use(compress.New())

    // Custom Middleware that logs every request
    app.Use(func(c *fiber.Ctx) error {
        start := time.Now()
        err := c.Next() // Pass control to the next middleware or route handler
        duration := time.Since(start)
        log.Printf("Request to %s took %v", c.Path(), duration)
        return err
    })

    // Route handler
    app.Get("/home", func(c *fiber.Ctx) error {
        return c.SendString("Welcome to Home Page")
    })

    // Start server on port 3000
    log.Fatal(app.Listen(":3000"))
}

Conclusion

In summary, middleware is a practical way to handle cross-cutting concerns like logging, compression, and authentication in web applications. Whether you’re using Node.js, .NET, or Go, middleware helps you organize these tasks efficiently. By understanding how to work with the next function and middleware order, you can keep your code clean and adaptable, making it easier to build scalable applications that respond well to changing needs.

What is Middleware? was originally published in Code&Beyond on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the past, as application developers, we were not only responsible for developing our applications but also had to manage the entire deployment process. When we wanted to deploy our application, we had to rent servers, virtual machines, or other resources from hosting providers, and all installations and configurations had to be handled by the developers themselves.

For example, the installation of the database for the application to be deployed on the server had to be carried out by the developer. Tasks such as regularly taking database backups and, in more advanced applications, setting up synchronization and data replication between databases in a cluster had to be manually configured by the developers.

Hosting and cloud refer to different concepts!

However, over time, the requirement for increasingly complex applications to be available 24/7 (highly available) and to respond within milliseconds (low-latency) made the deployment processes more challenging and time-consuming for developers.

At this point, cloud and cloud providers came to the rescue of developers. They enable developers to deploy the desired database, server, or application in any region with high availability, all with a single click, without the hassle of complex setups. This allows developers to focus solely on coding and problem-solving, without having to deal with any infrastructure-related tasks.

So, how do cloud providers manage to offer such highly available and low-latency systems worldwide?

In this article, we will explore the deployment strategies used by cloud providers such as AWS, Azure, and GCP to deliver cloud services with high availability and low latency to their customers.

First, we need to examine the concepts of zone and region.

A zone is a group of servers where applications are deployed in small clusters. This structure can be thought of as different shelves in a library, separate rooms within the same building, or distinct buildings within the same campus. The key aspect of zones is their proximity to each other, allowing them to communicate with very low latency (within milliseconds).

A region, on the other hand, is a structure formed by the combination of at least three zones. Regions are designed to ensure service continuity even in the event of natural disasters such as earthquakes or tsunamis. If one region becomes unavailable, other regions can continue to provide service without interruption.

The naming convention for zones and regions generally follows the format below:

For example, AWS has a region called us-east-1 located in Northern Virginia. This region includes several availability zones: us-east-1a ,us-east-1b ,us-east-1c ,us-east-1d and us-east-1e. Additionally, there is another region, us-east-2, located in Ohio, which contains the availability zones us-east-2a ,us-east-2b and us-east-2c

After discussing the concepts of zones and regions, we will now examine the types of deployments used for deploying cloud applications.

1. Zonal Deployment

This type of deployment involves deploying all components of an application within a single zone. It can be further divided into two categories:

• Single Zone: In this deployment type, all components of the application (such as storage, network, etc.) are hosted in a single zone. This setup is generally not suitable for production environments. It is more appropriate for test applications where data loss is not critical and outages do not pose significant problems.
• Primary Zone with Failover Zone: This deployment strategy involves deploying the application in two different zones simultaneously. In the event of a failure in one zone due to power outages, fires, or other reasons, traffic is automatically or manually redirected to the same application running in the second zone. This principle helps ensure higher availability and resilience for the application.

2. Regional Deployment

This deployment type involves serving the application through multiple zones within a single region. It can be divided into two categories:

• Single Region: In this deployment type, the application is deployed across multiple zones within a single region. Incoming traffic is directed to the active zone, typically attempting to funnel requests through the same zone to achieve better performance.
• Primary Region with Failover Region: In this strategy, the application is deployed across multiple zones in several regions. This setup ensures that if one region goes down, the zones in another region can continue to provide service. For example, if a region in Europe becomes unavailable, the application can still be served by zones in the Middle East region.

3. Multi-regional

This deployment scenario involves deploying the application across multiple regions. In cases where users from different continents access the application, users are directed to the instance in the region closest to them to achieve low latency.

Additionally, if the application’s requirements necessitate storing confidential information about users and regulations dictate that the laws in a particular region do not allow this data to be stored in another region (data sovereignty), this deployment type can also be utilized.

In this setup, users’ data is stored in a single region, ensuring compliance with regional data protection laws.

4. Global

In scenarios where the application is used globally, deployment is desired across multiple regions. Users retrieve data from the region closest to their location. Instead of storing a user’s data in a single region, the data is distributed across all regions. Consequently, the application deployed in all regions operates as if it were a single, unified application, providing a seamless experience to users regardless of their geographic location.

5. Hybrid

This scenario involves the application running both on-premises and in the cloud, working together in an integrated manner. By implementing failover mechanisms between the on-premises and cloud environments, the system’s availability is enhanced. This hybrid deployment allows for improved resilience, ensuring that if one environment experiences issues, the other can take over, thereby maintaining service continuity.

6. Multi-cloud

This scenario involves deploying the application across multiple public cloud providers to enhance its availability. By doing so, if an issue arises with one cloud provider, the application instances running on the other cloud provider can continue to provide service. This multi-cloud deployment strategy ensures greater resilience and minimizes the risk of downtime, allowing for seamless service delivery even in the event of provider-specific failures.

The image below will make all of this information more memorable for you.

References:

• Berenberg, A., & Calder, B. (2023). Deployment archetypes for cloud applications. Google Inc.
• https://cloud.google.com/architecture/deployment-archetypes

Deployment Archetypes for High Availability and Low Latency was originally published in Code&Beyond on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are going to use the repo from my previos JWT example story. Since the app uses a db connection and I want to keep everything simple, we will use docker-compose to build image for each step.

services:
  app:
    build: .
    container_name: fiber-jwt-app
    image: fiber-jwt-app-1  # 1 is the step number
    depends_on:
      - db
    env_file:
      - docker.env
    ports:
      - "3000:3000"
  db:
    ...

The Primitive Beginner

This is the typical approach many beginners follow. We use the full golang:1.22.5 image, which is based on Debian. This image is large because it includes everything needed for Go development, including build tools and libraries. Additionally, there are other large files inherited from the Debian base, such as package managers and system utilities, which are unnecessary for running the compiled application.

FROM golang:1.22.5

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download
COPY . .

RUN go build -o main .

CMD ["/app/main"]

We copy go.mod and go.sum first and run go mod download to take advantage of Docker’s caching. If dependencies haven’t changed, this step is cached, so Docker skips re-downloading them in future builds. This speeds up the process, as only the application code is re-copied and rebuilt when modified.

Using the Alpine Base Image

To reduce the size, we switch to the alpine version of the Go image. Alpine is a minimal Linux distribution that’s much smaller than Debian.

FROM golang:1.22.5-alpine

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download
COPY . .

RUN go build -o main .

CMD ["/app/main"]

We can see a little bit improvement here in image size but,

Do we need all of the content from the Alpine image to run our application?

Not really.

Multi-stage Build with Alpine

The Golang Alpine image, while lightweight compared to standard base images, still includes tools and libraries that are only necessary during the build process, such as the Go compiler and build dependencies. Once we compile our Go application into a static binary, we no longer need these build tools or libraries in the final runtime environment.

This is where multi-stage builds come in handy. In the first stage, we use the Golang Alpine image to compile the Go application. Then, in the second stage, we copy only the final binary into a minimal base image.

In the first stage, we compile the Go binary in a larger image. In the second stage, we copy only the compiled binary into a minimal alpine base, discarding everything else.

This way, we only include what’s absolutely essential for running the app, significantly reducing the image size and removing unnecessary files that could potentially increase the attack surface or slow down deployment.

FROM golang:1.22.5-alpine

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download
COPY . .

RUN go build -o main .

FROM alpine:latest

WORKDIR /app

COPY --from=builder /app/main .

CMD ["./main"]

Look how far we’ve reduced the size with this step! By using a multi-stage build, we’ve brought the image size down from hundreds of megabytes to just 26.2 MB. This is a crucial improvement because we are now separating the build environment from the runtime environment

Adding Build Flags for Further Optimization

To reduce the size even further, we can strip unnecessary debugging information from the Go binary using -ldflags="-s -w". By using the build flags -s and -w, we remove the symbol table and DWARF debugging information, which shrinks the size of the binary.

FROM golang:1.22.5-alpine as builder

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download
COPY . .

RUN go build -ldflags="-s -w" -o main .

FROM alpine:latest

WORKDIR /app

COPY --from=builder /app/main .

CMD ["./main"]

The Ultimate Minimal Image with scratch

Finally, we can use the scratch base image, which is completely empty and doesn’t even include a Linux distribution. It doesn’t even have basic commands like bash, cat and curl. This is the smallest possible image, and since Go can compile statically linked binaries, it’s perfect for Go applications.

FROM golang:1.22.5-alpine as builder

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download
COPY . .

ENV CGO_ENABLED=0  #Disables C dependencies for portability.

RUN go build -ldflags="-s -w" -o main .

FROM scratch

WORKDIR /app

COPY --from=builder /app/main .

CMD ["./main"]

We’ve reached the ultimate level of optimization with this final step! By using the scratch base image, we’ve reduced the size of the Docker image to an impressive 12 MB. This is possible because scratch is an entirely empty image—there's nothing but the Go binary we compiled. By statically compiling the binary with CGO_ENABLED=0, we ensure it doesn’t need any external libraries to run.

However, while this gives us the maximum efficiency for production, it does require more careful handling since scratch lacks tools for debugging or runtime adjustments.

Caveats for scratch image

While using the scratch base image creates the smallest Docker image, there are a few disadvantages to keep in mind:

1. No utilities or tools: scratch is completely empty, meaning it doesn’t include basic tools like bash, curl, or cat. This makes debugging and troubleshooting inside the container difficult.
2. No package manager: You can’t install anything into a scratch image, so you need to ensure your Go binary is fully self-contained and statically compiled.
3. Limited debugging: Since there are no tools, you won’t be able to inspect logs or make quick fixes inside the container.
4. External dependencies: If your app relies on external libraries or dynamically linked dependencies, you’ll need to handle them explicitly, as scratch won’t include them.

Conclusion

By following these steps, we’ve reduced the size of our Docker image from 1.25 GB to 12 MB — a reduction of more than 99%! Using multi-stage builds, alpine, build flags, and the scratch base image, we’ve created a highly optimized Docker image that’s fast to deploy, small to transfer, and efficient to run.

Key takeaways:

1. Start by using a smaller base image like alpine.
2. Use multi-stage builds to keep only the necessary runtime files.
3. Use build flags to strip out unnecessary information from the binary.
4. For ultimate size reduction, use scratch and a statically compiled Go binary. (But be mindful of the caveats)

By applying these techniques, you can ensure that your Go applications are packaged efficiently in Docker. Happy coding!

Dockerizing Golang Apps: A Step-by-Step Guide to Reducing Docker Image Size was originally published in Code&Beyond on Medium, where people are continuing the conversation by highlighting and responding to this story.

Processes running on the operating system need to communicate with each other. There are various methods that processes can use to communicate with each other. Shared Memory, Message Passing, and similar methods are commonly used for inter-process communication.

However, let’s consider that these two processes are running on different machines. In client-server systems like these, the most common methods for communication between processes are sockets, remote procedure calls (RPCs), and pipes.

In this article, we will utilize communication using sockets. So, what is a socket? Sockets enable processes to communicate with each other over the network. Operating systems have different implementations for sockets. For detailed information about Linux’s socket implementation, for example, we can refer to the Linux Kernel documentation.

Various types of sockets exist, such as TCP sockets, UDP sockets, and others. The primary purpose of these sockets is to facilitate communication between processes running on the network over the network.

For instance, when two isolated processes, such as the application where you keep your notes and a grammar check application that verifies your writing rules, need to communicate, they can use TCP sockets to exchange information in a specific format.

In the same way, our server app process (backend) running on the server and the process (client) attempting to access it via a web browser will communicate fundamentally over TCP.

The HTTP protocol is a protocol built on top of TCP. So, what does the term ‘protocol’ mean? A protocol is a set of predefined rules that two systems follow when communicating with each other. Messages sent in a specific format according to the rules of HTTP are interpreted and necessary actions are taken by the other system that understands the language/rules.

Now, we can start writing our HTTP server from scratch. First, we will ask the operating system to set up a socket for us:

using System.Net.Sockets;

using var socket = new Socket(SocketType.Stream, ProtocolType.Tcp);

When we run the above code on a Linux operating system, our code, through the GNU C Library (libc), makes a system call to the Linux kernel, and the kernel provides us with a TCP socket. (This can vary depending on the programming language used.)

Let’s continue from where we left off in the code. Since we will be using TCP for byte streaming, we specify that the socket is of type Stream. Additionally, we indicate that the protocol to be used is TCP. Now, we need to specify which host and port numbers to bind to this socket.

using System.Net;
using System.Net.Sockets;

using Socket socket = new Socket(SocketType.Stream, ProtocolType.Tcp);

var host = IPAddress.Parse("127.0.0.1");
var port = 7888;

var endpoint = new IPEndPoint(host, port);

socket.Bind(endpoint);

This endpoint is composed of an IP address and a port number. The reason for using a port number is to determine which process on the machine will receive the transmitted message among many processes. The use of an IP address is to understand which machine on the network will receive the message. In the end, the endpoint used by TCP takes a structure like 127.0.0.1:5300.

As seen, we have bound the socket to the 7888 port on our local machine, identified by the address 127.0.0.1. Now, we can start listening on this endpoint.

using System.Net;
using System.Net.Sockets;

using Socket socket = new Socket(SocketType.Stream, ProtocolType.Tcp);

var host = IPAddress.Parse("127.0.0.1");
var port = 7888;

var endpoint = new IPEndPoint(host, port);

socket.Bind(endpoint);

socket.Listen(10);

Console.WriteLine($"Listening on port {port}...");

while (true)
{
    // Accept incoming connection
    Socket clientSocket = socket.Accept();

    // Handle the accepted socket
    HandleClient(clientSocket);
}

void HandleClient(Socket clientSocket)
{
    // Handle the connection (you can add your logic here)
    // For example, read data from the client
    byte[] buffer = new byte[1024];
    int bytesRead = clientSocket.Receive(buffer);
    string receivedData = Encoding.ASCII.GetString(buffer, 0, bytesRead);
    Console.WriteLine($"Received data: {receivedData}");

    // Close the client socket
    clientSocket.Close();
}

The number 10 in the code specifies the backlog. So, what is the backlog? Multiple clients may want to connect to our server simultaneously. However, establishing the connection between the server and the client takes time due to the three-way handshake. In this case, incoming connection requests are queued up. The backlog parameter determines how many connections will be queued up in this queue. If more connection requests come in, our server will reject them.

Now, our socket is in a listening state. However, at the moment, it only prints the message sent by the client to the console. Now, let’s see what we will do with these packets coming over TCP, i.e., how we will write the HTTP server. In a sense, we will teach HTTP rules to TCP. For this, let’s take a closer look at HTTP first.

HTTP requests consist of two main parts: header and body. Below is a simple GET request sent to the google.com address.

As can be understood from the image, the steps involved are:

• Connect to the server via TCP connection.
• Send an HTTP message over the TCP connection.
• Read the response sent by the server.
• Close the connection.

So far, with the above code block, we have only written the part that establishes the TCP connection. Now, we need to interpret the incoming HTTP message in a specific format.

Accordingly, let’s take a closer look at the HTTP message sent by the client.

In addition to the image above, there is a special character \r\n at the end of each line. This represents a line break. Additionally, each empty line between lines indicates a new segment. For example, the empty line between the HTTP response header and the response body distinguishes these two parts.

We need to parse this incoming HTTP request on our TCP server. We can do this as follows:

void HandleClient(Socket clientSocket)
{
    // Handle the connection (you can add your logic here)
    // For example, read data from the client
    byte[] buffer = new byte[1024];
    int bytesRead = clientSocket.Receive(buffer);
    string receivedData = Encoding.ASCII.GetString(buffer, 0, bytesRead);
    Console.WriteLine($"Received data: {receivedData}");

    string[] lines = receivedData.Split("\r\n"); // Split all lines by new line

    string[] requestLine = lines[0].Split(' '); // Split the first line by space

    string method = requestLine[0]; // GET, POST, PUT, DELETE, etc.
    string path = requestLine[1]; // The path of the request like /index.html
    string httpVersion = requestLine[2]; // HTTP version like HTTP/1.1

    // ...
    // handle the request based on the method and path 
    // by using backend application server logic
    // ...

    // Send a simple HTTP response back to the client
    string response = "HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\nHello, World!";
    byte[] responseBytes = Encoding.ASCII.GetBytes(response);
    clientSocket.Send(responseBytes);

    // Close the client socket
    clientSocket.Close();
}

Here, we are parsing the incoming request according to HTTP standards. Later, based on the content of this parsed HTTP request, we enable our backend application to perform its logic. Finally, we create a response and send it back to the client as bytes.

By following this approach, we have essentially written a basic HTTP server. The server we’ve created can be further developed into a real HTTP server. For this, the implementation of all HTTP standards is required. We can refer to the RFC pages for the HTTP standards. For example, to explore the details of the HTTP 1.0 implementation, you can visit this link.

Finally, let’s take a look at HTTP versions and the features they bring. HTTP is developed by the HTTP community and is becoming more efficient over time. Briefly looking at its history:

• HTTP 0.9: The first version of HTTP, performing basic request/response operations at a simple level.
• HTTP 1.0: Introduced new features such as status codes, request/response headers.
• HTTP 1.1: This version introduced the pipelining feature, eliminating the need to wait for the response of a previous request before sending a new one. This allowed sending multiple requests in succession, increasing speed. It also introduced the ability to reuse the same connection for other requests.
• HTTP 2.0: In previous HTTP versions, a new connection was opened for each request. With HTTP 1.1, the ability to send multiple parallel requests over a single connection (multiplexing) was introduced.
• HTTP 3.0: Started using QUIC instead of TCP in the transport layer.

You can access the GitHub code from the link below.

GitHub - onurkanbakirci/HttpOverTCP: Own HTTP implementation

Writing an HTTP Server on Top of the TCP Layer from Scratch was originally published in Code&Beyond on Medium, where people are continuing the conversation by highlighting and responding to this story.