Forem: Bruno Caxias

Simplifying Design Patterns : Singleton

Bruno Caxias — Mon, 14 Apr 2025 16:49:58 +0000

Introduction

Design patterns are proven solutions to common software design problems. In this article, we’ll simplify the Singleton pattern—explaining how it works, when to use it, and how to implement it with clear examples. The examples are inspired by Refactoring Guru and Dive Into Design Patterns (Alexander Shvets), distilled to their essence.

How Does the Singleton Pattern Work?

The Singleton is a creational design pattern that ensures a class has only one instance and provides a global access point to it.

Example Scenario: A Restaurant Kitchen

Imagine a restaurant where:

There is a kitchen that needs only one oven for every dish
Instead of starting a new oven every time a dish is cooked, the kitchen reuses the existing one.
If the oven isn’t on yet, it gets started once. After that, every dish uses the same oven.

Everytime a dish is about to be cooked and the oven is called to start, it must check if it is already instantiated, if it is then the instance is returned if not the constructor must be called.

When to Use the Singleton Pattern?

Use this pattern when:

You have a class in your program that should just have one single instance available, like a database object.
You need strict control over global variables

How to Implement the Singleton Pattern

Step-by-Step (Restaurant Example)

Define a Private Static Instance
- The class holds its only instance in a private static field:
```
 private static Oven _instance;  
```

Lock the Constructor

Make the constructor private to block external instantiation:

 private Oven()  
 {  
     IsOn = false; // Initialization logic  
 }

Create a Controlled Access Method

Provide a public static method (GetInstance) with lazy initialization:

 public static Oven GetInstance()  
 {  
     if (_instance == null)  
     {  
         _instance = new Oven(); // Creates instance only on first call  
     }  
     return _instance;  
 }

Add Thread Safety (Optional)

For multi-threaded kitchens, use lock or Lazy<T>:

 private static readonly object _lock = new object();  
 // ...  
 lock (_lock)  
 {  
     if (_instance == null) _instance = new Oven();  
 }

Modern Approach: Use Lazy<T> (Recommended)

Replace manual checks with C#'s built-in lazy initialization:

 private static readonly Lazy<Oven> _lazyOven = new Lazy<Oven>(() => new Oven());  
 public static Oven Instance => _lazyOven.Value;

Diagram

Simplifying Design Patterns : Prototype

Bruno Caxias — Fri, 11 Apr 2025 20:48:27 +0000

Introduction

Design patterns are proven solutions to common software design problems. In this article, we’ll simplify the Prototype pattern—explaining how it works, when to use it, and how to implement it with clear examples. The examples are inspired by Refactoring Guru and Dive Into Design Patterns (Alexander Shvets), distilled to their essence.

How Does the Prototype Pattern Work?

The Prototype is a creational design pattern that allows you to create copies of existing objects without making your code dependent on their concrete classes. This is useful when object creation is costly or complex (e.g., when objects have private fields or require deep copying).

Example Scenario: A Restaurant Kitchen

Imagine a restaurant where:

You have a Pasta object that you want to duplicate (e.g., for a new order).
Some of its properties might be private or require complex initialization (e.g., ingredients, cooking time).
Instead of manually reconstructing the object (which could introduce errors or tight coupling), you:
- Define a Prototype interface with a method like clone().
- Make the Pasta class implement this interface, providing its own concrete cloning logic (e.g., shallow or deep copy).
Now, the kitchen (client code) can simply call pasta.clone() to get an identical copy without knowing the internal details of the Pasta class.

When to Use the Prototype?

Use this pattern when:

Your code is not supposed to depend on concrete classes of objects you need to copy
You want to reduce the amount of subclasses that only differ in the way they are initialized

How to Implement the Prototype Pattern in C#

Step-by-Step (Restaurant Example)

1. Define the Cloning Interface or Method

Option A: Create an IPrototype interface.

  public interface IPrototype<T> {
      T Clone();
  }

Option B: Add Clone() directly to an existing hierarchy.

  public abstract class Dish {
      public abstract Dish Clone();
  }

2. Implement the Copying Logic

Option A: Use a copy constructor.

  public class Pasta : IPrototype<Pasta> {
      public string Type { get; set; }
      public List<string> Ingredients { get; set; }

      // Copy constructor
      public Pasta(Pasta source) {
          this.Type = source.Type;
          this.Ingredients = new List<string>(source.Ingredients); // Deep copy
      }

      public Pasta Clone() {
          return new Pasta(this); // Invokes copy constructor
      }
  }

