DEV Community: Felipe Leao

The Developer’s Playbook: What I Wish I Knew Starting Out

Felipe Leao — Sun, 06 Oct 2024 17:59:22 +0000

What I Wish I Had Heard as a Software Developer 3 Years Ago

It’s worth noting that I’ve primarily worked in startups where agile development and product-based thinking were key pillars. However, I believe these points can be generalized, as the ultimate goal of developing software is to create something that people use (even better if you can sell that service). With that in mind, let’s dive into these points:

Don’t Compare Yourself Negatively to Others

You will always find professionals who are more experienced, quicker to grasp processes, workflows, and technical concepts. This is part of the journey. Instead of feeling discouraged, see these people as a goal to work towards. Focus on gradual improvement and learning from them rather than feeling inadequate.

Analyze Everything

The best way to grow as a developer is by analyzing everything around you. Study company processes, workflows, and try to understand how every department in your company works and how they connect. Ask questions and answer them when you can. This constant flow of information will make you increasingly valuable and knowledgeable.

Ask Questions and Understand the Big Picture

Ask as many questions as you can. Understand what you're building and why. Learn about your company's stakeholders, how your product is sold, and the sales process itself. Understand how departments communicate. In essence, if you don’t fully grasp something, take the time to figure out why it happens.

Seek Mentors and Mentor Others

You don’t need to be an expert to mentor someone. Always be willing to help with questions, explain workflows, decision-making processes, and technical concepts. Likewise, find mentors for yourself. Stay in touch and constantly ask for or offer feedback from those involved.

Keep Learning

Continue deepening your knowledge of the technologies your company uses. Aim to fully understand the tools you're working with and maximize their potential in your tasks. If you want to dive into new technologies, build a strong case and sell the idea to your team. Try to integrate that knowledge into your workflow whenever possible.

Be Proactive

If your company doesn’t have a testing culture, and you think it should, take the initiative. Lead by example, spark conversations, and make it happen. Of course, always keep deadlines and priorities in mind, but whenever you can, introduce new ideas, workflows, and concepts. It’s through this initiative that people will recognize your value within the team.

Strategies for Writing More Testable Code - An Imperative Approach

Felipe Leao — Sun, 01 Sep 2024 04:36:08 +0000

More testable code

Initial Observations

Improvement in test writing and code testability depends on the team's maturity with:
- The development environment
- Test development
- System architecture
- Requirements understanding and clarity
The points covered in this document are based on the theoretical study and knowledge acquired during the exhaustive practice of test development.
- Such practices will be useful and relevant, however, standards must be created and maintained by the teams so that the workflow of developing code and writing tests becomes a common and easily adaptable flow for everyone.

What are tests for?

Tests serve as documentation for other developers.
- Facilitates the understanding and maintenance of a company's products.
Testing provides confidence in the development and maintenance of product flows.
Tests indicate whether your code is well written.
- If it's difficult to write tests for a piece of code, it may be badly written, complex, verbose, over-coupled, or more complicated than it could be.
Tests detect faults during the development stage.
- They prevent these faults from being found by users.

Why having well-testable code is positive for the lifespan of software?

The flow of software is always changing to keep up with the real world and the needs of users.
- Maintaining a team's testing culture depends on the time/benefit ratio of writing tests.
Having a well-testable code implies the adoption and maintenance of a codebase structure/architecture, generating:**
- Easier to understand and develop
- Reduced time to find faults**
- Better understanding of complex flows
- Less costly, tiring and disorganized workflow

Strategies to improve the testability of a code

a complete understanding of the requirements and design of a system
- this includes the infrastructure of the code
- how internal and external components interact
Definition of breakpoints.
Error standardization
- Standardization of error messages
Data standardization
Separation of internal and external components well decoupled

Let's break down the above points:

Available Infrastructure

Understanding the infrastructure involves knowing what resources are available, such as servers, cloud services, databases, and how the code will run. This affects design decisions, development decisions and testing scenarios.

