DEV Community: Samuel Pires

Estruturando endpoints de forma sucinta e direta.

Samuel Pires — Mon, 02 Jun 2025 13:33:27 +0000

No artigo de hoje, vamos falar sobre uma prática da qual eu já fui vítima, e você, leitor, provavelmente também já foi (ou ainda está sendo).

Trata-se da famigerada prática de criar endpoints excessivamente verbosos. Quando estamos desenvolvendo uma API REST para nosso sistema, é comum tentarmos facilitar o acesso a dados muito específicos. No entanto, isso muitas vezes se transforma em uma bola de neve.

Quem nunca se pegou pensando: “Só mais um endpoint e tudo estará resolvido”... e repetiu isso incontáveis vezes?

Isso acontece porque ignoramos um fator muito importante no conceito de API: ela deve servir como um portal de acesso aos recursos gerais do sistema, e não como um grande servidor repleto de rotas altamente específicas para cada situação.

Esse problema costuma surgir, principalmente, quando lidamos com recursos que estão relacionados entre si.

Pense na seguinte situação:

Você precisa listar usuários que possuem tarefas atribuídas. A abordagem comum e tentadora é criar um endpoint como:

/getUsersWithTasks

Mas esse tipo de design fere princípios fundamentais de uma API bem construída. Em vez disso, pense na sua API como uma interface para recursos, e usuários são um recurso. Logo, uma forma mais adequada e escalável seria algo como:

/users?withTasks=true

Esse formato segue o padrão REST, é mais flexível e permite expandir facilmente os filtros no futuro, como:

/users?withTasks=true&active=true

Dicas gerais

Evite criar endpoints com verbos como get, delete ou create. Além de quebrar os princípios REST, isso torna sua API redundante e desnecessariamente verbosa. Por exemplo:

🚫 /getUserById
✅ /users/:id

Além disso:

Prefira filtros via query parameters em vez de encher a URL com parâmetros.

Mantenha seus endpoints focados em recursos, não em ações.

Seguindo essas dicas simples, sua API se tornará muito mais limpa, intuitiva, escalável e fácil de manter.

Filas e Microserviços, como e quando implementar.

Samuel Pires — Fri, 30 May 2025 13:21:52 +0000

Quando estamos começando no mundo do desenvolvimento backend, logo percebemos que nem tudo é um grande CRUD. Principalmente para atravessar a ponte entre o nível Júnior e Pleno, precisamos aprender alguns conceitos novos — e um deles são os "Microserviços" e as "Filas".

Um problema que notei é que boa parte do conteúdo sobre esse assunto, muitas vezes, utiliza jargões difíceis que podem acabar limitando o aprendizado de alguém que nunca teve contato com esse tipo de material.

Para mim, por muito tempo, microserviços nada mais eram do que simplesmente “serviços pequenos” (seja lá o que isso quisesse dizer). Mensageria? Eu não fazia ideia. Kafka? Só conhecia o escritor...

Para começar a desmistificar esses assuntos, vamos primeiro entender quando microserviços e filas são necessários.

Imagine que você tem um grande sistema de API para um banco — um sistema responsável por TUDO o que o banco faz, escalando infinitamente. Como no print abaixo.

Processamento, onde os microserviços começam a fazer sentido.

Agora, imagine que todo tipo de transação dentro dessa API está fadada a competir por processamento com todos os outros recursos do sistema. Para fazer um depósito, eu preciso "disputar espaço" com outro usuário tentando solicitar um empréstimo — e o meu depósito só será processado depois que o empréstimo dele for concluído, e assim por diante.

Se o seu banco tem, talvez, mil clientes, pode até ser que tudo funcione bem. Mas e quando esses números crescerem? Um grande número de pessoas tentando fazer depósitos pode afetar diretamente a experiência de um único usuário que só quer fazer uma transferência.

Ou algo pior pode acontecer: imagine que algo muito sério aconteça e todo o seu sistema seja derrubado. Agora, nenhum cliente consegue acessar nada — nem fazer depósitos, nem empréstimos. O banco, literalmente, caiu por completo.

Para resolver esse problema em um sistema monolítico, seríamos obrigados a escalar o sistema como um todo para ganhar mais performance. Mas... e se existisse uma forma de escalar apenas um módulo específico sob demanda?
É aí que os microserviços se tornam realmente úteis.

