DEV Community: patrick0806

Why You Should Never Use a Random UUID as an Idempotency Key in Payment APIs

patrick0806 — Fri, 27 Jun 2025 14:33:32 +0000

Imagine you have a saas and your user clicks "Pay", but the network times out, so they hit the button again.

Your backend processes the same request twice.

💥 Result? Two charges. Angry user. Support ticket. Refund dance.

Recently, I started building a personal project using a monolithic architecture and integrated Stripe for billing. As expected, YouTube began recommending all sorts of payment integration videos.

One of them caught my attention — and nearly made me choke on my dinner.

In the video, the creator was integrating with Mercado Pago and explained the use of the X-Idempotency-Key header by saying:

"Just use randomUUID() from Node here. It just needs to be unique."

Seems harmless, right? But that one line can break the whole concept of idempotency especially in payment systems.

🧠 What Is Idempotency, Really?

Idempotency ensures that multiple identical requests only have one effect.

If the first request goes through and the second one is retried — whether due to a flaky network, user impatience, or frontend retry logic — the backend should return the same result, not perform the operation again.

✅ Example:

User tries to subscribe to your service.
You send a request to Mercado Pago → an invoice is created.
User refreshes the page and submits again.
If the request includes the same idempotency key, the same invoice is returned — no duplicate charge.

That’s the power of headers like:

X-Idempotency-Key: invoice-1234-user-5678

❌ The Problem with `UUID.randomUUID()`

If you generate a new UUID for each retry, the server can't detect that it's the same operation.

Each request looks completely unique.

So instead of being safe and idempotent, you get:

❌ First request → Charge created
❌ Second request → Another charge created
💣 Third request → Yep... you get the idea

✅ What You Should Do Instead

An idempotency key must be deterministic:

the same operation should always produce the same key.

You can use:

A combination of userId + invoiceId
A traceId or sessionId from the frontend
A fingerprint of the payload (e.g. hash of the JSON body)

Examples:

const key = "invoice-" + userId + "-" + invoiceId;

or something like

const key = sha256(JSON.stringify({
  userId: "1234",
  plan: "pro",
  price: "49.90"
}));

This ensures idempotency across retries, across network hops, even across frontend reloads.

🛡️ Backend Handling

On the server side, the logic is straightforward:

Receive the X-Idempotency-Key header

Check if that key already exists in storage

If yes → return the saved response

If no → process, store the response + key

Storage options:
Relational DB with unique constraint on the key

Redis with TTL

Distributed cache or NoSQL with atomic writes

Bonus tip: log the idempotency key with your trace logs to simplify debugging.

💡 Real-World Examples: Stripe & Mercado Pago

Both Stripe and Mercado Pago rely heavily on idempotency keys to avoid duplicate charges.

Their APIs require that you set this key once per operation, and they cache the result server-side.

If you change the key on each retry — like using a UUID.randomUUID() — you lose all protection.

🧵 Pro Tip: Where to Generate the Key?

Ideally, the client(frontend, api caller) should generate the key once per operation and persist it until it's confirmed successful.

If you use traceId or a sessionId, make sure it persists across retries (not regenerated).

On mobile apps, you can store it in local storage or memory.

The important thing is: same intent → same key.

📌 Final Thoughts

Idempotency isn't about "not crashing on retry" —
it's about not duplicating irreversible effects.

Random UUIDs are great for correlation IDs or primary keys —
but not for identifying business operations.

So next time you're building a billing integration or an API that creates side effects, ask yourself:

“What happens if this request is sent twice?”

And remember:

🧨 Random UUIDs ≠ Idempotency

💬 Have you ever seen this bug happen in production?

Or used UUID.randomUUID() without thinking twice?

Drop a comment below — let’s share some war stories 😅

Do you know the difference between Kafka and RabbitMQ... or did you just put it on your resume?

patrick0806 — Wed, 18 Jun 2025 14:29:09 +0000

Since last year, one of my responsibilities has been to interview those who apply for positions at the company they work for. What often happens is the following: many do not have resumes with tools like Kafka and RabbitMQ — which are present in most modern systems — but when I ask the classic question:

"What is the difference between these messaging services? And why did you use both?"

The answer almost always comes out as:

"I don't know, I just used them."
"They're all queues, right?"

💣 Spoiler: they're not.

If you really want to understand how these tools work and when to use each one, this article is for you. Let's talk about:

The difference between a queue and a stream
Why RabbitMQ is push-based and Kafka is pull-based
When to use each approach

What is a queue? (RabbitMQ):

A queue is a FIFO (First In, First Out) data structure. When we talk about messages, the flow looks like this:

Producer ➡️ Queue ➡️ Consumer

Or, in more detail:

[1] The producer sends a message to the queue
[2] The broker delivers that message to a consumer
[3] The message is removed from the queue after consumption

If processing fails, the message can be resent — usually through a dead-letter queue.

Features:

Guaranteed processing order (generally)
Single consumer per message
Transient storage

Examples of queue-based brokers:
RabbitMQ

Amazon SQS
Redis Streams (FIFO mode)

What is a stream? (Kafka)

A stream is an ordered, immutable record of events. Unlike a queue, messages are not discarded after consumption. Instead, the consumer reads the message from a given offset, and this log can be suspended for days or weeks (or indefinitely).

Typical flow:

Producer ➡️ Broker (log) ⬅️ Consumer

The consumer asks:

“Is there anything new for me after offset 128?”
And then he reads the message directly.

Features:

Immutability: messages are not deleted immediately
Configurable retention (e.g. 7 days by default in Kafka)
Multiple consumers can read the same message independently

Examples beyond Kafka:

Amazon Kinesis
Apache Pulsar
Redpanda

Push vs Pull: Who controls the pace?

RabbitMQ(push)
The broker pushes messages to consumers as soon as they are available.
✅ Lower latency
⚠️ Risk of overload if the consumer is not contagious
Kafka (pull)
The consumer pulls messages according to its own pace and offset.
✅ Easier reprocessing
⚠️ Require more control and logic on the consumer side

When to use each? RabbitMQ:

Guaranteed and immediate delivery
TTL or disposable message after consumption
Not ideal for:
- Reprocessing messages
- Multiple consumers reading the same data

When to use each? RabbitMQ:

Storing and reprocessing events
Multiple concurrent consumers
Processing large volumes with horizontal scalability
Implementing event sourcing or stream processing
Not ideal when:
- Each message must be processed only once and summarized
- You need advanced routing logic on the broker

Kafka ≠ Queue. This is the trick:
Kafka is not a queue.
Kafka is a distributed log with read control on the consumer.
RabbitMQ is a traditional message broker, based on delivery and removal.

🧠 Conclusion
Kafka and RabbitMQ solve different problems.
Using both is not wrong. Using them without understanding why is.
Kafka is about streaming, retention, performance and multiple consumers
RabbitMQ is about control, reliability and simplicity in routing
It is not enough to know how to use it.
Understand why.
📌 Messaging is an architecture, not a library.

💬 What about you?
Have you ever fallen into the trap of treating Kafka as a queue?
Have you ever had a project that used both... and didn't need either?
Tell us what you think, and share it with that friend who swears that Kafka is the best.

Monoliths aren't dead. You just forgot how they work.

patrick0806 — Fri, 13 Jun 2025 14:03:17 +0000

Over the past few years, I've worked with robust and complex architectures: microservices, Kubernetes, message queues, millions of requests per day. Naturally, when I started a new personal project, my mind went straight to:

Separate API and frontend
Different deployments
Observability, alerts, scalability from day 0

But is this the right path for an MVP?

The answer I found was: not necessarily.

A new experiment: less complexity, more delivery

For my new SaaS, I decided to try the opposite:

Use Next.js not only as a frontend, but taking advantage of its full stack capabilities
I centralized the logic in Server Actions
For checkout, I adopted Stripe Checkout out of the box, without reinventing the wheel
No queues, workers or distributed services — everything in a single deployment

Benefits I noticed

🚀 Fast delivery: less configuration, more code that matters
🧩 Simple maintenance: everything in one place
💡 Focus on the product, not on the infrastructure

And most importantly: I moved forward. I took the idea off the drawing board and started testing it with real users.

Conclusion

If scaling becomes a problem in the future, great — that's the kind of problem you want to have.

But until then, think twice before applying complex solutions to simple problems. Sophistication can wait. Delivery can’t.

Have you also experienced this when building your own projects? How did you find the balance between robustness and simplicity?

Big O Notation: A Simple Guide

patrick0806 — Tue, 29 Oct 2024 14:12:17 +0000

