DEV Community: Erik Santana

Creating a reverse proxy and load balancer in 2 minutes using Caddy

Erik Santana — Fri, 24 Jan 2025 22:13:29 +0000

Setting Up Your Computer:

To perform what will be demonstrated in this example, you'll need these tools:

Node 22: https://nodejs.org/pt/blog/release/v22.11.0
Caddy: https://caddyserver.com/docs/install

Introduction:

Two well-known approaches in DevOps are reverse proxy and load balancer. Let's understand them:

Reverse proxy:

A Reverse Proxy is an approach where a server receives requests and acts as middleware with conditions and overrides to forward to a specific server. After the server responds, the reverse proxy is responsible for responding to the end user.

In the example above, the user makes a request to localhost:8080 or service2.com.br, and the reverse proxy will work based on its conditions, which in this case would be:

If a header "x-service-1" exists, it will call Service 1
If the host is "service2.com.br", it will call Service 2
If the path contains "/test", it will call Service 3

A use case for using a reverse proxy is when you don't want to expose multiple domains to the internet or when these applications are on a private network. In this scenario, you can leave only your reverse proxy public while keeping the applications private.

In this scenario, all Services are private, meaning you cannot access them directly. However, you use the reverse proxy to make calls using a single domain: api.domain.com

Load balancer:

Load balancer is an approach used to handle multiple instances of a single application (or multiple applications with certain conditions, though this approach is not ideal and is typically used to reduce costs).

Similar to a reverse proxy, the key difference with a Load Balancer is that it uses algorithms to decide which instance to call. Consider an example:

Suppose you have an API with 4 instances. How would you distribute traffic effectively to prevent one instance from being overloaded while another remains idle?

Using a Load Balancer solves this problem, as you can employ the most common algorithm, Round Robin, which is equitable and efficient in distributing traffic.

Unlike a reverse proxy, a Load Balancer points to a single application, distributing traffic equally and avoiding instance overload.

Another interesting point about Load Balancer is that we can specify a route that it can access periodically to check if the server is up. If the server is not running, the Load Balancer will not distribute traffic to the broken server.

Are they the same thing?

Definitely not. A load balancer can point to a reverse proxy, which in turn points to N load balancers, and many other existing scenarios.

Putting into Practice:

Now that you've learned about reverse proxy and load balancer, it's time to implement a basic example using Caddy and Node.js.

We'll use Caddy to create a server that will act as a reverse proxy and balance load using round-robin, and Node.js to create multiple instances of the same API.

Starting with Node.js, we'll create two files: server.js and start_workers.js

For server.js (which creates a simple server):

import { workerData } from "node:worker_threads";
import http from "node:http";

const sleep = async (ms) => {
    return new Promise(res => setTimeout(res, ms));
}

const server = http.createServer(async (req, res) => {
    // We use sleep to get a real example of a request that takes 2 seconds to respond
    await sleep(2000);

    const data = `Hello, this is the same API in different instance ${workerData.instanceId}`

    console.info(data);
    res.writeHead(200, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({
      data,
    }));
});

console.info(`Server is running on port ${workerData.port}`)
server.listen(workerData.port);

It will start on the port passed by the parent process
Each call will display a message showing the instance ID

For start_workers.js:

import { Worker } from "node:worker_threads";
import path from "node:path";

for (let i = 0; i < 5; i++) {
    const worker = new Worker(path.resolve(process.cwd(), "server.js"), {
        workerData: {
            port: 8081 + i,
            instanceId: i
        }
    });
}

It will create 5 workers
Each worker will be an API running on different ports: :8081, :8082, :8083, :8084, :8085
Each worker will have a corresponding ID: 1, 2, 3, 4, 5

To use Caddy, we'll create a file called Caddyfile with the following configuration:

{
    admin 0.0.0.0:5555
}

:8080 {
    reverse_proxy :8081 :8082 :8083 :8084 :8085 {
        lb_policy round_robin
    }
}

The above file means we'll receive requests on port :8080, and Caddy should perform reverse proxy to ports :8081, :8082, :8083, :8084, :8085. Additionally, we specify that the Load Balancer will use Round Robin to decide which instance to call.

Running the Project

Once these three files are created, open 3 terminals in the project folder:

First terminal, start the Caddy server:

caddy run

Second terminal, start Node servers:

