DEV Community: Carlos Talavera

Principle of Least Astonishment

Carlos Talavera — Tue, 17 Mar 2026 14:40:40 +0000

When we talk about creating “maintainable” or “sustainable” software, one of the key parts involved in achieving so is the Principle of Least Astonishment (a.k.a. POLA).

Sounds fancy, but it’s very simple.

Code is read many more times than it is written. This means that if software developers are going to spend a lot of time reading code, it should be easy to read, right?

Well, that’s where this principle comes into play.

One of the traits of code that is easy to read is that if some file, class, method, or any other artifact has a name that says “I do this”, then you expect it to do such a thing because… why wouldn’t it?

When you expect one thing and see something else, it surprises you. It “astonishes” you. Surprises in life might be nice, but when it comes to software, they’re not.

It’s not only about misleading names. It’s also about inconsistencies. For example, if you see that in module A the folder structure is one and in module B you find a different one, again, it surprises you.

So, this principle just says: “Do what you would expect to find. Do what makes sense. Create code so boring that there are no surprises and anyone can understand what’s going on without thinking they’re not smart enough”.

Boring code is predictable code. Predictable code is reliable.

If you’re looking for fun and surprises, you can go skydiving or try whatever activities people who love strong thrills usually enjoy.

But software? It’s not like people say, “I want to do something risky. Let’s create technical debt.” Well, at least I hope they don’t.

Next time you approach a problem, take a step back and think how you would expect things to work if you were an outsider. That’s the heart of POLA.

What keeps people motivated?

Carlos Talavera — Tue, 03 Mar 2026 15:00:31 +0000

In the past few months, I’ve been facing some challenges in my current job that made me think about motivation.

Why do some days feel easier than others?
What actually makes the difference?
Is it having less work — or more meaningful work?
What do we do on the days when everything feels overwhelming and starting seems impossible?

Each of us has different reasons that keep us going despite adversity.

The people we love. The money we earn. The dreams we’re building. The hobbies that keep us sane. The responsibilities we carry.

No reason is more valid than another — and most of the time, it’s a mix.

As I’ve progressed in my career as a software engineer, I’ve noticed how priorities shift.

At the beginning, motivation often comes from finishing tasks. You do what’s assigned. You get small, frequent wins. Maybe it’s shipping a feature. Learning a new language. Trying a new framework. Applying a pattern correctly. The feedback loop is short and satisfying.

But over time, something changes.

You stop thinking in terms of tasks.
You stop thinking even in terms of projects.
You start thinking in systems.

And systems are messy.

Dependencies are no longer just between Service A and Service B. They’re between teams. Between departments. Between priorities. Between people. Sometimes even between companies or regulations.

You realize that naming something isn’t trivial. A name can shape how a system evolves. Ten years later, that “temporary” decision might still be there — creating misunderstandings, misaligned expectations, and friction that slowly wears teams down.

The complexity grows. The wins take longer. The impact is less visible.

So what keeps us motivated when the work becomes less about tasks and more about navigating complexity?

I’m no expert, but here’s what works for me:

Break things down — aggressively.
You can’t hold an entire system in your head at once. But you can hold the next small piece. Progress at scale is just small clarity repeated many times.
Seek deep understanding.
An undefined problem is overwhelming. A grounded problem is actionable. The more precisely you understand the issue, the smaller it feels.
Ask for help.
Colleagues. Communities. Mentors. Even AI — as long as you stay critical. Complexity is lighter when shared.

And outside of work?

Disconnect. Rest. Do what you enjoy. Complexity requires energy — and energy isn’t infinite.

Motivation, for me, isn’t constant excitement.
It’s learning how to operate even when things feel heavy.

So I’m curious:
What keeps you motivated when the work stops being simple?

What is the domain and why is it important?

Carlos Talavera — Tue, 24 Feb 2026 16:05:22 +0000

One of the most important things I have learned as a software engineer is to design systems around the domain.

“What’s the domain?” — you might ask.

In terms of software design, I would define the domain as any useful unit of business.

For example, let’s say the business is real estate. One domain might be “rentals” and another one might be “sales”. Both have their own rules and logic and represent useful units that give us a full picture of the business.

That’s the whole point.

Why would the software — the code, the database entities, the tools, etc. — use technical and obscure names? Why would the software and the business speak two different languages?

This disconnection creates problems we’ve all seen in software development:

Product/Business and engineering are talking about the same thing, but using different words. This creates unnecessary confusion and friction
Business rules and semantics are all over the place. This means that the boundaries are not clear. Unclear boundaries are the perfect recipe for technical debt. This debt implies rigid software that is a headache to maintain and that doesn’t evolve with the product

If, instead, we design around the domain, we create expressive software. So expressive that anyone with business knowledge could understand most of what’s happening even if they don’t know the specifics of how to code.

Code that is easy to read is one of the fundamental parts of sustainable software.

The domain is so important that it is the core of any kind of “clean” architecture. Every other layer relies on the domain, while the domain doesn’t rely on anything else (why would it?). This is trivial if I say that in order to understand a system, you have to start by understanding the problem it’s trying to solve.

It’s so important that there’s even a design philosophy called “Domain-Driven Design” (a.k.a. DDD).

So now, every time you hear “the domain” in this context, you know what they mean, and if you want to approach a complex system, you know where to start.

Why do we create software?

Carlos Talavera — Tue, 17 Feb 2026 18:37:54 +0000

Let’s start with a "simple" question: why do we create software?

Humans pursue knowledge for two reasons: curiosity and solving problems. Sometimes they mix. You try to fix something and end up loving the learning. But for this reflection, let’s focus on the problem-solving part.

Every project we work on — personal or professional — starts with a problem. We try to automate boring stuff, prevent incidents, save time, improve accuracy, do what was previously impossible, coordinate people and processes… Basically, we try to make life a little easier.

In other words: software exists to reduce friction between what we want and what actually happens.

Sounds simple enough. But then… why does software so often make things worse? Why does it confuse people, break randomly, frustrate users, or make future work a nightmare?

Not because engineers don’t care. Not because the business is “evil”.

It happens because motivations aren’t fully aligned. Speed is easy to measure, maintainability isn’t. Shipping is visible; technical debt is invisible. Software feels reversible — like you could just CTRL + Z it later.