Interaction between Internal and External Components

Knowing how internal components (modules, services) and external components (APIs, databases, third-party systems) interact is crucial for decision-making, system design and test scenarios. For example, when integrating with a third-party API, it is important to clearly define how to deal with failures or latencies in order to maintain the system's robustness. Secondly, keeping internal components well decoupled from external components
helps us to create mocks, simulate possibilities and take control of all possible scenarios in the feature we are developing.
we are developing.

Standardization of errors and error messages

Why standardize errors and error messages?

Consistency: Guaranteed use of the same terminology throughout the system.
Ease of maintenance: Changes made in a single place, without having to search and replace throughout the code.
Internationalization: Facilitates translation by centralizing messages and instantiating them only once.
Testability: Predictable messages make it easier to validate exceptions in tests.
Reusability: Error messages can be used uniformly in different parts of the application.

export const createErrors = (error_message: string, status_code: number) => {
  const error = new Error(error_message);

  return {
    error: error,
    status_code,
  };
};

export const ErrorMessages = {
  INVALID_PASSWORD: “Invalid password”,
  USER_ALREADY_EXISTS: “User already exists”,
} as const;

export const createUser = async ({
  email,
  password,
}: {
  email: string;
  password: string;
}) => {
  const validPassword = validatePassword(password);

  if (!validPassword) {
    return createErrors(ErrorMessages.INVALID_PASSWORD, 422); // breakpoint
  }

  const userExists = await findUserByEmail(email);

  if (userExists) {
    return createErrors(ErrorMessages.USER_ALREADY_EXISTS, 412); //breakpoint
  }
};

Data normalization

What is data normalization?

Data normalization is the process of transforming unstructured data into a consistent, structured format before using it in the rest of the system. This helps ensure that the system works predictably, consistently and decoupled from external components. This applies to any external component, Cache source, data source, messaging, storage...

Why normalize data?

Separation of responsibilities: Decisions can only be made for external components, the application is treated as an independent entity.
Testability**: Generates types and interfaces that are fully linked to the application, facilitating predictability and mock results.
Documentation: Normalization creates an implicit documentation of the expected data format.

const orders = await db.order.findMany();

// [
// {
// “id”: 1,
// “customer_id”: 101,
// “product_id”: 202,
// “quantity”: 2,
// “total_price”: 59.99,
// “created_at”: “...”,
// “status”: “shipped”,
// “delivery_date”: “...”,
// “notes”: “FRAGILE”
// },
// ...
// ]

type NormalizedOrder = {
  orderId: number;
  customerId: number;
  productId: number;
  quantity: number;
  totalPrice: number;
  status: string;
  deliveryDate: string | null;
  notes?: string;
};

// normalizing generalizing
function normalizeOrders(orders: any[]): NormalizedOrder[] {
  return orders.map((order) => ({
    orderId: order.id,
    customerId: order.customer_id,
    productId: order.product_id,
    quantity: order.quantity,
    totalPrice: Number(order.total_price),
    status: order.status,
    deliveryDate: order.delivery_date
      ? new Date(order.delivery_date).toISOString()
      : null,
    notes: order.notes,
  }));
}

// normalizing by adapter

import { Order as PrismaOrder } from “@prisma/client”;
import { Order as MongoOrder } from “mongodb”;

function normalizePrismaOrder(order: PrismaOrder[]): NormalizedOrder {
  return {
    orderId: order.id,
    customerId: order.customer_id,
    productId: order.product_id,
    quantity: order.quantity,
    totalPrice: Number(order.total_price),
    status: order.status,
    deliveryDate: order.delivery_date
      ? new Date(order.delivery_date).toISOString()
      : null,
    notes: order.notes,
  };
}