node start_workers.js

Third terminal, use autocannon to create parallel requests:

npx --yes autocannon http://localhost:8080

To stop Caddy server, remember to run:

caddy stop

This command calls the reverse proxy, which will distribute traffic equally among our 5 Node servers.

You'll see something like:

As you can see, even without directly calling ports :8081, :8082, :8083, :8084, :8085, the reverse proxy distributed traffic equally without overloading any server.

If you can't reproduce this, you can verify the implementation in the GitHub repository: https://github.com/ekerdev/example-reverse-proxy-and-load-balancer

Understanding Server-Side Rendering Like a Pro

Erik Santana — Fri, 24 Jan 2025 08:47:57 +0000

Introduction

If you are a developer, especially one working in Front-end development, you probably know that the most modern way of building applications today is by using Server-Side Rendering, commonly known as SSR. This approach significantly enhances your site's indexation (SEO) across key market players.

As with everything in programming, SSR has its pros and cons. For you, the developer who may only be familiar with its advantages, I decided to list some of its disadvantages as well.

Understanding SSR

First, let’s understand why the need for server-side rendering emerged and why it’s now uncommon to see applications being built with Client-Side Rendering (CSR).

No, Next.js was not the creator of SSR. In fact, long before frameworks like React, Vue, and Angular existed, the web relied on either static rendering or server-side rendering. Let’s look at a few examples:

Static Sites: HTML, CSS, JavaScript, and jQuery: These sites were entirely rendered in the user's browser. All the information appeared instantly on the user’s screen, and the browser executed the scripts embedded in the site to populate the screen. When you inspected the code, you would see something like this:

What user and you see

<html>
<body>
 <h1>List of best players of the world</h1>
 <script>
  async fetchListOfBestPlayersOfTheWorld() {
   const res = await fetch(...);
   const data = res.json();

   // loop to add content in html
  }

  fetchListOfBestPlayersOfTheWorld()
 </script>
</body>
</html>

First Content Paint (FCP)

Server-Rendered Sites: PHP or JSP: These sites were rendered by the language interpreter and displayed the result on the user’s screen. This meant the information was already filled in when displayed. If you inspected the code, you’d see something like this:

What you see:

<%
List<PlayerDTO> bestPlayersOfTheWorld = APIService.getBestPlayersOfTheWorld();
%>
<html>
<body>
 <h1>List of best players of the world</h1>
 <ul>
  <% for (PlayerDTO player : bestPlayersOfTheWorld) { %>
   <%-- loop to add content in html --%>
  <% } %>
 </ul>
</body>
</html>

What user see:

<html>
<body>
 <h1>List of best players of the world</h1>
 <ul>
  <li>Cristiano Ronaldo</li>
 </ul>
</body>
</html>

First Content Paint (FCP)

It’s clear that both types of sites achieve the same goal, but the static site doesn’t render the list until it’s loaded in the browser, unlike JSP, which makes the API call on the server, renders the page in the interpreter, and only then delivers it to the user.

From this, we can conclude that Next.js didn’t invent SSR. This approach has existed for years across many languages like PHP, Java (using JSP or other frameworks), ASP.NET, and more.

The Chaos

When React, Vue, and Angular became popular, there was a shift in the market. Nobody wanted to write countless lines of code anymore to create a basic site using jQuery, JSP, PHP, etc. Why not use these modern tools instead?

And so, we humble developers abandoned those old tools and started using React, Vue, and Angular to build our websites. Now, Front-end development had a single responsibility: creating pages and reusable components while reducing the load time we used to experience with tools like jQuery and Bootstrap.

Let’s explore the advantages these tools offered:

Code reuse that brought more readability and longevity to projects.
Complete builds that eliminated unused code and improved page load times.
CSS compilers that removed unused styles and added cross-browser compatibility.

Pretty cool advantages, right? I agree. But we had three major issues:

These tools were WORSE than static sites in terms of SEO:

Despite being similar to static sites, the modern tools didn’t write your code directly into the HTML. Instead, your site relied on JavaScript generated by library (called the bundle). After being downloaded, this bundle would inject your code into the site. For example:

With these tools, we wouldn’t even see the "List of Best Players of the World" until the browser had finished downloading the bundle and executing the script, as shown in the example below:

Your code