Spoiler alert: you can’t. Complex systems remember. Decisions pile up. Mistakes compound.

And yet, people still talk about “quality” like it’s a purist argument:

“The good practices say…”

Sure. But here’s the simpler truth: if we create software to solve problems, anything that introduces instability, fragility, or long-term friction is incomplete.

A complete solution:

Works correctly
Handles functional and non-functional requirements
Remains understandable
Can evolve as needs change

Anything less? It’s not done. It’s just shipped.

Quality isn’t a fancy ideal. It’s purpose realized.

And if we forget why we create software in the first place… well, don’t be surprised when it stops solving the problem.

Dockerizing a Next.js Application using a Standalone Build

Carlos Talavera — Sat, 19 Oct 2024 17:06:17 +0000

Introduction

Docker has gained popularity in recent years for enabling applications to be placed inside containers. These containers can be deployed to any environment and will work the same way in all of them, providing a uniform behavior regardless of the platform where the application runs. These containers use images, which are a copy or compressed snapshot of the application. By placing them within a container, they are displayed exactly as they are. This is one of those technologies that some were desperate for, while others don't realize they need it until they hear about it.

For its part, Next.js is the most popular React framework. As any other JavaScript application that uses a bundler such as webpack or Vite, for production a compiled version of the project is used. This is known as build. A build aims to provide the minimum amount of code needed for the application to function the same as it does in development. This ensures that JavaScript files are very lightweight, allowing the browser to fetch and interpret them in the shortest possible time to render the user interface or perform whatever tasks the application requires."

Next.js, specifically, offers a version that further reduces the build size: the Standalone Build. If we use Docker to create an image for our Next.js application, we can easily deploy that great application that we have built to any environment without worrying about compatibility or additional configurations. In this article, we'll see how to achieve it.

Package manager

In my case, I like to use pnpm to reduce the disk size of the node_modules folder. Therefore, the example of the Next.js Docker image uses this package manager, but you can make slight adjustments to use npm or yarn if you prefer.

Next.js configuration

In the next.config.js file, we have to specify that the resulting build type will be standalone when the application is compiled for production. For this, we need to include the following:

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: "standalone"
};

export default nextConfig;

This way, the output of the application will be of type standalone.

Dockerfile

The file that represents our Docker image is the Dockerfile. Commonly this file is placed in the root of the project. Let's create it step by step.

Base image

Every Docker image starts from a base image. In this case, any JavaScript project that runs a server, will need a runtime like Node.js. We'll take as base the Docker image of a Node.js version that is compatible with our project. In my case, I like to use the Alpine version of the images, since this is more lightweight. However, we have to check that there are no compatibility issues when building the image, otherwise, we have to use the "non-Alpine" version of the image. For this example, I use the node:22.6.0-alpine3.19 image as base.

FROM node:22.6.0-alpine3.19 AS base

We place an alias to recycle it in the different steps or stages of the image.

System and pnpm dependencies

The next stage is to install the dependencies. In this case, only one system dependency is required: libc6-compat. Here it is mentioned why.

FROM base AS build-deps
RUN apk add --no-cache libc6-compat

Since pnpm isn't included by default in Node.js, it is necessary to activate it and set the environment variables so as the installed packages can be cached.

ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"

RUN corepack enable
RUN corepack prepare pnpm@latest --activate

Then, we have to set the working directory to have a clear separation between the system folders and the application folder. In this case, we use /app.

WORKDIR /app

Now we have to copy the files containing the project dependencies information and install them.

COPY package.json pnpm-lock.yaml ./

RUN pnpm install --frozen-lockfile --prefer-frozen-lockfile

The --frozen-lockfile and --prefer-frozen-lockfile arguments are used to respect the versions specified in the lock file of pnpm.

To finish with this stage, the sharp library is added. This is necessary to optimize images in a production environment in Next.js.

RUN pnpm add sharp

The full stage looks like this:

FROM base AS build-deps
RUN apk add --no-cache libc6-compat

ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"

RUN corepack enable
RUN corepack prepare pnpm@latest --activate

WORKDIR /app

COPY package.json pnpm-lock.yaml ./

RUN pnpm install --frozen-lockfile --prefer-frozen-lockfile

RUN pnpm add sharp

Building the application

The next stage is to compile the Next.js application. This is where the key for making the image work lies, because the rest of the Dockerfile isn't anything different or that you can't find in any other example. At this stage it is necessary to pass as build arguments the environment variables used in the project and set them before generating the build.

This is because, as there are two times in which the applications work, build time and run time, if the environment variables are not available at run time, all the static assets that use them won't have a value for them and the application won't work properly. In this example, three environment variables are used: NEXT_PUBLIC_BACKEND_URL, FRONTEND_URL and JWT_SECRET.

FROM base AS builder

ARG NEXT_PUBLIC_BACKEND_URL
ENV NEXT_PUBLIC_BACKEND_URL=$NEXT_PUBLIC_BACKEND_URL

ARG FRONTEND_URL
ENV FRONTEND_URL=$FRONTEND_URL

ARG JWT_SECRET
ENV JWT_SECRET=$JWT_SECRET

Then, pnpm is activated, the work directory is set, all the application files are copied and the build is generated.

RUN corepack enable
RUN corepack prepare pnpm@latest --activate

WORKDIR /app

COPY --from=build-deps /app/node_modules ./node_modules

COPY . .

RUN pnpm build

The full stage looks like this:

FROM base AS builder

ARG NEXT_PUBLIC_BACKEND_URL
ENV NEXT_PUBLIC_BACKEND_URL=$NEXT_PUBLIC_BACKEND_URL

ARG FRONTEND_URL
ENV FRONTEND_URL=$FRONTEND_URL

ARG JWT_SECRET
ENV JWT_SECRET=$JWT_SECRET

RUN corepack enable
RUN corepack prepare pnpm@latest --activate

WORKDIR /app

COPY --from=build-deps /app/node_modules ./node_modules

COPY . .

RUN pnpm build

Running the application

The last stage is to run the application. To do this, we first set the Node production environment:

FROM base AS runner

ENV NODE_ENV=production

For personal preference, Next.js telemetry is disabled. That is, we basically don't send our application data to Vercel to improve Next.js through error diagnosis and usage metrics.

ENV NEXT_TELEMETRY_DISABLED=1