function normalizeOrmOrder(order: MongoOrder[]): NormalizedOrder {
  return {
    orderId: order._id,
    customerId: order.customerId,
    productId: order.productId,
    quantity: order.quantity,
    totalPrice: order.totalPrice,
    status: order.status,
    deliveryDate: order.deliveryDate ? order.deliveryDate.toISOString() : null,
    notes: order.notes,
  };
}

Mat of instructions that don't carry too much complex logic.

import client as mailClient from “@sendgrid/mail”;
import { db } from “./db”;
import dotenv from 'dotenv'

dotenv.config()

const processOrder = async(data: {
  order,
  user_id
}, {
  orders: {
    quantity: number;
    item: string
  }[],
  user_id: string
}) => {


  const user = await db.user.findUnique({
    where: {id: user_id}
  })
  if (order.quantity <= 0) {
    console.log(“Invalid quantity”);
    return;
  }

  const validItems = [“Laptop”, “Smartphone”, “Tablet”];

for (const order of orders)
  if (!validItems.includes(order.item)) {
    console.log(“Invalid item”);
    return;
  }
}

  const message = {
    from: “store@gmail.com”,
    to: user.email,
    subject: “Purchase made”,
    body: `email body`,
  };

  const mailClient = mailClient.setApiKey(process.env.SENDGRID_KEY);

  const data = await client.send(message);

  return {ok: true}
}


import client as mailClient from “@mail”;
import { db } from “./db”;
import dotenv from 'dotenv'

dotenv.config()


const ErrorMessages = {
  INVALID_QUANTITY: “Invalid quantity”,
  INVALID_ITEM: “Invalid item”,
  USER_NOT_FOUND: “User not found”,
  MAIL_NOT_SENT: “Mail not sent”,
} as const; // error message instantiated in a single source


const getUserById = async(id: number) => {
  const user = await db.user.findUnique({
    where: { id }
  })

  if (!user) {
    console.log(ErrorMessages.USER_NOT_FOUND) // standard error message
    return null
  }

  return user;
}

const validateOrder = (order: {
  quantity: number;
  item: string;
}) => {
  if (order.quantity <= 0) {
    console.log(ErrorMessages.INVALID_QUANTITY); // standard error message
    return false;
  }

  const validItems = [“Laptop”, “Smartphone”, “Tablet”];
  if (!validItems.includes(order.item)) {
    console.log(ErrorMessages.INVALID_ITEM);
    return false;
  }

  return true;
}

const sendOrderRequestedMail = async (email_to: string) => {
  const message = {
    from: “store@gmail.com”,
    to: email_to,
    subject: “Purchase made”,
    body: “email body”,
  }

  const mailClient = mailClient.setApiKey(process.env.MAIL_CLIENT_KEY);

const mailSent = await client.send(message);

  if(!mailSent) {
    console.log(ErrorMessages.MAIL_NOT_SENT)
    return { ok: false }
  }
}

const processOrder = async({
  orders,
  user_id
  }: {
  orders: {
    quantity: number;
    item: string;
  }[],
  user_id: number;
  } ) => {

  const user = await getUserById(user_id); // db decoupling

  if (!user) {
    return {ok: false} // breakpoint
   }



  for( const order of orders) {
    if (!validateOrder(order)) {
      return {ok: false} // breakpoint
    }
  }

  await sendOrderRequestedMail(user.email); // mail decoupling

  return { ok: true }
}

Benefits of refactoring

Flexibility: With a modular architecture and standardized error messages, it is easier to add new features and make changes to the code without impacting other parts of the system.
Reusability: Functions can be used in different contexts(e.g. getUserById)
Testing: Dividing the code in this way makes it easier to create mocks, stubs and spies and complete test scenarios with a simple and clear treadmill, and allows testing on small scopes of the treadmill, which are basically the causes of breakpoints.

Estratégias para escrever código com maior testabilidade - uma análise imperativa

Felipe Leao — Sat, 31 Aug 2024 00:09:17 +0000

Código com maior testabilidade

Observações Iniciais