Option B: Manual field copying (e.g., for languages without copy constructors).

  public class Pasta : IPrototype<Pasta> {
      public string Type { get; set; }
      public List<string> Ingredients { get; set; }

      public Pasta Clone() {
          return new Pasta() {
              Type = this.Type,
              Ingredients = new List<string>(this.Ingredients) // Deep copy
          };
      }
  }

3. Implement the `Clone()` Method

Ensure the method returns the concrete type (avoid polymorphism issues).

  // Correct (returns SpicyPasta):
  public new SpicyPasta Clone() {
      return new SpicyPasta(this);
  }

Avoid this (risky downcasting):

  // Warning: Returns Pasta when cast to IPrototype<Pasta>
  public override Pasta Clone() {
      return new SpicyPasta(this);
  }

Factory Method vs. Prototype in C#

Factory Method:

  public abstract class Kitchen {
      public abstract Dish PrepareDish();
  }

  public class PastaKitchen : Kitchen {
      public override Dish PrepareDish() {
          return new Pasta(); // Creates from scratch
      }
  }

Prototype:

  Pasta prototype = new Pasta { Type = "Carbonara" };
  Pasta order1 = prototype.Clone(); // Copies existing object

Diagram

Simplifying Design Patterns : Builder

Bruno Caxias — Thu, 10 Apr 2025 01:56:35 +0000

Introduction

Design patterns are proven solutions to common software design problems. In this article, we’ll simplify the Builder pattern—explaining how it works, when to use it, and how to implement it with clear examples. The examples are inspired by Refactoring Guru and Dive Into Design Patterns (Alexander Shvets), distilled to their essence.

How Does the Builder Pattern Work?

The Builder Pattern is a creational design pattern that separates the construction of a complex object into step-by-step processes. This allows the same construction logic to create different representations of an object while avoiding overly complex constructors.

Example Scenario: A Restaurant Kitchen

Imagine a restaurant kitchen where:

All pasta dishes follow a base preparation flow: boiling pasta, preparing sauce, adding garnishes, and serving.
Some pastas require extra steps (e.g., adding cheese, spices, or special toppings), but the core process remains consistent.
Without the Builder Pattern, a Pasta class would need a massive constructor with many parameters (most unused in most cases), leading to messy code and null defaults.
Define a PastaBuilder interface with methods for each construction step (e.g., setPastaType(), addSauce(), addGarnish()).
Implement concrete builders (e.g., SpaghettiBuilder, AlfredoBuilder) to handle variations.
Introduce a Director (e.g., the head chef) to enforce standardized recipes (e.g., "Vegetarian Pasta" or "Spicy Arrabbiata") by executing predefined steps.
Clients (or chefs) can either use the Director for preconfigured dishes, or Customize dishes directly via the Builder for flexibility.

When to Use the Builder?

Use this pattern when:

You have enormous constructors
You want different representations of the same product
You are working with complex objects that can be constructed with steps

How to Implement the Builder

Step-by-Step (Restaurant Example)

Define the product by creating a Pasta class with properties (type, sauce, garnish, etc.)

   public class Pasta 
   {
       public string Type { get; set; }
       public string Sauce { get; set; }
       public string Garnish { get; set; }
       public bool HasCheese { get; set; }
   }

Create a interface builder declaring methods for each construction step (SetPastaType, AddSauce, etc.)

   public interface IPastaBuilder 
   {
       void SetPastaType(string type);
       void AddSauce(string sauce);
       void AddGarnish(string garnish);
       void AddCheese(bool hasCheese);
       Pasta GetPasta();
   }

Now implement concrete builders for each of the dishes, like SpaghettiBuilder that implement the builder

   public class SpaghettiBuilder : IPastaBuilder
   {
       private Pasta _pasta = new Pasta();

       public void SetPastaType(string type) => _pasta.Type = type;
       public void AddSauce(string sauce) => _pasta.Sauce = sauce;
       public void AddGarnish(string garnish) => _pasta.Garnish = garnish;
       public void AddCheese(bool hasCheese) => _pasta.HasCheese = hasCheese;
       public Pasta GetPasta() => _pasta;
   }