A arquitetura de microserviços consiste em termos todos os módulos do nosso sistema desacoplados uns dos outros. Nesse caso, deixamos de ter uma única API com todos os endpoints possíveis, e passamos a ter várias "micro" APIs, cada uma responsável por um módulo individual e hospedada de forma independente.

Dito isso, poderiamos ter algo parecido com o print abaixo.

No modelo representado acima, nossos sistemas estariam desacoplados e independentes uns dos outros. Uma instabilidade no sistema de pagamentos não geraria conflito no sistema de empréstimos, e vice-versa.

O papel das filas

Filas trabalham lado a lado com microserviços, e o motivo disso é que, agora, como temos múltiplos serviços desacoplados, precisamos de um meio sólido para manter a consistência dos dados comunicados entre um e outro.

É completamente possível ter microserviços se comunicando via HTTP normalmente (ou por algum outro protocolo interno). Porém, isso pode ser um problema devido à concorrência entre requisições, e à chamada "race condition" — uma vulnerabilidade já bem conhecida que pode causar problemas, principalmente em sistemas com alto volume de leitura e escrita de dados.

Sobre race condition

Suponhamos que um cliente tente fazer uma transferência para outro várias vezes e tenhamos a seguinte situação:

Cliente A possui R$ 40,00 em conta.
Cliente A paga R$ 30,00 para o Cliente B.
Cliente A paga R$ 30,00 para o Cliente B novamente.

O que deveria acontecer?

A primeira transferência leria o saldo atual de A (R$ 40,00) e seria realizada normalmente.
Como estamos trabalhando com microserviços, o serviço de pagamentos receberia essa ordem e iniciaria o processo de pagamento. Porém, devido à latência do banco de dados, a transferência demora mais do que deveria — e o Cliente A, vendo que seu saldo não foi alterado, tenta realizar o pagamento novamente.

E quando menos se espera, o Cliente A se encontra com –R$ 20,00, e o Cliente B com R$ 60,00.

Uma situação completamente errada e inesperada.

Mas como isso aconteceu?

Aqui temos um caso do que chamamos de race condition, onde duas requisições quase simultâneas leem o mesmo dado no mesmo estado, ao mesmo tempo.

Como a primeira tentativa de pagamento estava com atraso, a segunda tentativa leu o banco de dados antes que a primeira fosse concluída.
Portanto, ela entendeu que o Cliente A ainda tinha os R$ 40,00 de saldo original — e enviou uma segunda ordem de pagamento.

E se tivéssemos uma forma de enfileirar as requisições e tornar o processo totalmente síncrono, garantindo que uma ordem so seria processada assim que outra ordem anterior fosse totalmente completa?

Conseguimos fazer isso implementando um sistema de filas/mensageria, voce ja deve ter ouvido nomes muito famosos como RabbitMQ ou Apache Kafka, ou Amazon SQS.

Como filas e mensagerias funcionam

Os modelos mais comuns de sistemas de filas seguem o padrão "produtor e consumidor".

Mas o que isso significa?

Basicamente, um sistema "produz" uma mensagem em uma fila, contendo qualquer dado necessário (por exemplo, um JSON), e outro sistema "consome" essa mensagem, retirando-a da fila e processando o conteúdo, ou em casos de erro, retornando a mesma para o final da fila original (isso e opcional de sistema para sistema).

Solucionando o problema

Veja como no exemplo abaixo da situacao que descrevemos.

Aqui, não teríamos o problema de dois pagamentos sendo processados ao mesmo tempo, já que o segundo seria, obrigatoriamente, processado apenas após o término do primeiro.

Isso permite que você controle a frequência do fluxo de leitura de pagamentos, evitando sobrecarga no sistema e mantendo a consistência total dos dados.

Sistemas modernos de filas permitem configurar múltiplas filas para diferentes "assuntos", possibilitando o processamento simultâneo de dados não relacionados, sem conflitos. Eles também permitem ajustar o tempo e a forma como cada processamento deve ocorrer. Às vezes, você pode querer ler 10 mensagens ao mesmo tempo ou executar leituras agendadas em lotes. Tudo isso é configurável nos sistemas de filas mais populares.

Como vimos, microserviços e filas não são conceitos místicos nem “coisas de empresa grande” — são ferramentas que ajudam a manter nossos sistemas mais organizados, performáticos e preparados para crescer.

Aprender isso é uma das chaves para sair do modo CRUD e começar a pensar como engenheiro de software: buscando soluções escaláveis e resilientes.