Big O Notation is a mathematical concept used to describe the performance or complexity of an algorithm in terms of time and space as the input size grows. It helps us understand how the runtime of an algorithm increases with larger inputs, allowing for a more standardized comparison of different algorithms.

Why Use Big O Notation?

When comparing algorithms, relying solely on execution time can be misleading. For example, one algorithm might process a massive dataset in one hour, while another takes four hours. However, the execution time can vary based on the machine and other running processes. Instead, we use Big O Notation to focus on the number of operations performed, which provides a more consistent measure of efficiency.

Example: Summing Numbers

Let’s explore two ways to calculate the sum of all numbers from 1 to n:

Option 1: Using a Loop

function addUpTo(n) {
    let total = 0;
    for (let i = 1; i <= n; i++) {
        total += i;
    }
    return total;
}

Option 2: Using a Formula

function addUpTo(n) {
    return n * (n + 1) / 2;
}

Analyzing the Complexity

In Option 1, if n is 100, the loop runs 100 times. In contrast, Option 2 always executes a fixed number of operations (multiplication, addition, and division). Thus:

Option 1 is O(n): The time complexity grows linearly with n.
Option 2 is O(1): The time complexity remains constant, regardless of the input size.

Disclaimer

While Option 2 involves three operations (multiplication, addition, division), we focus on the general trend in Big O analysis. Thus, instead of expressing it as O(3n), we simplify it to O(n). Similarly, O(n+10) simplifies to O(n), and O(n^2 + 5n + 8) simplifies to O(n^2). In Big O Notation, we consider the worst-case scenario, where the highest-order term has the greatest impact on performance.

There are other forms of notation beyond the common complexities listed above, such as logarithmic time complexity expressed as O(log n).

What Is Big O Notation?

Big O Notation allows us to formalize the growth of an algorithm’s runtime based on input size. Rather than focusing on specific operation counts, we categorize algorithms into broader classes including:

Constant Time: O(1) - The algorithm's performance does not change with the input size.
Linear Time: O(n) - The performance grows linearly with the input size.
Quadratic Time: O(n^2) - The performance grows quadratically as the input size increases.

Example of O(n^2)

Consider the following function, which prints all pairs of numbers from 0 to n:

function printAllPairs(n) {
    for (var i = 0; i < n; i++) {
        for (var j = 0; j < n; j++) {
            console.log(i, j);
        }
    }
}

In this case, the function has two nested loops, so when nnn increases, the number of operations increases quadratically. For n= 2, there are 4 operations, and for n=3, there are 9 operations, leading to O(n^2).

Another Example: Count Up and Down

function countUpAndDown(n) {
    console.log("Going up!");
    for (var i = 0; i < n; i++) {
        console.log(i);
    }
    console.log("At the top!\nGoing down...");
    for (var j = n - 1; j >= 0; j--) {
        console.log(j);
    }
    console.log("Back down. Bye!");
}

At first glance, one might think this is O(n^2) because it contains two loops. However, both loops run independently and scale linearly with n. Thus, the overall time complexity is O(n).

Simplifying the Analysis

Analyzing every aspect of code complexity can be complex, but some general rules can simplify things:

Arithmetic operations are considered constant time.
Variable assignments are constant time.
Accessing elements in an array (by index) or object (by key) is constant time.
For a loop, the complexity is the length of the loop multiplied by the complexity of what happens inside the loop.

Space Complexity

While we've focused on time complexity, it's also possible to calculate space (memory) complexity using Big O. Some people include input size in their calculations, but it’s often more useful to focus solely on the space required by the algorithm itself.

Rules for Space Complexity (based on JavaScript):

Most primitive values (booleans, numbers, etc.) are constant space.
Strings require O(n) space (where n is the string length).
Reference types (arrays, objects) are generally O(n), where n is the length of the array or the number of keys in the object.

An Example

function sum(arr) {
    let total = 0;
    for (let i = ; i < arr.length; i++){
        total += arr[i];
    }
    return total;
}

In this function, the space complexity is O(1) because we use a constant amount of space (two variables) regardless of the input size.

For a function that creates a new array:

function double(arr) {
    let newArr = [];
    for (let i = 0; i < arr.lenght; i++){
        newArr.push(2*arr[i]);
    }
    return newArr;
}

Here, the space complexity is O(n) because we allocate space for a new array that grows with the size of the input array.

Conclusion