Create a director to coordinate the calling of those step methods and what parameters must be sent to them

   public class Chef
   {
       private IPastaBuilder _builder;

       public Chef(IPastaBuilder builder) => _builder = builder;

       public void MakeMargheritaPasta()
       {
           _builder.SetPastaType("Spaghetti");
           _builder.AddSauce("Tomato");
           _builder.AddGarnish("Basil");
           _builder.AddCheese(true);
       }
   }

In your client code instatiate a concrete builder and a director, passing the builder to the director for it to create the dish you want

   var builder = new SpaghettiBuilder();
   var chef = new Chef(builder);

   // Standard recipe
   chef.MakeMargheritaPasta();
   Pasta margherita = builder.GetPasta();

   // Custom order (without Director)
   var customBuilder = new SpaghettiBuilder();
   customBuilder.SetPastaType("Penne");
   customBuilder.AddSauce("Alfredo");
   Pasta customPasta = customBuilder.GetPasta();

Diagram

Simplifying Design Patterns : Abstract Factory

Bruno Caxias — Tue, 08 Apr 2025 23:25:12 +0000

Introduction

Design patterns are proven solutions to common software design problems. In this article, we'll simplify the Abstract Factory pattern—explaining how it creates object families, when to use it, and how to implement it with kitchen-themed examples. Inspired by Refactoring Guru and Dive Into Design Patterns (Alexander Shvets).

How Does the Abstract Factory Work?

The Abstract Factory is a creational design pattern that produces families of related objects without specifying their concrete classes.

Key Characteristics

Creates multiple product types (e.g., Pizza + Pasta + Burger)
Ensures created objects are compatible (all Italian or all Mexican)
Uses composition over inheritance (factories are injected)

Example Scenario: Restaurant Kitchen

Imagine a kitchen that needs:

Multiple dish types (Pizzas, Pastas, Burgers)
Multiple cuisines (Italian, American, Mexican)

Instead of:

// ❌ Hardcoded kitchen (brittle)  
class Kitchen {  
    Pizza makeItalianPizza() {...}  
    Pasta makeAmericanPasta() {...} // Mixed cuisines!  
}

We use:

// ✅ Abstract Factory solution  
interface CuisineFactory {  
    Pizza createPizza();  
    Pasta createPasta();  
}  

class ItalianFactory implements CuisineFactory {  
    Pizza createPizza() { return new MargheritaPizza(); }  
    Pasta createPasta() { return new AlfredoPasta(); }  
}

When to Use Abstract Factory?

Use this pattern when:

Working with object families – Your system needs groups of related products (e.g., GUI components, cuisine sets)
Enforcing compatibility – Objects must work together (no "Italian Pizza + Mexican Pasta")
Switching configurations – You need to change entire product families at runtime

How to Implement Abstract Factory

Step-by-Step (Restaurant Example)

Define Product Interfaces

   interface Pizza { void bake(); }  
   interface Pasta { void boil(); }

Create Concrete Products

   class MargheritaPizza implements Pizza {  
       @Override void bake() {  
           System.out.println("Baking thin-crust pizza");  
       }  
   }

Declare Abstract Factory

   interface CuisineFactory {  
       Pizza createPizza();  
       Pasta createPasta();  
   }

Implement Factories per Cuisine

   class MexicanFactory implements CuisineFactory {  
       @Override  
       Pizza createPizza() { return new TacoPizza(); }  

       @Override  
       Pasta createPasta() { return new ChipotlePasta(); }  
   }

Use in Client Code

   class Kitchen {  
       private final CuisineFactory factory;  

       Kitchen(CuisineFactory factory) {  
           this.factory = factory;  
       }  

       void prepareMeal() {  
           Pizza p = factory.createPizza();  
           p.bake();  
       }  
   }  

   // Usage:  
   Kitchen italianKitchen = new Kitchen(new ItalianFactory());

Extend with Variants (Optional)

   Pizza createPizza(PizzaStyle style) {  
       return switch(style) {  
           case NEAPOLITAN -> new NeapolitanPizza();  
           case SICILIAN -> new SicilianPizza();  
       };  
   }

Why Avoid Hardcoding Factories?

// ❌ Problematic approach  
class Kitchen {  
    Pizza makeItalianPizza() {...}  
    Pasta makeMexicanPasta() {...}  
    Burger makeAmericanBurger() {...}  
}