Se você chegou até aqui, espero que esse conteúdo tenha te ajudado a enxergar esse mundo com menos mistério e mais clareza.

Projetos Pessoais de forma realista: Como retomei a pratica de programação e destravei

Samuel Pires — Tue, 01 Apr 2025 13:55:09 +0000

O Inicio

Durante a carreira do Dev médio, ja é tido como uma certeza de que o estudo é algo crucial para a própria evolução, sendo sua pratica independente da sua atuação profissional ou não na area.
Porém uma outra grande certeza que temos e que nem sempre temos a criatividade e motivação para ir atrás de novos projetos, linguagens e conceitos.
Eu, como uma pessoa extremamente ansiosa, vivia martelando essa ideia em minha cabeça, de que deveria ter "projetos pessoais" como todos dizem. Aquelas ideias super bem estruturadas, com milhões de conceitos e regras, enfim, ja e de se esperar que nada saia do papel, e pra piorar, isso so me deixava mais desmotivado ainda.

Realidade

Este texto e uma reflexão de como eu consegui destravar esse processo pra mim, e talvez, você leitor consiga fazer o mesmo.
Então acho importante compartilhar algumas realidades que podem ser libertadoras.

1 - Você não ira produzir nada grandioso, e isso é bom.

Com grande poderes, vem grandes responsabilidades, e o que buscamos aqui é apenas estudar, não lançar a próxima startup milionária ou SaaS com faturamento recorde.
Se você e ansioso como eu, sabe bem que somente de contemplar a ideia de um projeto pessoal dessa magnitude ja vai fazer a sua cabeça ferver, e o processo para desenvolver sera mais doloroso do que benéfico.

2 - Foque em conceitos isolados, não em estruturas completas

Um dos grandes impeditivos que eu tinha era sobre estudar tentando implementar estruturas e projetos do começo ao fim, e isso acabava por minar minha motivação logo de cara, pois no primeiro obstaculo, todo o processo ja era desfalcado e eu não sentia que estava fazendo a coisa certa.
A ideia aqui e focar em conceitos, você não precisa fazer um projeto fullstack de ponta a ponta, comece aos poucos.
Estude tudo de forma isolada, quer aprender sobre Oauth? Crie um projeto cuja única ideia é voce conseguir fazer login utilizando Google por exemplo, esqueça css, esqueça rotas, esqueça todo o resto, e por ai vai, isso pode se aplicar a qualquer conceito ou tecnologia que voce esteja querendo aprender.
Inúmeras vezes ja criei um projeto para estudar sobre autenticação e vi que gastei um bom tempo pensando no banco de dados que iria utilizar, na estrutura de pastas, quando vi o foco ja tinha se perdido.

3 - Ser realista

Atrelado ao conceito anterior, vem a ideia também de entender a sua realidade, e o que realmente significa o estudo para você.
Tenha sempre essa ideia na cabeça, seu "projetinho" não precisa ir pra produção, e se for, não terá mais que 3 usuários (que você mesmo criou para teste).
Entender bem isso vai aliviar, e muito, a tensão na hora de pensar em fazer qualquer projeto para estudo.
Você não precisa implementar o melhor banco de dados, a melhor estrutura de serviços e arquitetura de projetos, a não ser que seu estudo seja focado exclusivamente nisso, e novamente, se for, todo o resto deve ser o mais simplório possível.

A primeira aplicação

Ultimamente venho estudando muito NestJS, assim como autenticação, sempre foi um assunto extremamente complicado para mim, portanto desenvolvi, tentando ao maximo utilizar os conceitos acima, um pequeno template que consiste em uma aplicação NestJS que possui apenas duas rotas, login, e logout, e uma rota protegida que funciona apenas para usuários logados.

Um projeto totalmente básico, sem nenhuma intenção ou regra complexa, direto ao ponto.

O projeto se encontra aqui caso você queira dar uma olhada.

Somente nesse pequeno tempo estudando (pouco mais de uma hora)
consegui exercitar conceitos que não tinha dominio antes como:

O conceito de guards no nestjs
Criação de decorators customizados
Implementação da biblioteca Passport para autenticação

Proximos desafios

Agora o maior desafio não é mais a pratica, e sim a consistencia da mesma.
Tentarei ao maximo trazer pequenas partes deste estudo para ca, e compor explicações de conceitos que ja tenho bastante pratica para devs menos experientes.