A melhora na escrita de testes e na testabilidade do código depende da maturidade da equipe com:
- O ambiente de desenvolvimento
- O desenvolvimento de testes
- A arquitetura do sistema
- A compreensão e clareza de requisitos
Os pontos tratados nesse documento possuem base no estudo teórico e no conhecimento adquirido ao longo da prática exaustiva do desenvolvimento de testes:
- Tais práticas serão úteis e relevantes, no entanto, padrões devem ser criados e mantidos pelas equipes para que o workflow de desenvolver código e escrever testes vire um fluxo comum e de fácil adaptação para todos.

Para que servem os testes?

Testes servem como documentação para outros desenvolvedores:
- Facilita o entendimento e a manutenção dos produtos de uma empresa.
Testes transmitem confiança para desenvolvimento e manutenção de fluxos de produto.
Testes indicam se o seu código está bem escrito:
- Se é difícil escrever testes para um código, ele pode estar mal escrito, complexo, verboso, acoplado demais, ou mais complicado do que poderia.
Testes detectam falhas durante a etapa de desenvolvimento:
- Evitam que essas falhas sejam encontradas pelos usuários.

Por que ter um código bem testável é positivo para a vida útil de um software?

O fluxo de um software sempre muda para acompanhar o mundo real e as necessidades dos usuários:
- Manter a cultura de testes de uma equipe depende da relação tempo/benefício em escrever testes.
Ter um código bem testável implica na adoção e manutenção de uma estrutura/arquitetura de codebase, gerando:
- Fácil entendimento e desenvolvimento
- Redução do tempo para encontrar falhas
- Melhor entendimento de fluxos complexos
- Fluxo de trabalho menos custoso, cansativo e desorganizado

Estratégias para melhorar a testabilidade de um código

entendimento completo de requisitos e do design de um sistema
- isso inclui a infra da qual dispõe o código
- a forma como os componentes internos e externos interagem
Definição de 'breakpoints'.
Padronização de erros ( Molde )
- padronização de mensagens de erro
Normalização de dados
Separação de componentes internos e externos bem desacoplada

Destrinchemos os pontos acima:

Infraestrutura Disponível

Entender a infraestrutura envolve conhecer os recursos disponíveis, como servidores, serviços em nuvem, bancos de dados, e como o código será executado. Isso afeta decisões de design, tomadas de decisão no desenvolvimento e cenários de testes.

Interação entre Componentes Internos e Externos

Conhecer como os componentes internos (módulos, serviços) e externos (APIs, bancos de dados, sistemas de terceiros) interagem é crucial para a tomada de decisão, o design do sistema e os cenários de testes. Por exemplo, ao integrar com uma API de terceiros, é importante definir claramente como lidar com falhas ou latências para manter a robustez do sistema. Em um segundo ponto, manter componentes internos bem desacoplados de componentes externos
nos ajuda a criar mocks, simular possibilidades e ter o controle de todos os cenários possiveís na feature
que estamos desenvolvendo.

Padronização de erros e mensagem de erros

Por que padronizar erros e mensagem de erros?

Consistência: Garantia de uso da mesma terminologia em todo o sistema.
Facilidade de Manutenção: Alterações feitas em um único lugar, sem precisar buscar e substituir em todo o código.
Internacionalização: Facilita a tradução ao centralizar as mensagens e instancia-las apenas uma vez.
Testabilidade: Mensagens previsíveis facilitam a validação de exceções em testes.
Reutilização: Mensagens de erro podem ser usadas de forma uniforme em diferentes partes da aplicação.

export const createErrors = (error_message: string, status_code: number) => {
  const error = new Error(error_message);

  return {
    error: error,
    status_code,
  };
};

export const ErrorMessages = {
  INVALID_PASSWORD: "Invalid password",
  USER_ALREADY_EXISTS: "User already exists",
} as const;