Issues:

Mixed cuisines create incompatible meals
Adding new cuisines requires modifying Kitchen
Violates Single Responsibility Principle

Diagram

The client (Kitchen) works with factories and products only through interfaces.

Key Takeaways

✅ Ensures compatibility – All objects belong to the same family

✅ Simplifies swapping – Change entire themes by switching factories

✅ Follows Open/Closed – Add new families without modifying code

Use Abstract Factory when you need coordinated object families with clean separation of concerns!

Simplifying Design Patterns : Factory Method

Bruno Caxias — Mon, 07 Apr 2025 19:57:40 +0000

Introduction

Design patterns are proven solutions to common software design problems. In this article, we’ll simplify the Factory Method pattern—explaining how it works, when to use it, and how to implement it with clear examples. The examples are inspired by Refactoring Guru and Dive Into Design Patterns (Alexander Shvets), distilled to their essence.

How Does the Factory Method Work?

The Factory Method is a creational design pattern that provides an interface for creating objects in a superclass while allowing subclasses to alter the type of objects created.

Example Scenario: A Restaurant Kitchen

Imagine a restaurant where:

The Kitchen class defines how dishes are made.
Each dish (e.g., Pizza, Burger, Pasta) follows a common Dish interface with methods like prepare().
Instead of hardcoding dish creation, the Kitchen delegates instantiation to subclasses (PizzaStation, BurgerStation).

This way, adding a new dish (e.g., Taco) doesn’t require modifying the Kitchen—just creating a new subclass.

When to Use the Factory Method?

Use this pattern when:

You don’t know object types beforehand – The exact class of objects (e.g., dishes) isn’t known until runtime.
You want extensibility – Users of your library/framework should be able to add new types (e.g., new dishes) without changing existing code.
You need object reuse – Avoid rebuilding objects by caching and reusing them (e.g., reusing a preconfigured Pizza object).

How to Implement the Factory Method

Step-by-Step (Restaurant Example)

Define a Common Interface
- All dishes implement a Dish interface with shared methods (e.g., prepare(), cook()).
Create the Base Factory (Kitchen)
- The Kitchen class declares an abstract (or default) factory method:
```
 public abstract Dish createDish(String type);  
```

Implement Factory Subclasses

Subclasses (PizzaStation, BurgerStation) override createDish() to instantiate specific dishes:

 public class PizzaStation extends Kitchen {  
     @Override  
     public Dish createDish() {  
         return new Pizza(); // Pizza implements Dish  
     }  
 }

Optional: Use Parameters for Variants
- If a dish has variations (e.g., PastaType), pass a parameter to the factory method instead of creating more subclasses:
```
 public Dish createDish(String pastaType) {  
     return new Pasta(pastaType);  
 }  
```
Make the Factory Method Abstract (If Needed)
- If the base factory method has no default logic, declare it abstract to force subclasses to implement it.

Why Avoid Hardcoding?

A bad alternative would be hardcoding every dish in the Kitchen:

// ❌ Hardcoded (inflexible)  
public class Kitchen {  
    public Pizza makePizza() { ... }  
    public Burger makeBurger() { ... }  
    // Requires changes for every new dish!  
}

Problems:

Violates the Open/Closed Principle (code isn’t open for extension).
Becomes bloated as new dishes are added.

Diagram

Levantando uma ASP.NET Web API em AWS ECS

Bruno Caxias — Wed, 24 Apr 2024 17:10:11 +0000

Introdução

Este artigo tem como objetivo ensinar como é possível levantar uma imagem Docker de uma Web API em ASP.NET para AWS ECS utilizando o GitLab Container Registry e o AWS Academy.

Antes de Começarmos

Para poder utilizar o ECS da AWS, antes deve-se ter um registro de uma imagem Docker do seu projeto. Nesse caso, será utilizado como exemplo um registro no repositório do GitLab, mas também é possível utilizar outros registros como o do próprio Docker (DockerHub) ou o registro do ECR da AWS. Além disso, deve-se ter um cadastro na plataforma da AWS para uso das ferramentas. No caso deste artigo, será utilizado uma conta de estudante com acesso limitado a alguns módulos. Outro ponto a se considerar é a conexão da API com o banco de dados. No exemplo fornecido, a API está conectada a um banco levantado no próprio AWS por RDS, por meio de uma string de conexão no próprio código fonte.