Also, as a good practice, it is recommended to use a non-root user in Docker images. This, for instance, avoids security breaches in case the container has access to the host network. To do this, a nodejs group and a nextjs user are added and assigned the .next folder property.

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
RUN mkdir .next
RUN chown nextjs:nodejs .next

Then, the files generated by the standalone build are copied to create the same structure of the default build of Next.js.

COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
COPY --from=builder --chown=nextjs:nodejs /app/public ./public

Since we created the nextjs user, we need to specify that this will be the user to use.

USER nextjs

Likewise, it is required to specify the exposed port of the container, as well as the Node port and the hostname that will be used, which will be 0.0.0.0 since we don't know the exact address.

EXPOSE 3000
ENV PORT=3000
ENV HOSTNAME="0.0.0.0"

Then, the environment variables for the application runtime are specified from the build arguments.

ARG NEXT_PUBLIC_BACKEND_URL
ENV NEXT_PUBLIC_BACKEND_URL=$NEXT_PUBLIC_BACKEND_URL

ARG FRONTEND_URL
ENV FRONTEND_URL=$FRONTEND_URL

ARG JWT_SECRET
ENV JWT_SECRET=$JWT_SECRET

Specified environment variables in a docker-compose.yml file can be used, as well as when running the container, however, it wouldn't make sense for the environment variables in this context to be different at build time and run time.

Finally, we run the server.

CMD ["node", "server.js"]

Complete file

The complete Dockerfile looks like this:

FROM node:22.6.0-alpine3.19 AS base

FROM base AS build-deps
RUN apk add --no-cache libc6-compat

ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"

RUN corepack enable
RUN corepack prepare pnpm@latest --activate

WORKDIR /app

COPY package.json pnpm-lock.yaml ./

RUN pnpm install --frozen-lockfile --prefer-frozen-lockfile

RUN pnpm add sharp

FROM base AS builder

ARG NEXT_PUBLIC_BACKEND_URL
ENV NEXT_PUBLIC_BACKEND_URL=$NEXT_PUBLIC_BACKEND_URL

ARG FRONTEND_URL
ENV FRONTEND_URL=$FRONTEND_URL

ARG JWT_SECRET
ENV JWT_SECRET=$JWT_SECRET

RUN corepack enable
RUN corepack prepare pnpm@latest --activate

WORKDIR /app

COPY --from=build-deps /app/node_modules ./node_modules

COPY . .

RUN pnpm build

FROM base AS runner

ENV NODE_ENV=production

ENV NEXT_TELEMETRY_DISABLED=1

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
RUN mkdir .next
RUN chown nextjs:nodejs .next

COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
COPY --from=builder --chown=nextjs:nodejs /app/public ./public

USER nextjs

EXPOSE 3000
ENV PORT=3000
ENV HOSTNAME="0.0.0.0"

ARG NEXT_PUBLIC_BACKEND_URL
ENV NEXT_PUBLIC_BACKEND_URL=$NEXT_PUBLIC_BACKEND_URL

ARG FRONTEND_URL
ENV FRONTEND_URL=$FRONTEND_URL

ARG JWT_SECRET
ENV JWT_SECRET=$JWT_SECRET

CMD ["node", "server.js"]

You can also find the file in this gist.

Conclusion

Creating a Docker image for a Next.js application can be daunting at first because of all the considerations we have to take into account. In addition, there is the popular belief that self-hosting a Next.js application, i. e., outside Vercel, is complicated. It isn't. By understanding the key parts, it's actually simple.

I hope that with this information you can dockerize your Next.js application without problems. And you know the drill, if you have any question or want to share something, leave it in the comments :)

Integrating Laravel Sanctum with Next.js SSR: Key Points

Carlos Talavera — Tue, 15 Oct 2024 18:18:05 +0000

Introduction

Next.js is a React framework which has gained popularity in the recent years because of its practical approach to route handling, SEO support, caching mechanisms for requests and the different rendering strategies it provides. In a nutshell, by supporting the use of a server, it allows to fetch data on the server instead of fetching it on the client (the browser, for instance). This allows for reduced response times, since once the user can see the interface the data is already available, as opposed to having to wait for the information to be fetched after the interface is visible. This is known as Server-Side Rendering, or in short, SSR.

For its part, Laravel Sanctum provides a simple way to authenticate applications that consume an API developed in Laravel. There are two authentication methods: using session cookies or API tokens. The first approach is perhaps not as well known. It is based on storing cookies in the browser that are sent with every request and verified by the API, hence it only works for web applications, where there is a browser. The second one is well known. A token is assigned to the user and as long as this token is included in the request headers, the user will be authenticated.

In this article we'll explore authentication using cookies, as this is where problems arise when trying to make requests from the server instead of from the client. Moreover, we have to take advantage of this method because it protects against CSRF attacks, which is impossible using API tokens.

This article talks about the key points, a few details are presented, but it's purely conceptual. At the end there's a link to a GitHub repository with the detailed implementation

The problem

When client-server requests are made, browser cookies are automatically sent. Besides, if there are cookies in the response, they are just simply stored in the browser without any intervention. However, when making a server-server request, cookies don't exist as such, because cookies are a concept of the browser, the server doesn't know anything about them. So, if you want to make a request from the server that includes cookies, you need to ask the browser for them and explicitly send them in the Cookie header. We'll see how to do this in the Next.js section.

Laravel

It's possible to install Sanctum and add all the necessary configurations, however, this takes time and because of this, Laravel offers us Breeze. Breeze creates the entire skeleton needed to implement authentication. It includes routes to log in and log out, register, verify email and reset password.

It also adds the necessary configuration for CORS and Sanctum so that we can focus on starting to develop our application. After following the installation steps of the previous link, there will be a part where it will ask us the type of application we want to use Breeze with. We'll select the API option so that it only gives us what we need to connect from Next.js.

Creating UserResource

We have to create an UserResource to return the user information in a standardized way. We first create the resource:

php artisan make:resource UserResource

Then we specify the fields as follows:

/**
 * Transform the resource into an array.
 *
 * @return array<string, mixed>
 */
public function toArray(Request $request): array
{
    return [
        'id' => $this->id,
        'name' => $this->name,
        'email' => $this->email,
        'emailVerifiedAt' => $this->email_verified_at,
        // Use camelCase so it matches the naming convention in JavaScript
    ];
}