export const createUser = async ({
  email,
  password,
}: {
  email: string;
  password: string;
}) => {
  const validPassword = validatePassword(password);

  if (!validPassword) {
    return createErrors(ErrorMessages.INVALID_PASSWORD, 422); // breakpoint
  }

  const userExists = await findUserByEmail(email);

  if (userExists) {
    return createErrors(ErrorMessages.USER_ALREADY_EXISTS, 412); //breakpoint
  }
};

Normalização de dados

O que é normalização de dados?

Normalização de dados é o processo de transformar dados não estruturados para um formato consistente e estruturado antes de usá-los no restante do sistema. Isso ajuda a garantir que o sistema funcione de maneira previsível, consistente e desacoplado de componentes externos. Isso serve para qualquer componente externo, Fonte de cache, fonte de dados, mensageria, storage...

Por que normalizar dados?

Separação de responsabilidades: Decisões podem ser tomadas somente para componentes externos, a aplicação é tratada como uma entidade independente.
Testabilidade: Gera tipos e interfaces totalmente ligadas a aplicação, facilitando a previsibilidade e mock de resultados.
Documentação: A normalização cria uma documentação implícita do formato esperado de dados.

const orders = await db.order.findMany();

// [
//   {
//     "id": 1,
//     "customer_id": 101,
//     "product_id": 202,
//     "quantity": 2,
//     "total_price": 59.99,
//     "created_at": "...",
//     "status": "shipped",
//     "delivery_date": "...",
//     "notes": "FRÁGIL"
//   },
//   ...
// ]

type NormalizedOrder = {
  orderId: number;
  customerId: number;
  productId: number;
  quantity: number;
  totalPrice: number;
  status: string;
  deliveryDate: string | null;
  notes?: string;
};

// normalizando generalizando
function normalizeOrders(orders: any[]): NormalizedOrder[] {
  return orders.map((order) => ({
    orderId: order.id,
    customerId: order.customer_id,
    productId: order.product_id,
    quantity: order.quantity,
    totalPrice: Number(order.total_price),
    status: order.status,
    deliveryDate: order.delivery_date
      ? new Date(order.delivery_date).toISOString()
      : null,
    notes: order.notes,
  }));
}

// normalizando por adapter

import { Order as PrismaOrder } from "@prisma/client";
import { Order as MongoOrder } from "mongodb";

function normalizePrismaOrder(order: PrismaOrder[]): NormalizedOrder {
  return {
    orderId: order.id,
    customerId: order.customer_id,
    productId: order.product_id,
    quantity: order.quantity,
    totalPrice: Number(order.total_price),
    status: order.status,
    deliveryDate: order.delivery_date
      ? new Date(order.delivery_date).toISOString()
      : null,
    notes: order.notes,
  };
}

function normalizeOrmOrder(order: MongoOrder[]): NormalizedOrder {
  return {
    orderId: order._id,
    customerId: order.customerId,
    productId: order.productId,
    quantity: order.quantity,
    totalPrice: order.totalPrice,
    status: order.status,
    deliveryDate: order.deliveryDate ? order.deliveryDate.toISOString() : null,
    notes: order.notes,
  };
}

Esteira de instruções que não carregam lógicas complexas demais.

import client as mailClient from "@sendgrid/mail";
import { db } from "./db";
import dotenv from 'dotenv'

dotenv.config()

const processOrder = async(data: {
  order,
  user_id
}, {
  order: {
    quantity: number;
    item: string
  }[],
  user_id: string
}) => {


  const user = await db.user.findUnique({
    where: {id: user_id}
  })
  if (order.quantity <= 0) {
    console.log("Invalid quantity");
    return;
  }

  const validItems = ["Laptop", "Smartphone", "Tablet"];
for (const order of orders) {
  if (!validItems.includes(order.item)) {
    console.log("Invalid item");
    return;
  }
}

  const message = {
    from: "store@gmail.com",
    to: user.email,
    subject: "Compra realizada",
    body: `corpo do email`,
  };

  const mailClient = mailClient.setApiKey(process.env.SENDGRID_KEY);

  const data = await client.send(message);

  return {ok: true}
}