O Que é o ECS?

De acordo com a documentação oficial da Amazon, o ECS é um serviço totalmente gerenciado de orquestração de contêineres que ajuda a implantar, gerenciar e dimensionar facilmente aplicações conteinerizadas. Sendo assim, esse serviço se encaixa perfeitamente para as necessidades desse artigo.

Salvando a imagem Docker em um Registry

Para esse exemplo será utilizado o Container Registry do GitLab para salvar e disponibilizar a imagem do Docker contendo o projeto.

Crie um repositório com o projeto que deseja dockerizar no GitLab.
Ao criar o repositório, vá até Deploy -> Container Registry na barra lateral.

Utilize os comandos mostrados na tela principal para realizar a publicação da imagem do Docker:

docker login registry.gitlab.com
docker build -t [url do registro do projeto] .
docker push [url do registro do projeto]

Os comandos de build podem variar contendo outras tags dependendo do projeto, então é importante prestar atenção a esses cuidados.

Levantando o ECS em AWS

Iniciando o Lab

Para começar o levantamento do ECS, primeiro deve-se acessar o AWS Lab para ter acesso aos serviços.

Clique em Start Lab, assim que o símbolo de AWS ficar verde clique nele.

Criando o ECS

Após isso, na aba de pesquisa coloca-se ECS para encontrar o serviço.

Clicando um ECS a seguinte tela deve aparecer.

Crie um cluster para o serviço seguindo os passos, nesse caso será criado um cluster AWS Fargate (Sem servidor):

Insira um nome para o cluster
Selecione AWS Fargate

Criando tarefas para rodar no Cluster

Acesse Definições da tarefa na barra lateral.

Clique em Criar nova definição de tarefa.
Defina um nome para a tarefa.

Configure os requisitos de infraestrutura, nesse caso será mantido o AWS Fargate no tipo de inicialização, o sistema operacional deve ser o sistema no qual o seu Docker irá rodar, o tamanho da tarefa deve ser definido a partir dos requisitos da sua Web API (Para APIs com muita computação é aconselhável alterar os valores).

Em funções da tarefa é interessante que em Função de execução de tarefas seja selecionado um perfil com as permissões necessárias para as ações da API, ou no caso de contas de estudante (como a utilizada), seja selecionada uma opção permitida. Nesse caso, será utilizado o perfil LabRole.

Agora será o momento de configurar o container para que rode no cluster.
- Comece colocando um nome para o contêiner, o link para a imagem do Docker no repositório, mantenha a opção de Contêiner Essencial como Sim, caso as imagens do repositório sejam privadas é necessário a configuração de um Secrets Manager no AWS para autenticação e acesso a imagem no repositório.

Caso não saiba, para conseguir o link para a imagem no repositório você deve ir em Deploy -> Container Registry após ter publicado a imagem e clicar no botão de copiar ao lado do nome da imagem.

Em mapeamento de porta coloque a porta em que a API estará respondendo, no exemplo será a porta 8080. Caso queira o protocolo da aplicação pode ser alterado também (por exemplo HTTP2 para HTTPS).

No caso do exemplo o resto das opções podem ser mantidas como padrão.

Inserindo a tarefa no Cluster

Acesse o Cluster e clique em Criar na aba de Tarefa.

Em Ambiente selecione a opção Tipo de Inicialização e mantenha em Fargate.

Em Configuração de Implantação selecione Serviço. No caso da Web API, selecione a família da tarefa criada para o cluster, atribua um nome, mantenha o tipo de serviço no padrão e coloque quantas tarefas irão ser inicializadas.

Após isso, para esse exemplo pode-se manter o resto em padrão e clicar em Criar.

Acessar a API Web por IP Público

Depois de criado o serviço no cluster basta acessar o cluster e na aba services selecionar o serviço criado.

Na tela do serviço clique em Tarefas e clique na Tarefa do serviço.

Ao clicar na tarefa, na aba de Configuração será possível ver uma aba com o IP Público, por meio desse IP será possível acessar a API externamente.

Lembre-se de colocar a porta que deve ser acessada, assim como os caminhos próprios da API na URL para verificar funcionalidade.

Conclusão