Returning the authenticated user after login and registration

We have to modify the store method in AuthenticatedSessionController.php to return the authenticated user after login. The same applies to the store method in RegisteredUserController.php after registering an user.

// app/Http/Controllers/Auth/AuthenticatedSessionController.php
/**
 * Handle an incoming authentication request.
 */
public function store(LoginRequest $request)
{
    $request->authenticate();

    $request->session()->regenerate();

    return UserResource::make(Auth::user());
}

// app/Http/Controllers/Auth/RegisteredUserController.php
/**
 * Handle an incoming registration request.
 *
 * @throws \Illuminate\Validation\ValidationException
 */
public function store(Request $request)
{
    $request->validate([
        'name' => ['required', 'string', 'max:255'],
        'email' => ['required', 'string', 'lowercase', 'email', 'max:255', 'unique:'.User::class],
        'password' => ['required', 'confirmed', Rules\Password::defaults()],
    ]);

    $user = User::create([
        'name' => $request->name,
        'email' => $request->email,
        'password' => Hash::make($request->string('password')),
    ]);

    event(new Registered($user));

    Auth::login($user);

    return UserResource::make(Auth::user());
}

In the Next.js section we'll see why we have to do this.

CORS

Breeze will add an environment variable FRONTEND_URL that will contain the address of our Next.js application, which runs in http://localhost:3000 by default. To be able to share cookies, it's also important that there is support for credentials. Therefore, the CORS configuration should look like this:

// config/cors.php
'paths' => ['*'],

'allowed_methods' => ['*'],

'allowed_origins' => [env('FRONTEND_URL', 'http://localhost:3000')],

'allowed_origins_patterns' => [],

'allowed_headers' => ['*'],

'exposed_headers' => [],

'max_age' => 0,

'supports_credentials' => true

Session domains

Session cookies can only be shared between subdomains that exist within the same domain. In the case of a local application, since there are no subdomains unless we use some reverse proxy, applications are accessed via localhost:{{PORT}}. Therefore, we have to make sure that the session domain is localhost or 127.0.0.1 (using the IP or the localhost alias may or not work depending on the operating system and hosts configuration).

SESSION_DOMAIN=localhost

In production, it's important to use a dot before the domain so that all the subdomains are allowed. For example:

SESSION_DOMAIN=.example.com

Sanctum domains

Sanctum domains are the hosts or addresses from which it is allowed to access the sessions created by this means. Breeze also takes care of adding FRONTEND_URL to the domains list. The configuration looks like this:

// config/sanctum.php
'stateful' => explode(',', env('SANCTUM_STATEFUL_DOMAINS', sprintf(
    '%s%s%s',
    'localhost,localhost:3000,127.0.0.1,127.0.0.1:8000,::1',
    Sanctum::currentApplicationUrlWithPort(),
    env('FRONTEND_URL') ? ','.parse_url(env('FRONTEND_URL'), PHP_URL_HOST) : ''
))),

The reason behind using parse_url is to remove the http or https protocol from the frontend URL, since a domain is just the alias of an address, without including the communication protocol. parse_url(env('FRONTEND_URL'), PHP_URL_HOST) can be read this way: "Take this URL, FRONTEND_URL, and just keep the PHP_URL_HOST component, which is the host or URL address". This is a necessary process since FRONTEND_URL must include the protocol because that's how it's required by CORS configuration.

In production, it is advisable to eliminate all the local domains (localhost, 127.0.0.1), because it should only be possible to authenticate from non-local addresses.

Next.js

Note: App Router is used.

Here comes the fun part.

Environment variables

Initially, only the backend URL is needed. We'll call this variable NEXT_PUBLIC_BACKEND_URL. The NEXT_PUBLIC prefix is added so that the variable is available in client components, although it will also be used in the server.

# .env
NEXT_PUBLIC_BACKEND_URL=http://localhost:8000

We must not forget the http protocol because otherwise the URL will be interpreted as relative to the frontend project (as if it was a subfolder), and it won't work.

Constants definition

Several constants that will be used in differente parts of the application are defined for routes and URL parameters to determine what to do.

// lib/constants/index.ts
export const LOGIN_ROUTE = "/login";

// Expired session
export const EXPIRED_SESSION_PARAM = "expired_session";
export const EXPIRED_SESSION_ROUTE = `${LOGIN_ROUTE}?${EXPIRED_SESSION_PARAM}`;

axios configuration

I find it practical to use axios because of the facility it provides to create an instance with a configuration that includes a base URL, credentials support, the CSRF token and other predefined properties, and because of the interceptors that will be useful to handle authentication errors. This is the axios configuration that I use:

// lib/axios.ts
import { EXPIRED_SESSION_ROUTE, LOGIN_ROUTE } from "@/constants";
import axios, { AxiosError, AxiosInstance, AxiosResponse } from "axios";

const axiosInstance: AxiosInstance = axios.create({
  baseURL: process.env.NEXT_PUBLIC_BACKEND_URL,
  withCredentials: true,
  withXSRFToken: true,
  headers: {
    Accept: "application/json", // * Important so we don't get HTML responses
    "Content-Type": "application/json",
    "Cache-Control": "no-cache", // "Do not use cached content without validating with the server"
  }
});

// Add an interceptor to redirect to the login page if the server responds with a 401 (unauthorized)
axiosInstance.interceptors.response.use(
  (response: AxiosResponse) => response,
  (error: AxiosError) => {

    if (error.response?.status === 401) {
      if (typeof window !== "undefined" && window.location.pathname !== LOGIN_ROUTE) {
        // We're on the client side
        // It's important to check that we're not on the login page, otherwise we'll end up in an infinite loop
        // The server side redirects should be handled by a ServerSideRequestsManager class
        window.location.href = EXPIRED_SESSION_ROUTE;
      }
    }
    return Promise.reject(error);
  }
);

export default axiosInstance;

When does a 401 Unauthorized error happen? When the CSRF token is valid, but the session has already expired, or the domain isn't allowed by Sanctum. The expired session parameter will serve to identify if expiring the session is needed in the middleware. This way there's no need to create a new route to achieve this.

Managing session in client and server

Here are two parts: having the user's information available in client and server components, and knowing if the user is authenticated.