import client as mailClient from "@mail";
import { db } from "./db";
import dotenv from 'dotenv'

dotenv.config()


const ErrorMessages = {
  INVALID_QUANTITY: "Invalid quantity",
  INVALID_ITEM: "Invalid item",
  USER_NOT_FOUND: "User not found",
  MAIL_NOT_SENT: "Mail not sent",
} as const; // mensagem de erros instanciadas em uma única fonte


const getUserById = async(id: number) => {
  const user = await db.user.findUnique({
    where: { id }
  })

  if (!user) {
    console.log(ErrorMessages.USER_NOT_FOUND) // mensagem de erro padronizada
    return null
  }

  return user;
}

const validateOrder = (order: {
  quantity: number;
  item: string;
}) => {
  if (order.quantity <= 0) {
    console.log(ErrorMessages.INVALID_QUANTITY); // mensagem de erro padronizada
    return false;
  }

  const validItems = ["Laptop", "Smartphone", "Tablet"];
  if (!validItems.includes(order.item)) {
    console.log(ErrorMessages.INVALID_ITEM);
    return false;
  }

  return true;
}

const sendOrderRequestedMail = async (email_to: string) => {
  const message = {
    from: "store@gmail.com",
    to: email_to,
    subject: "Compra realizada",
    body: "corpo do email",
  }

  const mailClient = mailClient.setApiKey(process.env.MAIL_CLIENT_KEY);


  const mailSent = await client.send(message);

  if(!mailSent) {
    console.log(ErrorMessages.MAIL_NOT_SENT)
    return { ok: false }
  }
}

const processOrder = async({
  orders,
  user_id
  }: {
  orders: {
    quantity: number;
    item: string;
  }[],
  user_id: number;
  } ) => {

  const user = await getUserById(user_id); // desacoplamento do db

  if (!user) {
    return {ok: false} // breakpoint
   }



  for( const order of orders) {
    if (!validateOrder(order)) {
      return {ok: false} // breakpoint
    }
  }

  await sendOrderRequestedMail(user.email); // desacoplamento do mail

  return { ok: true }
}

Beneficios da refatoração

Flexibilidade : Com uma arquitetura modular e mensagens de erro padronizadas, é mais fácil adicionar novas funcionalidades e fazer alterações no código sem impactar outras partes do sistema.
Reusabilidade: As funções podem ser usadas em diferentes contextos(ex: getUserById)
Testes: Dividir o codigo desta maneira desencadea uma facilidade em criar mocks, stubs e spies e cenários de testes completos com uma esteira simples e clara, ademais, permite o teste em pequenos escopos da esteira, que são basicamente as causas dos breakpoints.

ADHD and being a programmer

Felipe Leao — Mon, 07 Nov 2022 15:51:20 +0000

My skills are a little bit different in every regard because I have ADHD. As soon as I become interested in something, I make every effort to educate myself on it. I've always behaved that way. My father used to tell me as a child that I was "addicted to addicts" because I was unable to stop playing with any toy, video game, or other passion of mine until the day that I just quit enjoying being drawn to those things.

Now that I am an adult software developer and Computer Science student graduating college, it's a daily but gratifying struggle to maintain my interest in these types of things. In programming, I discovered an endless world. Am I free? I am starting to use Vim. Do I have free time? I'll read some topics about computer science, and it's been that way since I started. Sure, there are days when I am highly focused and productive. But there are also days when I just want to take a deep breath and focus on something else. I do not know how you have been or if you are going through something like that right now. But if so, we have something in common.

I have been in treatment and taking pills since my psychiatric doctor concluded after a few sessions that I have ADHD, and the process has been amazing. I was so anxious about everything, and that took a toll on me. That's gotten better now; of course, I am still an anxious person, but not like I used to be. What I am saying is that we draw a parallel between love and disinterest when it comes to programming and all of our fluid but solid passions. There are days and days. We must celebrate the good and productive days.