Dessa forma, por meio desse artigo temos ao fim uma ASP.NET Web API Dockerizada rodando em ECS AWS. Essa publicação teve em mente detalhar e exemplificar melhor o processo de criação desse serviço utilizando imagens dos módulos. Por fim, é importante incentivar a leitura da documentação oficial do AWS assim como a busca por outros fóruns capazes de sanar dúvidas e questões relacionadas a passos específicos não elaborados suficientemente aqui.

Levantando um SQL Server RDS em AWS

Bruno Caxias — Wed, 24 Apr 2024 15:56:14 +0000

Introdução

Este artigo tem como objetivo ensinar como é possível levantar um SQL Server em RDS por meio do AWS Academy.

Antes de Começarmos

Para poder utilizar o RDS do AWS, deve-se ter um cadastro na plataforma da AWS para uso das ferramentas. No caso deste artigo, será utilizado uma conta de estudante com acesso limitado a alguns módulos.

O Que é o RDS?

De acordo com a documentação oficial da Amazon, o Amazon Relational Database Service (Amazon RDS) é um serviço da Web que facilita a configuração, operação e escalabilidade de um banco de dados relacional na Nuvem AWS. Ele fornece capacidade econômica e redimensionável para um banco de dados relacional padrão do setor e gerencia tarefas comuns de administração de banco de dados.

Levantando o RDS na AWS

Iniciando o Lab

Para começar o levantamento do ECS, primeiro deve-se acessar o AWS Lab para ter acesso aos serviços.

Clique em "Start Lab". Assim que o símbolo da AWS ficar verde, clique nele.

Criando o RDS

Após isso, na aba de pesquisa, coloca-se "RDS" para encontrar o serviço.

Clique em RDS e acesse a opção de Instâncias de banco de dados.

Clique em Criar Banco de Dados.

Na tela de criação, na aba de Escolher um método de criação de banco de dados, devido às limitações da conta utilizada, a opção de Criação Fácil é indisponível.

Em Opções de Mecanismo, selecione Microsoft SQL Server e escolha a versão que deseja utilizar para o banco. No caso do exemplo, a versão será a seguinte:

Em modelos, escolha qual a fase do projeto que deseja utilizar. Para o exemplo, será utilizado a versão gratuita.

Na aba de configurações, defina o nome, usuário e senha do banco.

As senhas podem ser salvas em AWS Secret Manager, mas aqui será utilizado um Autogerenciado.

Para o resto das configurações, pode-se manter em padrão.

Caso queira acessar seu banco externamente, é necessário fazer alterações nas configurações de Conectividade.

Nas opções, é possível vincular o banco a uma instância EC2 já existente no AWS e também é possível ativar o Acesso Público ao banco.

Após isso, pode-se criar o banco de dados e esperar o mesmo subir ao ar.

Mudando regras de acesso para o banco

Na tela de detalhes do banco, podemos ver várias informações sobre o mesmo. Em Connectivity & security, encontramos o endpoint que será a URL de acesso para o banco.

Para mudar as regras para o acesso público ao banco, é necessário acessar o firewall responsável pelo mesmo. Para isso, deve-se acessar o VPC na área de Security dentro de Connectivity & security e clicar no link do mesmo.

Ao ser redirecionado para a página de Security Groups, deve-se acessar o security group responsável pelo banco de dados.

Ao acessar o security group responsável pelo banco, pode-se ver a aba de Inbound rules e nela estarão presentes todas as regras de acesso ao banco de dados.

Para criar uma nova regra, basta clicar em Edit Inbound Rules e, na tela que aparecer, criar a nova regra.

A seguinte regra permite que qualquer IP acesse o banco, sendo necessário apenas o uso do usuário e da senha (se foram criados).

Conclusão

Dessa forma, conclui-se o tutorial com passo-a-passo e imagens para compreensão de como criar um banco de dados RDS na AWS, visando sanar possíveis dúvidas e falta de entendimento do processo. Juntamente com este documento, recomenda-se o estudo aprofundado das ferramentas do AWS, assim como a busca por outros fóruns capazes de detalhar passos não elaborados.

Explorando o AppSmith com uma REST API

Bruno Caxias — Mon, 05 Feb 2024 11:33:29 +0000

Introdução