For the former, it is required to create our own cookie, since the cookies that Laravel provides don't guarantee a valid session because they can simply exist for making an API request. This cookie should be HttpOnly for secutiry reasons, so that it can be accessed from the client through an API Route Handler and from the server can be accessed directly through the cookies method that Next.js provides. From the client side, authenticated user's information will be preserved using a global state through React context.

This cookie will contain the authenticated user's information in a JSON Web Token (JWT) that will be created with a library that is compatible with the edge runtime that Next.js utilizes in the middleware, because if you try to access user's information from the middleware and that library uses an API not available in that runtime, an error would occur. The jose library is an excellent option for this purpose. The secret to encrypt and decrypt the JWT should be in an environment variable. For example:

JWT_SECRET=super_secret_key

Without including NEXT_PUBLIC because it's only needed server-side. For the second part, knowing if the user is authenticated, we simply need to check in the middleware if the cookie exists and validate its content through the utilized library to generate the JWT. If Role-Based Access Control (RBAC) is implemented, then the user should include the role and we should use it to determine where to redirect them to.

Sanctum cookies retrieval

It is important to retrieve the Sanctum cookies before login by making a GET request to the /sanctum/csrf-cookie route, as is mentioned in the docs. If this process is not done, you'll always receive a 419 Unknown status error with the message "CSRF token mismatch". After login, a request to /api/user has to be made to get the authenticated user's information and the new cookies that represent the session with the user already authenticated. This always applies when you want to renew a session. Otherwise, a 401 Unauthorized will be received.

Login

The login process is the following:

Retrieve Sanctum cookies
Log in to Laravel
Use the authenticated user to generate the cookie with the JWT (this is why we need Laravel to return the user's data)
Register the user in the global state
Redirect to homepage

Manual logout

If the user logs out voluntarily, then:

Log out in Laravel
Delete the cookie with the JWT (expire it)
Clear global state (set user to null or undefined)
Redirect to login page

Making requests from the server

This is, in my opinion, the most important section, since the secret for successful requests lies in request headers. To make requests from the server, regardless of the type, it is fundamental to send three headers: Referer, Cookie and X-XSRF-TOKEN. The first one, which is the origin of the request, must be the frontend URL. This is very important because this way a domain allowed by Sanctum is used and we wil avoid getting the 401 Unauthorized error. Therefore, there should be another environment variable, which will only be used server-side, called FRONTEND_URL:

FRONTEND_URL=http://localhost:3000

For the second header cookies must be retrieved and converted into a string. Not including the cookies is the same as not having a session, so we will get the same 401 Unauthorized error if we don't include them.

The third one is to specify the CSRF token as it's done in client-side requests. To get this value we simply access the XSRF-TOKEN cookie. Using axios, the example for a GET request should look like this:

import { cookies } from "next/headers";
import axiosInstance from "@/lib/axios";

const headers = {
  Referer: process.env.FRONTEND_URL,
  Cookie: cookies().toString(),
  "X-XSRF-TOKEN": cookies().get("XSRF-TOKEN")?.value as string
};

const response = await axiosInstance.get(url, { headers });

Making requests from the server

It is recommended to use Server Actions for mutations that perform the same logic that would be performed server-side.

Setting cookies after making requests from the server

Originally, Sanctum cookies are updated after every request client-side, so that the session remains valid. However, in the server, cookies are not magically set after receiving every response. This could be achieved if every server response was a NextResponse that includes that information.

Nevertheless, this option is hard to implement for two reasons: you can't directly type a NextResponse, you can just use a type guard that works at run time; a NextResponse represents the response of the server, so anything that comes after a NextResponse is received would be ignored and nothing but the content of this response would be rendered. Handling these subtleties adds complexity to server components.

Therefore, an easy option is to have a SetCookies client component that has a hidden input which takes care of making a request to the Next.js /api/user route, which in turn takes care of making a request to the Laravel /api/user route. Laravel response will be received by Next.js API Route Handler and when the response from this route reaches the SetCookies component, it will set the cookies in the browser because it's a client component. This component should be present in all the routes where cookie renewal is needed, so that placing it in a page header or a common layout is the best.

Cookies from the server response could be passed in an object to the SetCookies component and set them in the browser and avoid an extra request, however, this wouldn't allow for updating HttpOnly cookies if they exist.

Error handling in the server

Two common errors will be the 401 Unauthorized error and the 419 Unknown content error. When the first happens, it is necessary to redirect to the expired session route, which will be responsible for expiring the cookie with the JWT from the middleware and redirect to the login page. In this process we have to be careful about removing the expired session parameter so as not to cause an infinite redirection loop in the middleware. For the second error, the request must be retried after renewing the cookies by following the same process that is made when setting the cookies after a request server-side. After this, any other error can occur, but not the same.

In server components responsible for fetching the data and rendering it, there must be a component in charge of displaying the error. Because of this, and in general for a proper error handling, it is important to standardize Laravel API responses so as to be able to create generic methods and components that make requests and render the appropriate content. This process of standardizing is known as serializing, therefore, this response would be serializable.

Link to GitHub repository

The detailed implementation with an example of a page that fetches all the users paginated and the rest of the pages that Breeze provides can be found here.

Conclusion

Integrating Laravel Sanctum with Next.js SSR isn't an easy task at first. There are many subtleties and problems that I encountered while developing a project with these requirements, and I couldn't find solutions anywhere, not even in the official example of Laravel Breeze with Next.js. However, by understanding the important concepts and the role of each party involved, this integration can be greatly simplified, combining the best of both worlds.

I hope that with these key points and the repository that contains the example, you can achieve it. If you have questions or want to share something, leave it in the comments :)

Using Redis for Caching in Laravel: A Step-by-Step Guide

Carlos Talavera — Sun, 29 Sep 2024 21:48:48 +0000

Introduction

Laravel is, without fear of contradiction, the most popular PHP framework, and among the most popular within web development. Redis is, for its part, an in-memory database widely used for caching storage due to the fact that data is stored in key-value pairs, which makes its management easier. In this article we'll see how to set up Redis in a Laravel application and what is to be considered when handling cache keys.

Prerequisites

Make sure you have Redis installed on your computer. You can use Docker's official image, or install it directly on Windows, MacOS or Linux. In the case of Linux, it varies from distribution to distribution, however, the common thing is that it's available through the package manager of the operating system, usually under the name of redis or redis-cli. Once you confirm that it's installed and the connection works, let's see how to set it up in Laravel.