const ListOfBestPlayersOfTheWorld = () => {
 const { data: players } = useAPI(api.listOfBestPlayersOfWorld);

 return (
  <>
   <h1>List of Best Players of the World</h1>
   <ul>
     {players?.length && players.map((player) => {
      // loop to add content in html
     })}
   </ul>
  </>
 )
}

What user see

<html>
<body>
 <script src="/assets/bundle.js"></script>
</body>
</html>

First Content Paint (FCP)

The build file size could exceed 100MB, causing both download and load-time slowdowns:

In combination with the previous issue, if your site was very large, the generated bundle could become excessively large, causing delays for users and potentially being slower than loading the full jQuery script.

Furthermore, these tools relied on internal routing, meaning the bundle would load information for all pages, even if the user was only on the homepage, for instance.

One of the solutions to address this problem was the use of Lazy Loading, which delayed content presentation for the user but broke the code into smaller secondary bundles. Additionally, CDNs with caching were employed to ensure that users would only load the bundle once (with the cache being revalidated when changes were made to the site).

However, depending on the size of the primary bundle, these solutions still didn’t fully resolve the issue.

Excessive Use of JavaScript, neglecting native browser solutions (a topic addressed in the HTML-first approach):

How 'reacters' do

const ModalComponent = () => {
 const [open, setOpen] = useState(false);

 const onToggle = () => {
  // using useState that render after each change
  setOpen((open) => !open);
 }

 return <Modal open={open} onClose={onToggle} onOpen={onToggle} />
}

How 'html-firsters do'

const ModalComponent = () => {
 const ref = useRef<HTMLDialogElement>(null);

 const onOpen = () => {
  // using native solutions, no rerender
  ref?.current.showModal();
 }

 const onClose = () => {
  // using native solutions, no rerender
  ref?.current.close();
 }

 return <dialog ref={ref} />
}

The solution to the problem we created

Don’t be too upset with these tools—they genuinely improved the lives of front-end developers. However, certain issues started to grow too large to ignore, such as oversized bundles that led to high CDN costs, usability problems when JavaScript failed due to state management issues, and non-existent SEO, which negatively impacted site indexing.

That’s when we decided to take a step back and revisit the Server-Side Rendering (SSR) approach, using tools like Next.js, Nuxt, Qwik, Gatsby, and @angular/ssr.

Now that you’ve learned a bit about how Client-Side Rendering (CSR), Server-Side Rendering (SSR), and Single Page Applications (SPAs) work, I’ll share my perspective as a senior software engineer on this approach, along with its advantages and disadvantages:

Advantages:

Effective SEO:

Since the site uses the server, you can configure all metadata () and load all or most of the site’s information before rendering it in the browser. This generates the First Content Paint, which is the moment when the indexing bot "takes a snapshot" of your code and extracts information from the HTML to index your page on search engines.

Performance:

There’s a trade-off between performing tasks on the server or delegating them to the client. If you choose the client-side approach, the user’s experience might be negatively affected, as it demands high computational resources and can cause issues if they have a poor internet connection or weak hardware. It also increases the size of the bundle.

On the other hand, opting for server-side tasks improves user fluidity since the server handles the heavy lifting. This avoids overloading the user's browser and prevents generating a larger bundle.

Server Network Optimization:

If you make API calls within your domain, particularly within your private network (VPC), you’ll get faster responses because you can bypass much of the DNS resolution process.

When making a server-side call, instead of calling https://api.mydomain.com, you can directly call the internal IP or DNS of the service, reducing response time. This is because there are fewer DNS resolutions to reach the final address. Depending on the endpoint called, this can also reduce cloud costs (such as Route 53, Cloud DNS).

Note: This approach only works for server-side calls where your application is in the same network and region as your service. If attempted on the client-side, you must ensure users are part of the same private network, such as via a VPN.

Client Network Optimization:

If the user does not have a very fast internet connection, performing calls and processes on the server-side will save time for the page to load completely for the user.

Security:

Since your code runs on the server, you ensure that sensitive code or information—such as environment variables or internal logic—is not exposed to attackers. This adds an extra layer of security to your application.

Disadvantages:

Costs:

If a server exists, someone is paying to keep it active. Server-Side Rendering can be expensive, depending on the complexity of your application, generating resource costs in the Cloud and, for more advanced cases, entire infrastructure costs to maintain it scalably, such as the use of Load Balancers.