Big O Notation provides a framework for analyzing the efficiency of algorithms in a way that is independent of hardware and specific implementation details. Understanding these concepts is crucial for developing efficient code, especially as data sizes grow. By focusing on how performance scales, developers can make informed choices about which algorithms to use in their applications.

Choosing the Best Messaging System: Practical Guide

patrick0806 — Mon, 27 May 2024 18:16:34 +0000

When it comes to communication between microservices, choosing the right messaging system is crucial. These systems guarantee the independence of services by storing events in a broker to be consumed when the services are available. However, with a variety of options on the market, such as Kafka, RabbitMQ and SQS, how do you decide which one to use? In this article, we'll explore the basics of queuing and the key differences between some of the major players.

Message Ordering

It is important to understand how messages are ordered in queuing systems. The most common methods are FIFO (First In, First Out) and LIFO (Last In, First Out). Additionally, some brokers offer priority queues, allowing important messages to be consumed first, regardless of the default order.

Types of Queues: Pull vs. Push

Another crucial aspect is the type of queue: Pull or Push. In a push queue, messages are automatically sent to consumers regardless of their status. This can lead to problems if consumers cannot process the volume of incoming messages. On the other hand, in a pull queue, consumers request new messages from the broker, ensuring that they can process them correctly, although this may be slower.

Difference between Messaging and Stream

Messaging enables asynchronous and reliable communication between systems, useful when message order is not critical and data does not need to be delivered in real time. On the other hand, streaming services deal with continuous streams of data in real time, maintaining the order of records. This is ideal for processing large volumes of data in real time where order is crucial.

Amazon SNS (simple notification service)

Advantages: Self-managed service that supports sending messages to multiple destinations, integrated with AWS services, facilitating the construction of cloud-based applications.

Disadvantages: May be more expensive for applications with high message load and may not offer granular control over message consistency.

Amazon SQS (simple queue service)

Advantages: Managed and fault-tolerant queuing service, with automatic replication of messages between clusters.

Disadvantages: Message size limit and possibility of receiving duplicate messages due to replication.

Redis

Advantages: Simple configuration and quick access to data due to its memory storage.

Disadvantages: Lack of guarantees on message delivery order and latency for larger messages.

RabbitMQ

Advantages: Granular control over message consistency, support for multiple protocols and messaging models such as pub/sub and FIFO ordering.

Disadvantages: Complex configuration for scalability beyond a high rate of requests per second.

Apache Kafka

Advantages: Highly scalable, fault tolerant and suitable for handling large volumes of data in real time.

Disadvantages: Complexity in configuration and lack of integrated tools for management and monitoring.

Conclusion

Choosing the right messaging system depends on the specific needs of your project. Consider factors such as scalability, consistency, cost, and configuration complexity when making your decision. Carefully evaluate each option and choose the one that best meets your system requirements.

Understanding Providers and Dependency Injection in NestJS

patrick0806 — Thu, 30 Mar 2023 18:53:54 +0000

NestJS is a Node.js framework that allows us to build scalable and well-structured web applications using service-oriented architecture approach. One of the core features of NestJS is dependency injection, which is a common design pattern in object-oriented applications that allows you to create and manage instances of objects within an application environment.

To use dependency injection in NestJS, it is necessary to create and configure service providers, which are responsible for managing and providing object instances to other application components. In this article, we'll explore the concepts of providers and dependency injection in NestJS, as well as show you how to create and use custom providers and share instances of providers between modules.

What are providers and why are they important in NestJS?

A provider is an object that provides an instance of a service to other application components. In other words, a provider is responsible for creating, managing, and providing instances of objects to other application components. Providers are important in NestJS because they allow the developer to create and manage services in a modular and reusable way, making it easier to maintain code and create automated tests.

Providers are created through classes that have the @Injectable() decorator and are registered in modules through the providers method. For example, suppose we want to create a service that performs user validation in our application. We can create an AuthService provider as follows:

import { Injectable } from '@nestjs/common';

@Injectable()
export class AuthService {
  validateUser(username: string, password: string): boolean {
    // Lógica de validação de usuário aqui
    return true;
  }
}

The AuthService class has the @Injectable() decorator, indicating that it can be injected into other application components. In addition, the class has a validateUser() method that implements user validation logic.

To use the AuthService provider in other application components, we need to register it in a module. This can be done as follows:

import { Module } from '@nestjs/common';
import { AuthService } from './auth.service';