Installing Redis in Laravel

So far we have simply installed the Redis server in our computer, but we need to have a way to connect from a PHP application. For this there are two options, using phpredis, a PHP extension, or predis, a library. None is better than the other, they just have different objectives and scopes. phpredis has the advantage that it allows you to connect to Redis from any PHP project that is executed in that computer, whereas predis, being a library, only allows to connect from the projects where it's installed. In my case, I have experience with phpredis, so let's see how to install it.

Installing phpredis

The installation guide for several operating systems can be found here. Again, in Linux, if your distribution is not listed in the guide, my recommendation is to look in your distribution's documentation for the installation process. This process is often to install the package using the package manager and uncomment the extension(s) in the PHP configuration files.

Laravel configuration

The first thing we need to do is make sure that Redis configuration in config/database.php is the right one. It must look like this:

// config/database.php
'redis' => [
  'client' => env('REDIS_CLIENT', 'phpredis'),

  'options' => [
      'cluster' => env('REDIS_CLUSTER', 'redis'),
      'prefix' => env('REDIS_PREFIX', Str::slug(env('APP_NAME', 'laravel'), '_').'_database_'),
  ],

  'default' => [
      'url' => env('REDIS_URL'),
      'host' => env('REDIS_HOST', '127.0.0.1'),
      'username' => env('REDIS_USERNAME'),
      'password' => env('REDIS_PASSWORD'),
      'port' => env('REDIS_PORT', '6379'),
      'database' => env('REDIS_DB', '0'),
  ],

  'cache' => [
      'url' => env('REDIS_URL'),
      'host' => env('REDIS_HOST', '127.0.0.1'),
      'username' => env('REDIS_USERNAME'),
      'password' => env('REDIS_PASSWORD'),
      'port' => env('REDIS_PORT', '6379'),
      'database' => env('REDIS_CACHE_DB', '1'),
  ]
]

Then we must set the necessary environment variables to use Redis as a cache and connect. Here it is assumed that phpredis is used, that Redis is installed locally and not in a Docker container, that you left the default port when installing Redis, and that you didn't set up any password:

# .env
CACHE_STORE=redis
CACHE_PREFIX=laravel_cache

REDIS_CLIENT=phpredis
# For Docker, use the name of the service
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

REDIS_DB=0
REDIS_CACHE_DB=1

REDIS_URL is used when you want to specify the connection with a single URL, for example, tcp://127.0.0.1:6379?database=0. Otherwise it's needed to specify the rest of the fields so that Laravel forms this URL at the end and connects. On the other hand, the cache prefix is important because we'll have to use it when searching keys. In the case of REDIS_DB and REDIS_CACHE_DB, it's just a way to separate distinct databases depending on the purpose. The first one is the default one if Redis is used without specifying the database, while the second one only takes care of the cache.

Using Redis in Laravel

Once the configuration is ready, it's time to use Redis in our application. Laravel provides us a Illuminate\Support\Facades\Cache class as part of its facades to make all sorts of operations (if you didn't know, facade is a design pattern). It's important to note that when using these methods, it's not necessary to use the Redis prefix, since Laravel adds it automatically. The basic methods are presented below:

Get an element

use Illuminate\Support\Facades\Cache;

Cache::get('key'); // value or null

Check if a key exists

use Illuminate\Support\Facades\Cache;

if (Cache::has('key')) {
  // do something
}

Add or overwrite an element

The put method adds or overwrites a cache element, that is, if it doesn't exist it creates it, and if it exists it updates it.

use Illuminate\Support\Facades\Cache;

$minutes = 60; // 1 hour
Cache::put('key', 'value', $minutes);

As seen above, the time in minutes can be specified. If not specified, the element will persist until it is explicitly deleted.

Add several elements

use Illuminate\Support\Facades\Cache;

$minutes = 60; // 1 hour
Cache::putMany([
    'key1' => 'value1',
    'key2' => 'value2'
], $minutes);

Similar to put, with the difference that multiple elements are stored at once.

Add an element if it doesn't exist

use Illuminate\Support\Facades\Cache;

$minutes = 60; // 1 hour
Cache::add('key', 'value', $minutes);

Similar to put, with the difference that add only adds an element if it doesn't exist, so it doesn't overwrite the previous one if there is one.

Delete an element

use Illuminate\Support\Facades\Cache;

Cache::forget('key');

Clear the cache

use Illuminate\Support\Facades\Cache;

Cache::flush();

This method deletes all the cache elements, so it must be used with caution.

Get or add an element for a fixed time if it doesn't exist

The remember method is useful when getting or adding an element to the cache for a fixed time is needed if it doesn't exist yet, i. e., it doesn't overwrite and works like add. Besides this, its purpose is that by using a closure, complex operations can be done inside the function to determine the value to be obtained or added.

use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\DB;

$minutes = 60; // 1 hour
$value = Cache::remember('key', $minutes, function () {
    return DB::table('users')->get();
});

Get or add an element if it doesn't exist

use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\DB;

$value = Cache::rememberForever('key', function () {
    return DB::table('users')->get();
});

Similar to remember, with the difference that here no time is specified and the element persists until it is explicitly deleted.

Get and element and then delete it

use Illuminate\Support\Facades\Cache;

$value = Cache::pull('key');

This method obtains the value associated to the key, stores it on the $value variable and removes the element from the cache. Clearly, it must be used with care and always assigned to a variable so as not to lose the information. You can find more methods in the official docs.

Example of a pattern search

A common situation is that we need to search for all the keys that match a pattern, that contain a certain expression. To do this, the Cache facade is no longer used, but we use the Redis one directly, which provides more advanced methods as the ones that exist when interacting directly with the Redis server. Under the Redis syntax, an asterisk * means all. So, for example, if we want to obtain all the keys, the pattern would simply be *. Some bad examples would recommend to do the following:

use Illuminate\Support\Facades\Redis;

$found_keys = Redis::keys('*');

This would return us an array with all the keys that were found. If we wanted to get the values we would have to loop through this array and get every value using the same Redis facade, as following:

use Illuminate\Support\Facades\Redis;

$found_keys = Redis::keys('*');