Este artigo tem o objetivo de detalhar algumas partes da manipulação de componentes do AppSmith que fazem uso de uma REST API e de JS, proporcionando um melhor entendimento dessas funcionalidades. Embora a ferramenta AppSmith já esteja bem documentada no site oficial, é possível identificar algumas lacunas e pontos que não foram suficientemente detalhados. Assim, este documento surge como uma maneira de preencher essas lacunas.
Além disso, é pressuposto que uma API (pronta e funcional) será utilizada no projeto, sendo este o foco principal.

1. Criando Um Novo Projeto

Criar um novo projeto é relativamente simples, apenas clicando no botão

Um projeto pode ser importado também, caso você já possua alguma parte pronta de outro projeto AppSmith.

2. Utilizando APIs

2.1. Configurando DataSource

Antes de realizarmos as queries da API devemos configurar o DataSource nas opções do AppSmith.

Selecione para criar um novo DataSource e selecione RestAPI para utilizar uma API já criada.

A tela que aparecerá será uma de geração de query:

Caso queira somente realizar uma query em uma API pública basta inserir o link no campo de url, mas caso queira salvar um DataSource que será utilizado constantemente durante o projeto siga os seguintes passos:

Selecione a opção de Authentication

E após selecione o botão central de ‘Save as DataSource’