@Module({
  providers: [AuthService],
})
export class AuthModule {}

The AuthModule module registers the AuthService provider in the providers array, indicating that it can be injected into other application components that depend on that service.

Dependency injection in NestJS

Dependency injection is a design pattern that allows objects to be created and managed within an application environment. In NestJS, dependency injection is used to provide instances of services to other application components.

To inject a service into an application component, you must use the @Inject() annotation. For example, suppose we want to inject the AuthService provider into a controller that handles user authentication. We can do this as follows:

import { Controller, Post, Body } from '@nestjs/common';
import { AuthService } from './auth.service';

@Controller('auth')
export class AuthController {
constructor(private authService: AuthService) {}

@Post('login')
async login(@Body() body) {
const { username, password } = body;
const isValid = await this.authService.validateUser(username, password);
        if (!isValid) {
        throw new BadRequestException('Invalid credentials');
        }
        // JWT token generation logic here
    }
}

In the AuthController class, we use the constructor to inject the EmailService provider, indicating that this service is necessary so that the class can send registration confirmation emails.

Sharing provider instances between modules

To share the same instance of a provider across multiple application modules, you need to import the module containing the provider into all modules that want to use that provider. This can be done as follows:

import { Module } from '@nestjs/common';
import { EmailModule } from './email.module';
import { AuthModule } from './auth.module';

@Module({
   imports: [EmailModule, AuthModule],
})
export class AppModule {}

In the example above, the module AppModule imports the modules EmailModule and AuthModule, which contain the providers EmailService and *AuthService *, respectively. That way, all instances of these providers share the same dependency injection scope.

It is important to note that when sharing the same instance of a provider across multiple modules, care must be taken to avoid concurrency issues. For example, if multiple controllers modify the state of a provider simultaneously, problems with data inconsistency can occur. Therefore, it is recommended that providers be designed to be thread-safe, that is, to support concurrent access by multiple threads without generating data consistency problems.

Conclusion

In summary, providers and dependency injection are important features of NestJS that allow you to create modular, flexible and scalable applications. Using providers, we can encapsulate the application's business logic in independent, reusable components, which can be transparently injected into other components. Additionally, dependency injection allows us to automatically manage dependencies between application components, reducing code complexity and making maintenance and testing easier.

What is OAuth2 ?

patrick0806 — Sat, 15 Oct 2022 12:51:52 +0000

OAuth2 is an authorization framework that allows applications — such as Google, Facebook, and GitHub — to gain limited access to user accounts over an HTTP service. It works by delegating user authentication to the service that hosts a user account and authorizing third-party applications to access that user account. OAuth2 provides authorization flows for web and desktop applications as well as mobile devices.

You must have already used a button that says “Log in with your google account” when you were using some other application to avoid having to do all the registration by hand. In this case you are giving permission to this third-party application to use the resources of your application, in the example cited by Google, these applications have limited access to your information through the HTTP protocol.

Roles

Resource Owner: Person or entity that allows access to your data.
Client: It is the application that interacts with the Resource Owner, such as the browser, speaking in the case of a web application.
Resource Serve: The API that is exposed on the internet and needs data protection. To gain access to information, a token is required, which is issued by the authorization server.
Authorization Server: Responsible for authenticating the user and issuing access tokens, it is the one who has the resource owner information (the user), authenticates and interacts with the user after the client is identified.

How works ?

In the image above we can see how the authorization flow usually works:

Authorization Request: In this part, the client (application) requests authorization to access the user's server resources.
Authorization Grant: If the user authorizes the application, he receives an authorization grant.
Authorization Granting: The client requests an access token from the authorization server (API) by authenticating its own identity and granting authorization.
Access token: If the application's identity is authenticated and the authorization grant is valid, the authorization server issues an access token to the application. The client will already have an access token to manage and the authorization at this stage is already complete.
Access Token: When the client needs to request a resource from the resource server, just present the access token.
Protected resource: The resource server provides the resource to the client if its access token is valid.

The authorization server is responsible for SSO (Single Sign On), which centralizes user access credentials and authenticates, manages user permissions and issues access tokens.