Linters and Formatters: How code reads our code.

Samuel Pires — Tue, 30 May 2023 15:20:04 +0000

Throughout all my journey as a software engineer, I've always hoped in and out of different topics and questions, OOP or Functional?, Static or Dynamic Types? But one thing always seemed sure. I, and every other programmer that I knew liked a good-looking code, and I don't mean in a functional way, I'm talking about the visual part.

Identations, blank lines here and there, double and single quotes, and a bunch of other rules and styles make our code more readable and concise. And thanks to tools like auto-formatters and Linters, we can save ourselves the hustle of pressing tab once (or twice if you are a psycho) at the start of each line or things like that.

We all know what those linters and formatters are, but something that I got interested in the last weeks was HOW they worked, how exactly they read our code and sometimes can even fix some of our errors by themselves.

So in this little article, I'll guide you through a simple and general explanation of how a code formatter work, these rules can change but in most cases apply to the majority of linters and formatters out there.

1 - Abstract Syntax Tree

Abstract Syntax Tree, or AST for short, is known as a visual representation of our code structure, it doesn't know anything about how our code works or what it does, it consists in organizing each part of our code into "branches" of a tree-like structure, or even json which I will be using for further examples for better understanding.

For example lets take this simple Javascript function.

function sum(a, b) {
    return a + b;
}

Lets use AST explorer to generate the AST for this function block, it will look something like this.

{
  "type": "Program",
  "start": 0,
  "end": 34,
  "body": [
    {
      "type": "FunctionDeclaration",
      "start": 0,
      "end": 34,
      "id": {
        "type": "Identifier",
        "start": 9,
        "end": 12,
        "name": "sum"
      },
      "expression": false,
      "generator": false,
      "async": false,
      "params": [
        {
          "type": "Identifier",
          "start": 13,
          "end": 14,
          "name": "a"
        },
        {
          "type": "Identifier",
          "start": 16,
          "end": 17,
          "name": "b"
        }
      ],
      "body": {
        "type": "BlockStatement",
        "start": 18,
        "end": 34,
        "body": [
          {
            "type": "ReturnStatement",
            "start": 21,
            "end": 32,
            "argument": {
              "type": "BinaryExpression",
              "start": 28,
              "end": 31,
              "left": {
                "type": "Identifier",
                "start": 28,
                "end": 29,
                "name": "a"
              },
              "operator": "+",
              "right": {
                "type": "Identifier",
                "start": 30,
                "end": 31,
                "name": "b"
              }
            }
          }
        ]
      }
    }
  ],
  "sourceType": "module"
}

Yes, those 3 lines of code generated this monster of a JSON, but dont panic, lets go through slowly and you'll see that its actually very simple.

2 - Traversing the tree

First, we have our type which is "program", followed by an indication of where is the start and end of our script which can be like a "coordinate" of where that character is, and blank spaces count and tabs count differently here, but the most important part of all of this is the "body", is basically where all our code is.

Inside the body, we will see an array containing again the same pattern, a type, a start and end, another body, and so on.

Each "block" of our code resides inside the "body" of another block, and each type of code block may have some specific properties like for example let's pick only the function declaration.

"type": "FunctionDeclaration",
      "start": 0,
      "end": 34,
      "id": {
        "type": "Identifier",
        "start": 9,
        "end": 12,
        "name": "sum"
      },
      "expression": false,
      "generator": false,
      "async": false,
      "params": [
        {
          "type": "Identifier",
          "start": 13,
          "end": 14,
          "name": "a"
        },
        {
          "type": "Identifier",
          "start": 16,
          "end": 17,
          "name": "b"
        }
      ],

We see a FunctionDeclaration type, followed by a property of the type Identifier wish contains the function name, then we have expression, generator, and async wish are boolean values, followed by an array of params, that have each function parameter contained in its object, again with type Identifier, its name, and its "coordinates".

We can use this system to read through every block of our code, and we can already start to have an Idea of how the formatters and linters can apply rules to it.

3 - Applying changes through AST

Now let us take a look at the fun part of all of this. Knowing exactly where every statement starts and ends, where every variable is, and every function name and parameter, linters will read the AST and can generate a warning based on the reading. Let's see some examples:

Unused variables / functions / imports