Na tela de datasource preencha os dados necessários para a API. A URL inserida deve ser a URL base da API e não a da query que deseja ser feita (ex. uma query http://localhost:1337/api/pessoas tem como o endereço base da API http://localhost:1337/).

Se a API necessitar de algum tipo de autenticação, essa mesma pode ser realizada pela última opção de Authentication.

No caso do uso conjunto com o Strapi é necessário uma autenticação por ‘Bearer Token’, ao selecionar essa opção uma nova caixa de texto aparecerá para inserir o token de autenticação do Strapi (para adquirir esse token verifique a documentação do Strapi)

Após salvar o DataSource é possível realizar queries de forma mais simples, inserindo somente as rotas de navegação e mantendo a URL base, como no exemplo abaixo utilizando a rota ‘/api/pessoas/’

2.2. Utilizando APIs em Componentes

Ao se criar um componente como uma tabela é demonstrada a opção de conexão para obtenção de dados.

Ao clicar no botão tem-se novamente a opção de realizar uma query, mas desta vez será utilizado como base o DataSource já cadastrado anteriormente.

A tela de início não possuirá nada na URL, mas ao clicar no DataSource salvo na aba de Datasources o campo irá se auto preencher com a URL base e com isso basta complementar com a rota desejada.
A partir disto é possível testar a resposta da API clicando em ‘RUN’ e vendo o resultado da query.

2.3. Utilizando APIs sem Componentes

Queries também podem ser realizadas sem estarem vinculadas a um componente.

Selecionando a opção ‘Explorer’ no menu lateral e clicando no simbolo ‘+’ ao lado de ‘Queries/JS’ é possível criar uma query sem estar vinculada a um componente.

3. Utilizando componentes

3.1. Tabelas

Ao se criar uma tabela e um datasource for escolhido a tabela gerará uma coluna para cada tipo de dado fornecido.

Por meio das configurações presentes no menu lateral direito é possível definir o datasource e realizar configurações individuais para cada coluna, não só mudando a visibilidade das mesmas mas também a formatação dos dados presentes em cada.

Além das colunas geradas pelo datasource é possível também serem criadas colunas extras com nomes, símbolos e opções configuráveis, como as colunas de ‘Apagar’ e ‘Mais Detalhes’ presentes no exemplo.

3.2. Dropdowns

O menu dropdown ao ser adicionado já possui um dataset básico de exemplo. Sendo assim, deve-se altera-lo caso seja desejado utilizar dados do Datasource.

É importante sempre definir a ‘Label Key’ e a ‘Value Key’ de forma correta, sendo a ‘Label Key’ o campo que será utilizado para aparecer na listagem do dropdown e o ‘Value Key’ o valor do campo (ex. O objeto coordenador pode ter o nome ‘Bruno’ e o id ‘1’ e ao enviar a informação desse objeto esse id deve ser passado então ‘Bruno’ seria o ‘Label Key’ e o id seria o ‘Value Key’)

3.3. Date Pickers

O date picker não necessita de muitas alterações mas é importante verificar se o formato de data que é enviado é similar ao requisitado pela API.

O date format deve estar de acordo com o formato utilizado pela API (ex. Se a API requisitar a data em formato yyyy/mm/dd o date picker deve também ser configurado para este date format)

4. Redirecionando telas com informações

Ao selecionar um botão é possível atribuir ao mesmo um ação onClick.

Para que seja feito um botão de redirecionamento deve ser utilizada a opção ‘Navigate To’, ao seleciona-la é possível ser enviado um parâmetro pela query na aba de ‘Query params’. Utilizando variáveis já presentes no AppSmith é possível por exemplo no caso de uma tabela enviar o id da linha selecionada, nesse caso o id do
objeto que foi selecionado.

Então em outra tela esse parâmetro enviado, nesse caso o id, pode ser utilizado para realizar uma nova query como no exemplo acima utilizando a variável ‘appsmith.URL.queryParams.key’ para resgatar a key enviada.

5. Usando JS

O uso de javascript também é possível no AppSmith, sendo que a criação de um script ocorre na mesma aba de criação de queries.

Dessa forma, esses scripts podem ser atribuídos a diversos componentes, como no exemplo abaixo ao ser utilizado para calcular horas de trabalho.

Conclusão

Em resumo, este documento procurou oferecer assistência na configuração do DataSource e na utilização dos componentes, como tabela, dropdown e date picker, disponibilizados pelo AppSmith. Foram fornecidos insights sobre a configuração e a aplicação adequada desses elementos, incluindo detalhes sobre a configuração de queries e o uso de JS para personalizar campos de componentes. Recomenda-se a exploração da documentação oficial e de outros documentos complementares para uma compreensão mais aprofundada e para atender às demandas específicas de projetos. A combinação do AppSmith com APIs representa uma ferramenta robusta para o desenvolvimento ágil e eficaz de aplicativos.

Forem: Bruno Caxias

Simplifying Design Patterns : Singleton

Introduction

How Does the Singleton Pattern Work?

Example Scenario: A Restaurant Kitchen

When to Use the Singleton Pattern?

How to Implement the Singleton Pattern

Step-by-Step (Restaurant Example)

Diagram

Simplifying Design Patterns : Prototype

Introduction

How Does the Prototype Pattern Work?

Example Scenario: A Restaurant Kitchen

When to Use the Prototype?

How to Implement the Prototype Pattern in C#

Step-by-Step (Restaurant Example)

1. Define the Cloning Interface or Method

2. Implement the Copying Logic

3. Implement the Clone() Method

Factory Method vs. Prototype in C#

Diagram

Simplifying Design Patterns : Builder

Introduction

How Does the Builder Pattern Work?

Example Scenario: A Restaurant Kitchen

When to Use the Builder?

How to Implement the Builder

Step-by-Step (Restaurant Example)

Diagram

Simplifying Design Patterns : Abstract Factory

Introduction

How Does the Abstract Factory Work?

Key Characteristics

Example Scenario: Restaurant Kitchen

When to Use Abstract Factory?

How to Implement Abstract Factory

Step-by-Step (Restaurant Example)

Why Avoid Hardcoding Factories?

Diagram

Key Takeaways

Simplifying Design Patterns : Factory Method

Introduction

How Does the Factory Method Work?

Example Scenario: A Restaurant Kitchen

When to Use the Factory Method?

How to Implement the Factory Method

Step-by-Step (Restaurant Example)

Why Avoid Hardcoding?

Diagram

Levantando uma ASP.NET Web API em AWS ECS

Introdução

Antes de Começarmos

O Que é o ECS?

Salvando a imagem Docker em um Registry

Levantando o ECS em AWS

Iniciando o Lab

Criando o ECS

Criando tarefas para rodar no Cluster

Inserindo a tarefa no Cluster

Acessar a API Web por IP Público

Conclusão

Levantando um SQL Server RDS em AWS

Introdução

Antes de Começarmos

O Que é o RDS?

Levantando o RDS na AWS

Iniciando o Lab

Criando o RDS

Mudando regras de acesso para o banco

Conclusão

Explorando o AppSmith com uma REST API

Introdução

1. Criando Um Novo Projeto

2. Utilizando APIs

2.1. Configurando DataSource

2.2. Utilizando APIs em Componentes

2.3. Utilizando APIs sem Componentes

3. Utilizando componentes

3.1. Tabelas

3.2. Dropdowns

3. Implement the `Clone()` Method