// Get the values
foreach ($found_keys as $found_key) {
  $value = Redis::get($found_key);
  // Do something with the value
}

By this point you should have two questions: why is it bad to do this and why is Redis used instead of Cache to get the values. The latter is easier to answer, so I'll start there. Do you remember that I said that when using Cache Laravel handles the prefix automatically? Well, when the keys are obtained using Redis, these contain the prefix, so if we tried to find their value using Cache, it wouldn't work, since Laravel adds the prefix, but it doesn't detect if it already exists, so the result would be a key with the prefix duplicated.

Moving on to the other question, the issue with using the keys method is that it blocks the execution of the code while it searches for the keys, why? Because it gets all the keys at once, and if there are a lot, well, let's wait for it to end. So what you're doing is using PHP to operate over Redis records, that is, you're using a programming language to search between all the records of a database, instead of using the database itself to do this process. That will clearly be slower, and even more if we remember that PHP isn't a language designed for high performance applications and large volumes of data. So, what's the right approach?

In order to get Redis to do all the job instead of PHP, we have to use the scan method, which as its name mentions, scans the records and uses a cursor to have a reference of the last position where it searched for and that way it goes little by little, incrementally, moving between the keys. In other words, instead of obtaining all the keys at once, it gets a few of them and keeps looking. The same example, using scan, would look like this:

use Illuminate\Support\Facades\Redis;

$redis = Redis::connection('cache'); // Store the connection in a variable so as not to open multiple connections
$prefix = config('database.redis.options.prefix');

$cursor = null; // This is fundamental so as the scan method can loop through the records at least once
$pattern = "{$prefix}*"; // Important to include the prefix

$found_keys = [];

do {
    $response = $redis->scan($cursor, [
        'match' => $pattern,
        'count' => 300 // Adjust according to the maximum size of keys needed
    ]);

    if ($response === false) {
        break;
    }

    $cursor = $response[0];
    $results = $response[1];

    $found_keys = array_merge($found_keys, $results);
} while ($cursor !== 0); // The rule of the scan method is that it returns false once the cursor is 0

// Get the values
foreach ($found_keys as $found_key) {
  $value = $redis->get($found_key);
  // Do something with the value
}

As a bonus, let's say that we want to look for all the keys that start with test. For this, the pattern would simply be:

$pattern = "{$prefix}test*";

It's important to note the use of the asterisk because otherwise we would be searching for test exactly, and if it wasn't clear already, we must never use the keys method in production environments, we must always use scan. You can, of course, use keys locally, since it's easier to implement and you don't have much data nor a server on which the users depend, but when in production, the use of scan is mandatory.

Delete the keys using the scan method

Another common situation is that we need to search for the keys that match a pattern and then delete them. For this, the del method is available, which allows us to delete several keys at once, that is, the direct result of the scan method after each iteration. But here's a little detail, which took me hours to figure out at its time and this is my chance to say "You're welcome" so you don't lose your time too. For a reason unknown to me, the del method doesn't work if the keys include the prefix, so it must be deleted. By adjusting the previous example to remove the keys on each iteration, we have the following:

use Illuminate\Support\Facades\Redis;

$redis = Redis::connection('cache');
$prefix = config('database.redis.options.prefix');

$cursor = null;
$pattern = "{$prefix}*";

$found_keys = [];

do {
    $response = $redis->scan($cursor, [
        'match' => $pattern,
        'count' => 300
    ]);

    if ($response === false) {
        break;
    }

    $cursor = $response[0];
    $results = $response[1];

    // Delete the keys prefix (otherwise, they won't get deleted)
    $results = array_map(function ($key) use ($prefix) {
        return str_replace($prefix, '', $key);
    }, $results);

    if (count($results) > 0) {
        // Delete the keys found
        $redis->del($results);
    }
} while ($cursor !== 0);

Conclusion

Redis is a highly powerful in-memory database that can help us to implement caching mechanisms in our applications. By using it the right way, it can help to reduce response times by providing cached content instead of having to look for it in another database.

I hope you find this article useful and if you have questions or want to share something, leave it in the comments :)

Transforming API requests and responses in Laravel 11 - The easy way

Carlos Talavera — Tue, 14 May 2024 17:26:49 +0000

The problem

I've been working on an application using Next.js on the front-end and Laravel on the back-end as a traditional REST API. As you may know, snake_case is the naming convention for variable and function names in PHP, while camelCase is the naming convention in JavaScript. My database tables and columns use snake_case as well, so I stuck to that design.

A first approach: Laravel resources

I was already using Laravel resources to return clean API responses. For each API response we can specify each key using camelCase. Something like:

class ProductResource extends JsonResource
{
    /**
     * Transform the resource into an array.
     *
     * @return array<string, mixed>
     */
    public function toArray(Request $request): array
    {
        return [
            'id' => $this->id,
            'name' => $this->name,
            'price' => $this->price,
            'stock' => $this->stock,
            'category' => $this->category,
            'imageUrl' => $this->image_url,
            'salesCount' => $this->sales_count,
        ];
    }
}

While this is valid, it could be highly demanding for us to format every API response to camelCase, and even more when we have Eloquent relationships that we have to format too. We could also say "Well, let's create a BaseResource that extends the JsonResouce class, which formats everything to camelCase, and then have every resource class extend from there". It would be something like this:

class BaseResource extends JsonResource
{
    /**
     * Convert array keys from snake_case to camelCase.
     *
     * @param array $array
     * @return array
     */
    protected function toCamelCase($array)
    {
        $camelCaseArray = [];
        foreach ($array as $key => $value) {
            // Here we use the Str::camel() method from Laravel
            $camelKey = Str::camel($value);
            // Recursively convert nested arrays
            $camelCaseArray[$camelKey] = is_array($value) ? $this->toCamelCase($value) : $value;
        }
        return $camelCaseArray;
    }

    /**
     * Transform the resource into an array.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return array
     */
    public function toArray($request)
    {
        return $this->toCamelCase(parent::toArray($request));
    }
}

(Note the need for a recursive approach to deal with nested arrays).

That way, we have two scenarios: one where we simply extend from that class to display the visible fields from a table as they are, i. e., without any formatting for relationships or hidden fields excluded from the API response; and the second scenario where we do want to format our API response. The first case would look something like this:

class UserResource extends BaseResource
{
    // No need for anything in here
}