The client (application that runs on the user's machine) is defined through two types of application:

Confidential: clients who are able to maintain the confidentiality of their credentials.
Public : who are unable to maintain the confidentiality of their credentials

Continuing with the authorization flows, there are 4 ways to work with this integration:

Implicit - is a simplified authorization flow, optimized for web clients. When issuing an access token, the authorization server does not authenticate the client. It is widely used in SPAs and MVC applications.
Authorization Code - is achieved by using an authorization server as an intermediary between the client and the user. The client redirects the user to an authorization server. This type of client is used in third-party applications, that is, untrusted.
Resource Owner Password Credentials - used when the customer requests the username and password directly, which is already used in so-called trusted applications, such as the company's own applications.
Client Credentials - can be used when the client application is protected, which are used in system integrations.

What is Apache Kafka

patrick0806 — Sun, 25 Sep 2022 14:21:07 +0000

Recently I had to mess with Kafka in my work, it's something I've never done and I had some difficulty understanding, so I'm thinking of bringing a series of posts about it.
In this first post I want to give a little introduction about what Kafka is and how it works

What is Kafka?

Apache Kafka is an open-source, high-performance, real-time messaging platform. It stands out for being extremely fast and scalable, it is widely used with microservices.

After this more technical description let's go to what it actually does, in today's world we have systems communicating with each other all the time, but this may not always be the best option.

Let's imagine that I have a System A and a System B, if system A sends a message and system B is down, this message will be lost, so that doesn't happen, we put an intermediary for this communication that stores and sends these messages when system B comes back.

Important terms

When we talk about Kafka we have some terms that we use, and without understanding them it would be difficult to understand how it works, so here comes a list explaining these terms:

Broker: in computing, a broker is the server for sending messages, it is the one who triggers and receives the messages and it is he who owns the topics and partitions
Topics: a topic is an identifier, Through this identifier it is possible to connect with the broker and send or receive messages. (For me this guy is basically like the “database table” is where our data is)
Microservices: Microservices are a software architecture model that aims to separate a system into several smaller systems to improve performance and availability.
Partition: Subdivision of a topic, partition is a resource for load balancing
Cluster: In short, a cluster is a set of brokers and it contains the servers and the main instance of Kafka.

How does Kafka work ?

Kafka was written in Java and Scala, it performs data transmission asynchronously. In its structure, Kafka has consumers and producers.

Producers are those who send and distribute the data, while consumers are those who subscribe to a topic and listen to the messages that will arrive.

The Kafka Architecture described above allows for consistency in sending messages. Brokers are designed to withstand outages and failures, when a broker goes down and stays out for some reason, a backup broker takes over the activities and maintains delivery and availability without losing any information, the same thing goes for topics that have multiple partitions that are replicas of the primary. These replicas are often scattered on other machines.

Another very interesting thing about Kafka is that unlike some other messaging systems, even after the consumer reads the message, it is not thrown away, so if we have a new consumer who wanted to read the data from the beginning, he can, but of course, if desired, it is possible to configure the time this data will be available before being deleted.

Final considerations

Apache Kafka is really a fantastic system for you to be able to work with messaging tools, including working with Pub/Sub, for example.

Therefore, everyone reads a channel and a producer produces there on that channel, that is, in this topic everyone can read these messages.

If you are thinking of some solution for you to make your system communicate securely and efficiently and you still need to process these messages Apache Kafka is a great solution for you to consider.

Clean Code where to start

patrick0806 — Fri, 08 Jul 2022 00:35:44 +0000

Recently I started to read Clean Code, it is a well-known book in our area in which Uncle Bob tries to give us what he considers clean code, that is, a simple code to read and also to maintain.

In this article I want to focus on the first three chapters of the book where he talks about variables and functions. But this seems so common, that maybe you think if just paying attention to these two points can really improve the quality of my code?

The answer is yes and a lot, if we think carefully about the names of our variables and those names will be clear and will tell you what values are stored there and help in our understanding of what is going on in the code.

With an easier reading and understanding of the code, it is also easier to understand where to move and what to change, thus also helping in the maintainability of the software.

See an example with bad variable names:

const fn = "Patrick";
const yb = 2019;
const ln = "Nicezi";

console.log(fn+" "+ ln + " nasceu em" + yb);
// Result Patrick Nicezi was born in 1998

Now let's see the same example with well-named variables:

const firstName = "Patrick";
const yearOfBirth = "2019";
const lastName = "Nicezi"; 

console.log(firstName +" "+lastname+" nasceu em" + yearOfBirth);
// Result Patrick Nicezi was born in 1998

As you can see, the second one is much easier to understand because each variable says exactly what it stores and when it is used in conjunction with others it is much easier to understand what is happening. And this choice of names applies to everything you name during development like class names, functions...

But not only giving a good name to the variable gives a clear naming pattern it's also important to create a naming pattern, it helps a lot the next person who reads your code to understand it. For example:

function alterUser(){...};
function changeAddress(){...};
function modifyUserDate(){....};

When reading the code above, although I know that they are all functions that change an object, I still wonder if they have the same purpose, because with the different names I feel that they are doing different things

function updateUser(){...}
function updateAddress(){...}
function updateUserDate(){...}

Now in code with a naming pattern we can clearly see just by reading the function name what their purpose is and that they are similar purposes, and with this pattern it is much easier for someone who has never read a code to know what any function that starts with update does.

Speaking of functions, we have some very important things to focus on when creating one, the first one a function must do only one thing and the second it must not be too big, because apart from making it difficult to read if the function is very large it probably does more than one thing.

See an example of this:

function returnFormatedProducts(products){
    products.map(product =>{
    let amountOfPassengers;
        let adults = 0;
     let childrens = 0;

    if(product.type === 'CRUISE'){
        adults = cruiser.persons.adults;
        childrens = cruiser.persons.children + cruiser.persons.infants;
            amountOfPassengers = {adults,childrens};
    }else if(product.type === 'HOTEL'){
     const passengersPerRoom = hotel.rooms.map(room => {
                let childrensInRoom = 0;
        let adultsInRoom = 0;
         passengers.forEach(passenger => {
              if (passenger.type === 'ADULT') {
                adults++;
              } else {
                childrens++;
              }

          return {adults,childrens};
        });

        amountOfPassengers = passengersPerRoom.reduce(
          (totalPassengers, passengersInRoom) => {
            return {
              adults: (totalPassengers.adults += passengersInRoom.adults),
              childrens: (totalPassengers.childrens += passengersInRoom.childrens),
            };
          },
          { adults: 0, childrens: 0 },
        );
    }else{
        passengers.forEach(passenger => {
          if (passenger.type === 'ADULT') {
            adults++;
          } else {
            childrens++;
          }
        });
      amountOfPassengers = {adults,childrens};
    }

    return{
          sellDate:product.sellDate,
      route: product.route,
      startDate: product.startDate,
      endDate: product.endDate,
      price: product.price.replace('$', 'R$ '),
      paxChd: `${amountOfPassengers.adults} / ${amountOfPassengers.childrens}`,
    }
  });
}

This code becomes much clearer when we separate this large function into smaller functions and each with their own responsibility it becomes clear what the function does just by reading its name.

function returnFormatedProducts(products){
    products.map(product =>{
    const amountOfPassengers = this.getPassengersAmount(product);

    return{
          sellDate:product.sellDate,
      route: product.route,
      startDate: product.startDate,
      endDate: product.endDate,
      price: product.price.replace('$', 'R$ '),
      paxChd: `${amountOfPassengers.adults} / ${amountOfPassengers.childrens}`,
    }
  });
}

function getPassengersAmount(product) {
    if (product.type === "CRUISE") {
      return getPassengersFromCruiser(product);
    }

    if (product.type === "HOTEL") {
      return getPassengersFromHotel(product);
    }
    return countPassengers(product.passengers);
  }

function getPassengersFromCruiser(cruiser) {
    const adults = cruiser.persons.adults;
    const childrens = cruiser.persons.children + cruiser.persons.infants;
    return {
      adults,
      childrens,
    };
  }

  function getPassengersFromHotel(hotel) {
    const passengersPerRoom = hotel.rooms.map(room => {
      return this.countPassengers(room.passengers);
    });

    const amountOfPassengers = passengersPerRoom.reduce(
      (totalPassengers, passengersInRoom) => {
        return {
          adults: (totalPassengers.adults += passengersInRoom.adults),
          childrens: (totalPassengers.childrens += passengersInRoom.childrens),
        };
      },
      { adults: 0, childrens: 0 },
    );
    return amountOfPassengers;
  }

With this little code refactoring we can read it more smoothly, when we see the returnFormatedProduct function, we can understand what it does and if we need more details on how the number of passengers are taken, we can look at the specific functions for that.

And if you ever need to add a new shape or change an existing one, it won't impact the code as a whole and can be easily changed.

Conclusion

Writing clean code is a matter of practice, training and paying attention to the small details. It's an ongoing process, don't be afraid to refactor your code and rename things if you find better names for them.

Como começar a aprender programação

patrick0806 — Fri, 24 Dec 2021 19:22:46 +0000

Quando comecei a aprender programação me senti perdido sobre a enxurrada de conhecimento que eu tinha que absorver, e também a ordem em que eu deveria aprender as coisas.

Então agora uns anos depois estou escrevendo esse artigo no intuito de tentar ajudar alguém que esteja começando a como ele pode começar a aprender e até apresentar alguns materiais ou aulas que podem ajudar. Vou me ater a conteúdos em português por questão de facilidade para quem está iniciando.

Nesse artigo eu vou focar nas duas coisas que precisamos aprender para conseguir continuar os nossos estudos sem ficarmos batendo cabeça por ter pulado uma parte da base.

Logica de Programação

A primeira coisa que precisamos para aprender programação é aprender lógica de programação, qual a utilidade dela ?

Podemos descrever o computador como "burro" ele faz apenas oque é dito explicitamente para ele, a lógica de programação é a organização coesa de uma sequência de instruções voltadas à resolução de um problema, ou à criação de um software ou aplicação. Ela é a base porque é a partir dele que os aprendizados posteriores, como por exemplo o das linguagens de programação, fará sentido.

Para aprender logica de programação aconselho o material do Canal Curso em Vídeo sobre o tema.

Escolher uma linguagem de programação

Após isso o próximo passo seria escolher uma área de estudo como Front-end, Back-end ou mobile, a partir disso escolher uma linguagem de programação e aprende-la. Mas independente da área escolhida, eu aprenderia o javascript pois ele é quase uma bala de prata é possível usa-lo em qualquer uma das áreas embora nem sempre o ideal. Com ele você pode aprender todos os conceitos que necessita.

E após aprender esses conceitos trocar para outra linguagem especifica se necessário se torna muito mais simples, porque tirando a sintaxe que é como escrevemos o código em determinada linguagem os conceitos, são em grande parte reaproveitados por todas as linguagens, o curso em video também tem um otimo curso sobre javascript.

Eu diria que esses são os dois pontos principais para um iniciante aprender, após eles você já deve ser capaz de ver com qual área tem mais afinidade e deseja trabalhar, e assim filtrar e pesquisar coisas mais focadas com área que deseja trabalhar.

DEV Community: patrick0806

Why You Should Never Use a Random UUID as an Idempotency Key in Payment APIs

🧠 What Is Idempotency, Really?

✅ Example:

❌ The Problem with UUID.randomUUID()

✅ What You Should Do Instead

You can use:

Examples:

🛡️ Backend Handling

💡 Real-World Examples: Stripe & Mercado Pago

🧵 Pro Tip: Where to Generate the Key?

📌 Final Thoughts

Do you know the difference between Kafka and RabbitMQ... or did you just put it on your resume?

What is a queue? (RabbitMQ):

What is a stream? (Kafka)

Push vs Pull: Who controls the pace?

When to use each? RabbitMQ:

When to use each? RabbitMQ:

Monoliths aren't dead. You just forgot how they work.

A new experiment: less complexity, more delivery

Benefits I noticed

Conclusion

Big O Notation: A Simple Guide

Why Use Big O Notation?

Example: Summing Numbers

Option 1: Using a Loop

Option 2: Using a Formula

Analyzing the Complexity

Disclaimer

What Is Big O Notation?

Example of O(n^2)

Another Example: Count Up and Down

Simplifying the Analysis

Space Complexity

Rules for Space Complexity (based on JavaScript):

Conclusion

Choosing the Best Messaging System: Practical Guide

Message Ordering

Types of Queues: Pull vs. Push

Difference between Messaging and Stream

Amazon SNS (simple notification service)

Amazon SQS (simple queue service)

Redis

RabbitMQ

Apache Kafka

Conclusion

Understanding Providers and Dependency Injection in NestJS

What are providers and why are they important in NestJS?

Dependency injection in NestJS

Sharing provider instances between modules

Conclusion

What is OAuth2 ?

Roles

How works ?

What is Apache Kafka

What is Kafka?

Important terms

How does Kafka work ?

Final considerations

Clean Code where to start

Conclusion

Como começar a aprender programação

❌ The Problem with `UUID.randomUUID()`