The linter goes through the AST storing the name for every VariableDeclaration Identifier in a temporary Array, now every time it finds this same identifier's name on the rest of the code, it will pop that entry out of the array, when it gets to the end of it, the linter loops through all the remaining items and generates the "Unused variable" warning in your console since it never got out of the array, it means that it was never called anywhere in the code. The same process happens with function declarations and function calls, as well as imports in javascript.

Formatting

When it comes to formatting its also very straightforward, the formatting tool can read through our AST and find the exact position of every character, it can increment or decrement the "start" and "end" values to manipulate the number of blank spaces or tabs that your code will have.

Conclusion

I hope that with this article I could deliver some cool information about this topic that isn't discussed as much in our community I find it very interesting, and I also hope that you could learn something new here.

Feel free to follow me here and on my socials for more tech talk and articles like this one!

Why I think prisma is unbeatable.

Samuel Pires — Wed, 15 Feb 2023 00:01:11 +0000

Throughout my NodeJS journey as a full-stack developer, I've been in contact with many ORMs and Query builders, dealing with databases was always a real pain for me, especially when the actual tooling around most of the ORMs is not clear enough.

And for almost a year now, I've been using what I think is the best ORM available for NodeJS which is Prisma. It is one of the most complete tools for database manipulation that I have ever seen, and I'll be listing some things about it, and hopefully, encourage people to try it out.

Modeling your database with code

Prisma uses a schema file to define your database, so you can write your entire database out of it, without needing to use an abstraction of some kind like classes or decorators, just a simples "model" and Prisma can generate your database with ease. It can also read your already-built database, and extract the models from it, build a schema file that matches the database.

An example would be something like this:

   model User {
     id    Int     @id @default(autoincrement())
    email String  @unique
    name  String?
    posts Post[]
  }

  model Post {
   id        Int     @id @default(autoincrement())
   title     String
   content   String?
   published Boolean @default(false)
   author    User    @relation(fields: [authorId], references[id])
   authorId  Int
 }

With this model, you can easily generate a database with two tables, that have relations between them, and in a more "code" fashion, easily understandable.

Automatic client and type generation

Prisma uses a custom client to manage your database queries, which means that each Prisma project has its client built in differently, the client is generated after every database migration that you do, keeping its types matching the schema file.

Prisma also generates a base type definition for every table, so you also don't need to create different type files like DTOs for your application, and use it directly imported from Prisma.

Query Batching

Prisma automatically batches its queries, making it easy to deal with N+1 problems in graphql for example, without the need for additional tools or building custom dataloaders.

Prisma studio

This one is what I think is the coolest feature among the others, and it differentiates Prisma from other libraries.

When using Prisma, you can easily run a CLI command called "prisma studio", and it will read your schema file, and spin up a browser-based database managing toll, making it possible to read all your tables, add and remove content from them, and watch over them in real-time when testing.

For more information and very good documentation about it, just visit prisma.io and try it yourself, Prisma also has many implementations and automation which I didn't mention in this post.

If you like this type of content, feel free to follow me on social media and here on Dev.to, I always try to write about a cool thing that I'm using at the moment on my projects.

Zod - Validate your API inputs with ease

Samuel Pires — Tue, 13 Dec 2022 23:56:25 +0000

Zod is a Typescript library that allows you to validate the shape and type of your data using various utility functions and statically infer types for it.

It got a lot of hype in the last months, already surpassing millions of downloads on npm.

In this little article, I'm gonna show it to you how you can use the Zod library to validade your api request body input, in this example I'll be using Express, but the concept can be applied to any other framework that you like.

Implementation

To use Zod we first have to import it as such

import { z } from 'zod'

And now we can use it to create a "schema", a Zod schema is a variable that will hold the shape of our data, for example, lets create a basic input for creating a user, that we want to use to validate our user creation before calling our database handler.


export const createUserInput = z.object({
  name: z.string(),
  age: z.number(),
  email: z.string().email(),
});

As you can see, we are using 4 different types of zod utilities, first we call "object" wich states that the data will come in a object format, and inside of it, we can declare all the object properties, followed by its correspondent types like "string" or "number"

And notice that we also have helpers that can be called after the type function, such as "email" to validate an specific format for given data.

Other validations could also be "optional" and "nullable".

And now, we can use this zod schema to validate our api input, like the example below.