I would love to hear more stories about programmers with ADHD. Please feel free to comment below and tell about your struggles and how you daily deal with ADHD, or whatever you feel free and comfortable talking about.

ExpressJS: How to throw custom errors

Felipe Leao — Wed, 02 Nov 2022 00:53:03 +0000

The problem

Throwing readable custom errors is one of the most critical steps in the development of web applications. The communication between services must be clear and straight to the point.

The tool

Express middlewares when building NodeJS applications

The Solution:

Build an express middleware to throw custom responses error statusCode and messages
Our example will utilize a simple API built with ExpressJS and Prisma as an ORM

// app.ts


import express, { Request, Response, NextFunction } from 'express'
import 'express-async-errors'
import { router } from './routes'
import cors from 'cors'

const app = express()
app.use(express.json())
app.use(cors())
app.use(router)

app.use((err: {err: Error, statusCode: number, message: string}, _req: Request, res: Response, _next: NextFunction) => {
  if (err.err && err.err instanceof Error) {
    return res.status(err.statusCode).json({
      message: err.message,
      status: 'error'
    })
  }
  return res.status(500).json({
    status: 'error',
    message: 'Internal server error'
  })
})

export { app }

In addition, we can also define how our error response will be displayed to our clients. Here you can choose to show whatever you want and whatever you feel is pertinent for the client to see.

// lib/error

const builder = ({ statusCode, message }: {statusCode: number, message: string}) => {
  return {
    err: new Error(),
    statusCode,
    message
  }
}

export const error = { builder }

The object error should be thrown in the following manner

// src/services/userService.ts

import { error } from '../../lib/error'
import prismaClient from '../database/client'
import { IUser } from '../types/IUser'

interface ICreateUserRequest {
  name: string
  email: string
  password: string
}
const create = async ({ name, email, password }: ICreateUserRequest): Promise<IUser> => {
  if (!email) {
    throw error.builder({ statusCode: 422, message: 'Email not provided' })
  }

  if (await prismaClient.user.findFirst({ where: { email } })) {
    throw error.builder({ statusCode: 412, message: 'Email already taken' })
  }

  const user = await prismaClient.user.create({
    data: { name, email, password }
  })

  return user
}

export const userService = {create}

Basic operations every nodejs/mongoose developer should know

Felipe Leao — Thu, 14 Jul 2022 18:16:00 +0000

insert document

const cap = {
color: Yellow,
size: 'G',
brand: Nike
}

const capDb = await Cap.create(cap)

// capDb = { _id: objectId(''), color: Yellow,size: G, brand:Nike }

remove document

const cap = {
color: Yellow,
size: 'G',
brand: Nike,
_id: '123'
}

const capRemoved = await Cap.findByIdAndDelete(cap._id)

// capRemoved = { _id: objectId(''), color: Yellow,size: G, brand:Nike }

Find specific document

const cap = {
color: Yellow,
size: 'G',
brand: Nike,
_id: '123'
}

const capDb = await Cap.findById(cap._id)

// capDb = { _id: objectId(''), color: Yellow,size: G, brand:Nike }

// or 

const capDb = await Cap.findOne({color: Yellow, size: 'G'})

// capDb = { _id: objectId(''), color: Yellow,size: G, brand:Nike }

// note: findOne will return the first document that matches the filter specified if an _id is not provided

Filter documents

// find only Yellow caps from the 'Nike' brand and model 'Special'

interface cap {
brand: string
color: string
size: string
model: string
}

const caps = await Cap.find({color: 'Yellow' brand: 'Nike', model: 'Special'})

Filter documents matching array fields

// find the games which has 'PS5' platform

interface game {
genre: string
title: string
platforms: string[]
}