The second case would be the ProductResource class already showed, but with key differences: it preserves snake_case, extends the BaseResource class and implements the toCamelCase() method:

class ProductResource extends BaseResource
{
    /**
     * Transform the resource into an array.
     *
     * @return array<string, mixed>
     */
    public function toArray(Request $request): array
    {
        return $this->toCamelCase([
            'id' => $this->id,
            'name' => $this->name,
            'price' => $this->price,
            'stock' => $this->stock,
            'category' => $this->category,
            'image_url' => $this->image_url,
            'sales_count' => $this->sales_count,
        ]);
    }
}

That seems nice too. So, what's the catch? To me, there are two inconveniences: on one side, if we already have several resources we would have to change them all to extend BaseResource and use toCamelCase() where it applies; and on the other side, we should be really careful all the time while creating resources so they extend BaseResource and not JsonResource, and apply the conversion method if needed. We could modify the Artisan command for creating resources so they extend BaseResource instead of JsonResource. But all of that seems like too much work to me.

There's also one more thing, what if our API expects requests using snake_case? We could format API responses to camelCase, but we should format them back again to snake_case from our Next application. While Next supports server-side rendering, it doesn't sound like a good option to leave all that work to what is supposed to be the front-end. So, what can we do?

The solution: Laravel middlewares

To me, a middleware is basically something that intercepts traffic on a higher level and does stuff with it (I know it's vague, but why complicate things?). With higher level I mean that, unlike a proxy, a middleware does not work with a raw HTTP protocol, but does something with HTTP information already parsed.

What we want to achieve is to use an input middleware and an output middleware. One for "what we are receiving" and one for "what we are replying". We'll call the input one TransformApiRequest, so it handles the camelCase to snake_case conversion. The output one will be called TransformApiResponse, so it handles the snake_case to camelCase conversion. This way we keep our naming conventions within our Laravel application and just transform the information to the way we need it to be. Besides, all that transformation logic lives in the same place, making it easier to maintain.

Using Laravel 11, we create these middlewares as follows:

php artisan make:middleware TransformApiRequest
php artisan make:middleware TransformApiResponse

I'm not using Docker, so I'm not utilizing Laravel Sail. However, if you're using it, simply replace php with sail.

The TransformApiRequest middleware would look something like this:

class TransformApiRequest
{
    /**
     * Handle an incoming request.
     *
     * @param  \Closure(\Illuminate\Http\Request): (\Symfony\Component\HttpFoundation\Response)  $next
     */
    public function handle(Request $request, Closure $next)
    {
        // Transform keys of requests that are not GET to snake_case
        if ($request->method() !== 'GET') {
            $input = $request->all();
            $transformedInput = $this->transformKeysToSnakeCase($input);
            $request->replace($transformedInput);
        }

        return $next($request);
    }

    /**
     * Transform keys of an array to snake_case.
     *
     * @param  array  $input
     * @return array
     */
    private function transformKeysToSnakeCase($input)
    {
        $result = [];
        foreach ($input as $key => $value) {
            // Here we use the Str::snake() method from Laravel
            $snakeKey = Str::snake($key);
            $result[$snakeKey] = is_array($value) ? $this->transformKeysToSnakeCase($value) : $value;
        }
        return $result;
    }
}

In my case, I didn't want to convert GET requests with query parameters to snake_case because some of the parameters needed to stay in camelCase since I use (with no promotion intended) Laravel Purity for filtering. So, when it comes to Eloquent relationships, camelCase is the way to go. The other logic is self-explanatory.

As for the TransformApiResponse middleware, it's just a little bit more complex because we're not dealing with incoming requests, but with responses, so we need a way to identify when we need to format the response to camelCase. A clear condition is that the Content-Type header of our response must be application/json. But maybe we only want to transform successful responses, which makes the most sense to me, because, why would we have a complex error JSON response with keys long enough to be different in snake_case and camelCase? So let's consider that condition too. This middleware would look something like this:

class TransformApiResponse
{
    /**
     * Handle an incoming request.
     *
     * @param  \Closure(\Illuminate\Http\Request): (\Symfony\Component\HttpFoundation\Response)  $next
     */
    public function handle(Request $request, Closure $next)
    {
        $response = $next($request);

        // Transform keys of successful JSON responses to camelCase
        if ($response->isSuccessful() && $response->headers->get('Content-Type') === 'application/json') {
            $data = json_decode($response->getContent(), true);
            if ($data) {
                $transformedData = $this->transformKeysToCamelCase($data);
                $response->setContent(json_encode($transformedData));
            }
        }

        return $response;
    }

    /**
     * Transform keys of an array to camelCase.
     *
     * @param  array  $data
     * @return array
     */
    private function transformKeysToCamelCase($data)
    {
        $result = [];
        foreach ($data as $key => $value) {
            // Here we use the Str::camel() method from Laravel
            $camelKey = Str::camel($key);
            $result[$camelKey] = is_array($value) ? $this->transformKeysToCamelCase($value) : $value;
        }
        return $result;
    }
}

$response->isSuccessful() verifies that the response has a status code between 200 and 299. The other logic is self-explanatory.

Now we need to add these middlewares within our application. In Laravel 11, we go to bootstrap/app.php and locate the withMiddleware() method. As we're working on an API, we need to append these new middlewares to the api middleware group as follows:

->withMiddleware(function (Middleware $middleware) {
        // Transform keys of requests that are not GET to snake_case
        // and keys of successful JSON responses to camelCase
        $middleware->appendToGroup('api', [
            TransformApiRequest::class,
            TransformApiResponse::class,
        ]);
    })

That's it. With this approach, now we can keep developing using snake_case in Laravel and camelCase in Next.js seamlessly :)

"Drawbacks"

While it is true that the use of middlewares has an impact on performance, it is also true that we should keep API responses and requests as clean and short as possible. Thus, transforming information from snake_case to camelCase and vice versa should not be the culprit of a slow application.

Conclusions

Laravel is a great framework with a wide set of built-in features that make our life easier, but sometimes we have to decide which is the best way to go to reduce complexity and achieve our goals. In this case, it seemed that using Laravel resources would be a good option at first, but then, using custom middlewares turned out to be more sustainable and easier to implement.

This is my first article, so any feedback is well appreciated. I hope you liked it and found it useful :D