app.post('/createUser', (req: Request, res: Response) => {
  try {
    const data = createUserInput.parse(req.body);

    // send the now validated data to your service / database handler

    return res.send({
      data,
      message: 'Input validated!!',
    });
  } catch (error) {
    if (error instanceof ZodError) {
      return res.send(error);
    }
    return res.status(500).send({
      message: 'unknown error...',
    });
  }
});

The const "data" that returns from the parse function, contains the data of our object already validated and type safe, so you can safely pass it to your database functions and process the data.

If the parse function fails to validate one or more fields, it will throw a "ZodError" wich we will check in a catch block, and send it as a response to the user.

Zod errors have the following shape:

{
    "issues": [
        {
            "validation": "email",
            "code": "invalid_string",
            "message": "Invalid email",
            "path": [
                "email"
            ]
        }
    ],
    "name": "ZodError"
}

In the above example we directly return this error to the client, but in a real situation we could use a parser function to the error, to properly format into a useful message to the front end for example.

Bonus - Static type inference

The cherry on top is that zod schemas also work for type inference, so there is no need for a custom DTO class or anything like that.

So as we create our schema, we can also export a type from it, like so.

export type createUserInputType = z.infer<typeof createUserInput>;

The above example will output the exact type:

type createUserInputType = {
    name: string;
    age: number;
    email: string;
}

Docs and references

For more references and documentation about all the zod utilities, checkout their github repo

And also check this working example of the above implementation here

I hope this article was useful for you, feel free to follow me on my socials and GitHub too. Thanks for the reading!

The productivity dilemma

Samuel Pires — Fri, 09 Dec 2022 19:29:17 +0000

I'll start this article by just saying that the tools that you use do not define how smart you are, and here are my thoughts on that.

I'm in the tech field for almost two years now and always faced this constant internal battle in my head, about using the best tools possible to do my job and be "productive", because of this nonstop sense of "being smart".

As a very "environment driven" person, seeing people use those insane Vim configurations and be super fast with their keystrokes and code editing, using the most riced arch installation possible always drove me insane, I wanted that, it felt powerful, it felt easier to do things and more fun...

Every developer that I saw that fit those patterns felt like the image below.

It didn't take much time for me to start being overwhelmed by the feeling that I needed something like that for me to actually look like a awesome developer.

But turns out that the more time passed, I felt even worse, I didn't feel "hyperproductive" and even felt dumb in a sense...

It took too much time to configure a cool environment using things like Vim, minimalist window managers, Arch Linux, and stuff. And every once in a while, things kept breaking and I had to start all over again.

That demotivated me a lot, why wasn't I capable of being that 100x developer with insane hotkeys and Vim motions all the way? Where was the so-called "productivity"?

Recently I Acquired a new MacBook and thus I took the personal mission to do the complete opposite since the macOS cannot be overly customized, I decided to stuck with the most basic things that I could to focus on my job.

Whit this article I hope I was able to tell a cool story about myself as a professional developer and also motivate people that felt just like me in the tech area, you don't need that insane setup, the most incredible Vim configuration, it's okay to use your mouse.

We just need to feel good and make things work, no matter the tool.

"Boreout", being sick of not improving.

Samuel Pires — Fri, 21 Oct 2022 17:51:24 +0000

In recent times, it has become more and more common to hear about "Burnout" syndrome. Especially in the tech industry, we see a lot of already experienced developers that are exhausted, and already out of their limits when it comes to working.

And we also see a lot of solutions for this type of situation, people are already all over it and fighting this problem.

But, what about when the situation is the complete opposite?

I'm a beginner software developer with nearly one and a half years in the field, and I've constantly faced what I like to call the "Boreout" syndrome.

I feel that being a beginner, I have a lot of energy to spend, and think like a newborn child, it needs to be in constant movement, it is a completely blank paper ready to absorb experiences from other people and other things.

Speaking in "tech terms", it is fundamental to spend this useful energy from a beginner when it comes to solving problems and building new things. And I feel that companies often miss this point.

At least for me, this lack of internal motivation at work and just having to do boring things that don't make me feel that I'm going forward drives me into a very uncomfortable state. I'm feeling exhausted, doing less...

There is this constant feeling that I'm losing the "Good times" which is exactly when you are just starting at something, being stuck in places that don't actually will help you improve, and then, time passes and you are still just a junior when you should be ready to evolve to more senior roles.

I've always wanted to know what exactly could be the solutions for this type of situation, how we use 100% of our potential as beginners, and make sure that we get prepared for more challenging tasks in the future when they come.