const gamesDb = [
{_id: '1', genre: adventure, title: 'God of War', platforms: ['PS3', 'PS4', 'PS5']},

{_id: '2', genre: adventure, title: 'Demon souls remake', platforms: ['PS5']},

{_id: '2', genre: adventure, title: 'GTA IV', platforms: ['PS3']},

{_id: '2', genre: adventure, title: 'Forza horizon', platforms: ['XBOX 360', 'XBOX ONE']}


]


const games = await Game.find({platforms: 'PS5'})

/* games = [
{_id: '1', genre: adventure, title: 'God of War', platforms: ['PS3', 'PS4', 'PS5']},

{_id: '2', genre: adventure, title: 'Demon souls remake', platforms: ['PS5']},
]
*/

Filter documents matching array fields


// find the games which has 'PS5' and 'PS3' platform

interface game {
genre: string
title: string
platforms: string[]
}

const gamesDb = [
{_id: '1', genre: adventure, title: 'God of War', platforms: ['PS3', 'PS4', 'PS5']},

{_id: '2', genre: adventure, title: 'Demon souls remake', platforms: ['PS5']},

{_id: '2', genre: adventure, title: 'GTA IV', platforms: ['PS3']},

{_id: '2', genre: adventure, title: 'Forza horizon', platforms: ['XBOX 360', 'XBOX ONE']}

]

const games = await Game.find({platforms: {$in: ['PS3','PS5']})


/*games = [
{_id: '1', genre: adventure, title: 'God of War', platforms: ['PS3', 'PS4', 'PS5']},

{_id: '2', genre: adventure, title: 'GTA IV', platforms: ['PS3']}
]

*/

Update object prop in array of objects field in document


// update a document where the monster arm size is 700 and set to 30 and tattoo to true

interface monster {
arms: [{size: number, tattoo: boolean, side: string}]
}

const monster = {
_id: '1',
arm: {
size: 700,
tattoo: false,
side: 'left'
}

const monsterUpdated = await Monster.findOneAndUpdate(
{'arms.side': 'left'}, 
{'arms.$.size': 30, 'arms.$.tattoo': true}, 
{new: true} 
)


/* monsterUpdated = {
_id: '1',
arms: [{
size: 30,
tattoo: true,
side: 'left'
}]
*/

How to unzip .zip files from s3 bucket back to s3

Felipe Leao — Thu, 14 Jul 2022 02:56:33 +0000

The problem

Get an .zip file provided from s3 bucket and upload the extracted folder and its content back to s3 bucket

The solution

Built an npm package that gets an .zip file from s3 and create streams, with that you can do whatever you want with the extracted content.
You can check more and contribute to our package in: s3-zip-handler

built-in possibilities

Send extracted folder back to s3 bucket


import AWS from 'aws-sdk'
import s3ZipHandler, { IS3ZipFileParams } from 's3-zip-handler'

const s3Client = new AWS.S3({
...your s3 settings
})


const s3Config: IS3ZipFileParams = {
    s3Client,
    bucket: 'your-s3-bucket',
    key: 'your-s3-key/your-zip-file.zip',
    params: {
      ACL: 'public-read',
      ContentDisposition: 'inline'
    }
} 

const {
localPath, 
uploadedPath 
} = await s3ZipHandler.decompressToKeyFolderS3(s3Config)

// localPath = 'os-tmp/unzipped-xxxx/your-zip-file'
// uploadedPath  = 'your-s3-bucket/your-s3-key/your-zip-file'

Manipulate locally the extracted folder

import s3ZipHandler from 's3-zip-handler'
import AWS from 'aws-sdk'

const s3Client = new AWS.S3({
    ...your s3 settings
})

const s3Config = {
    s3Client,
    bucket: 'your-s3-bucket',
    key: 'your-s3-key/your-zip-file.zip'
} 

const {
 localPath
 } = await s3ZipHandler.decompressLocal(s3Config, 'path-to-extract')

// localPath = 'path-to-extract/your-zip-file'