In programming, trade-offs are always present, and in this case, you need to analyze whether the advantages compensate for the cost.

Static Files

Even when using a server-side rendering approach, some frameworks can generate static files to be loaded in the browser. For example, Next.js. If this is your scenario, you must decide whether to use the front-end server itself to serve these static files or host them on a CDN.

If you choose to let your server serve the static files, remember that if your application has 5 static files, each request will result in 5 additional requests to load those files. Some frameworks include features for caching these files to prevent users from downloading them every time they access your application. However, this scenario should still be carefully considered.

Infrastructure:

Complementing the previous disadvantage, using this approach requires more cloud knowledge in certain scenarios, as you'll need to maintain an infrastructure for the application to function. If you adopt this approach, you'll likely encounter the following costs:

Container image storage
Load balancers
Container orchestration
Machine instances
Networking
CDN

If you misconfigure the application or allocate insufficient resources without considering the expected load, you'll likely end up with an unstable application that provides a poor user experience, since the server renders the content.

Visual Bugs:

When using a framework that employs HTML hydration (e.g., Next.js), you may inadvertently introduce production bugs if you're not careful with application hydration. You must always ensure that the server is synchronized with the client and guarantee proper control and hydration synchronization between them.

The Tip

After providing this entire context to help make more assertive decisions, I'll share my approach to choosing languages, frameworks, and strategies for my applications:

This flowchart takes into consideration a front-end that will communicate with a REST backend, with no delivery deadlines, and will be hosted on a cloud platform such as AWS, GCP, or Azure, without delving into detailed questions.

Note: These are basic questions and cannot answer all scenarios.

English

Português

Reading configuration like a pro on Spring

Erik Santana — Thu, 23 Jan 2025 01:57:48 +0000

Introduction

As we already know, Spring provides many ways to achieve the same thing, and one of them is how to retrieve the values registered in your configuration file.

If you're new to Spring, you might come across code that uses the @Value annotation to retrieve values from your application.properties or application.yml file. If you're using this approach, know that it's not wrong; however, you might be introducing unnecessary complexity into your application.

The Problem with @Value

The main issue with using @Value arises when we deal with values that contain other values. Does that make sense? No? Let's look at an example:

Suppose you have the following configuration file:

mail.user=dev@locahost
mail.password=123
mail.headers.x-from=Ekerdev
mail.headers.x-custom=custom

You would need to do it like this:

@Service
public class CustomService {
 @Value("mail.user")
 private String user;

 @Value("mail.password")
 private String password;

 @Value("mail.headers.x-from")
 private String xFrom;

 @Value("mail.headers.x-custom")
 private String xCustom;
}

So far, no problem. But now imagine a scenario where your application needs to use these same values in multiple places in the code. Think of how much duplicated code we’d end up with, right?

The Solution

The best solution, then, is to use the @ConfigurationProperties annotation. This makes it easier for our application to inject variables into a class, and we can use it just like any other dependency in Spring, injecting it as shown in the example below:

Alternative 1 using Spring 3.x:

@Configuration
@ConfigurationProperties("mail")
public record MailProperties(
 String user,
 String password,
 Map<String, String> headers
) {}

Alternative 2 using Spring 3.x:

@Configuration
@ConfigurationProperties("mail.headers")
public record MailHeadersProperties(
 String xFrom,
 String xCustom,
) {}

@Configuration
@ConfigurationProperties("mail")
public record MailProperties(
 String user,
 String password,
 MailHeadersProperties headers,
) {}

Alternative 1 using Spring 2.x:

@Data
@AllArgsConstructor
@ConfigurationPropertiesScan
@ConfigurationProperties("mail")
public class MailProperties {
 private String user;
 private String password;
 private Map<String, String> headers;
}

@SpringBootApplication
@ConfigurationPropertiesScan("your.package.mailproperties")
public class ExampleApplication {
    public static void main(String[] args) {
        SpringApplication.run(ExampleApplication.class, args);
    }
}

And your service use properties like this:

@Service
@RequiredArgsConstructor
public class CustomService {
 private final MailProperties mailProperties;
}

The Advantage

The major advantage of using @ConfigurationProperties is that we don't have to hunt for @Value annotations in our code, which makes the code much more readable.