DEV Community: Vinicius Blazius Goulart

Integrating WhatsApp with Google Sheets

Vinicius Blazius Goulart — Mon, 20 Nov 2023 11:58:53 +0000

TLDR

I used to have a manual job that took hours to complete. Essentially, for some of the parties here in my city, guest lists were prepared. These lists included attendees who were paid, free, or prepaid. However, I was the one responsible for creating this guest list—event promoters would send me the names of the attendees, and I had to add these names to a spreadsheet for the day of the event.

The idea was to somehow automate this task. I wanted to minimize the changes for the promoters, so I didn't intend to shift from the convenience of sending names in a WhatsApp group. However, I also didn't want to spend hours organizing a list (some events had more than a thousand names).

To automate this, I thought of integrating WhatsApp with Google Sheets. I'll be sharing a bit about my experience performing this integration.

Tooling

Given my familiarity with the NodeJS + MongoDB stack, I chose to use it as the development stack for speed.

The complete stack I selected comprised: Typescript, NodeJS, MongoDB, and SWC.

For managing Google Sheets, I utilized the Google-provided API: googleapis

To handle WhatsApp, I needed to simulate a browser using Puppeteer and connect my WhatsApp to it. I used a library that did this for me: whatsapp-web.js

Once equipped with these tools, it was time to get my hands dirty. It's important to note that I started with the bare essentials—the MVP. The goal was to keep things simple initially.

I won't delve into every detail in this post, so feel free to follow the project: wpp-sheets-party-list

Entry point

To run the application, three things were necessary: connecting to my database, authorizing the Google client, and connecting to WhatsApp.

Mongodb

Connecting to my database allowed me to identify and synchronize a WhatsApp group with a spreadsheet. You can find the complete schema at https://github.com/vinibgoulart/wpp-sheets-party-list/blob/main/src/sheets/SheetModel.ts.

Google Sheets

The authorization part with Google was a bit more complex. Various environment variables were necessary.



const client = new google.auth.GoogleAuth({
    scopes: GOOGLE_SCOPES,
    keyFile: "credentials.json",
  });

For our application scope, we used Google Drive and Google Sheets to manipulate files and spreadsheet content. In the credentials, we needed to include all the necessary data to authenticate the Google client.



export const credentials = {
  type: "service_account",
  project_id: config.GOOGLE_PROJECT_ID,
  private_key_id: config.GOOGLE_PRIVATE_KEY_ID,
  private_key: config.GOOGLE_PRIVATE_KEY.split(String.raw`\n`).join("\n"),
  client_email: config.GOOGLE_SERVICE_ACCOUNT_EMAIL,
  client_id: config.GOOGLE_CLIENT_ID,
  auth_uri: config.GOOGLE_AUTH_URI,
  token_uri: config.GOOGLE_TOKEN_URI,
  auth_provider_x509_cert_url: config.GOOGLE_AUTH_PROVIDER,
  client_x509_cert_url: config.GOOGLE_CLIENT_CERT_URL,
  universe_domain: "googleapis.com",
};

WhatsApp Api

The next step was to connect WhatsApp and listen for new events. Firstly, initializing the client and displaying the QR code to connect to WhatsApp.



import { Client, LocalAuth } from "whatsapp-web.js";
import { onReady } from "./onReady";
import { onMessage } from "./onMessage";
import { onAuthFailure } from "./onAuthFailure";
import { onQrCode } from "./onQrCode";

export const client = new Client({
  authStrategy: new LocalAuth(),
  authTimeoutMs: 60 * 1000,
  puppeteer: {
    args: ["--no-sandbox", "--disable-setuid-sandbox"],
  },
});

export const connectClient = () => {
  client.initialize();

  onQrCode();

  onReady();

  onAuthFailure();

  onMessage();
};

A single file encompassed all my events. The first one to be executed was onQrCode, responsible for displaying the QR code for connection.



import { client } from "./client";

import qrcode from "qrcode-terminal";

export const onQrCode = () => {
  client.on("qr", (qr) => {
    qrcode.generate(qr, { small: true });
  });
};

After scanning this QR code on our phone, we received a message that the client was ready to receive messages.



import { client } from "./client";

export const onReady = () => {
  client.on("ready", () => {
    console.log("Client is ready!");
  });
};

Now, we could delve deeper into the sent messages.

The idea is this: create a group with promoters, naming the group after the event. Add the number connected to the application to the group, start the bot, and it would begin listening for new names and sending them to a spreadsheet.

These are the configured messages that the bot accepts:



import { client } from "../client";
import defaultMessage from "./defaultMessage";
import freeMessage from "./freeMessage";
import helpMessage from "./helpMessage";
import howItWorksMessage from "./howItWorksMessage";
import inputExamplesMessage from "./inputExamplesMessage";
import paidMessage from "./paidMessage";
import removeMessage from "./removeMessage";
import sheetsCreateMessage from "./sheetsCreateMessage";
import sheetsDetailMessage from "./sheetsDetailMessage";
import sheetsFinishMessage from "./sheetsFinishMessage";
import startListeningMessage from "./startListeningMessage";
import stopListeningMessage from "./stopListeningMessage";

export const onMessage = () => {
  client.on("message", async (msg) => {
    switch (msg.body) {
      case "!help":
        return helpMessage(msg);

      case "!hiw":
        return howItWorksMessage(msg);

      case "!ie":
        return inputExamplesMessage(msg);

      case "!sc":
        return sheetsCreateMessage(msg);

      case "!sd":
        return sheetsDetailMessage(msg);

      case "!sf":
        return sheetsFinishMessage(msg);

      case "!start":
        return startListeningMessage(msg);

      case "!stop":
        return stopListeningMessage(msg);

      case "!free":
        return freeMessage(msg);

      case "!paid":
        return paidMessage(msg);

      case "!remove":
        return removeMessage(msg);

      default:
        return defaultMessage(msg);
    }
  });
};

Some are help or explanation messages, while others are for interacting with the spreadsheet. The most important commands are:

!sc: to create a new list
!sd: to get details of the ongoing list
!sf: to finish a list
!stop: to temporarily stop the bot from listening to new names without finishing the list
!start: to resume the bot's listening process

Additionally, we have commands to manipulate names on the list:

default: if the bot is running in a group, any message that isn't a command is interpreted as a name and sent to Google Sheets
!free: to indicate that a sent name should go into the 'free' column
!paid: to indicate that a sent name should go into the 'prepaid' column

Sheet Create

The !sc command initializes a list. You can drill down into how it works here: https://github.com/vinibgoulart/wpp-sheets-party-list/blob/main/src/wweb/onMessage/sheetsCreateMessage.ts.

With this command, several actions are performed. Firstly, we create a list on Google Sheets, then change the group's description and name to indicate that the list is active. Finally, we send spreadsheet information to the group and start listening for new names.

From now on, all sent names will be directed to the spreadsheet. You can confirm if a name was sent to the spreadsheet by checking if the bot reacted to your message.

In this case, we sent three names to the list, and the bot accepts various name formats.

Apart from sending names to the list, the bot capitalizes names and sorts them alphabetically.

It's also possible to send names to the other two columns, 'free' and 'prepaid,' by replying to a message with either !free or !paid, and the name will go into the respective column.

And that's basically it. You use it to receive names and automatically add them to a spreadsheet. Finally, you can execute the !sd and !sf commands to view the list details or finish it.

You can view the complete code and delve deeper into the project here: https://github.com/vinibgoulart/wpp-sheets-party-list/tree/main

Deploy

To minimize my concerns about the bot, I opted for deployment, which brought new challenges. I chose to deploy on Railway because it's a platform I was already familiar with.

As we're running Puppeteer underneath and simulating a browser, we needed to install Chromium during the deployment preparation.

We easily achieved this with Docker by installing Chromium and defining it in our Dockerfile.



# syntax = docker/dockerfile:1

# Adjust NODE_VERSION as desired
ARG NODE_VERSION=20.3.0
FROM node:${NODE_VERSION}-slim as base

LABEL fly_launch_runtime="Node.js"

# Node.js app lives here
WORKDIR /app

# Set production environment
ENV NODE_ENV="production"

# Install pnpm
ARG PNPM_VERSION=8.6.5
RUN npm install -g pnpm@$PNPM_VERSION


# Throw-away build stage to reduce size of final image
FROM base as build

# Install packages needed to build node modules
RUN apt-get update -qq && \
    apt-get install -y build-essential pkg-config python-is-python3 chromium chromium-sandbox

# Install node modules
COPY --link package.json pnpm-lock.yaml ./
RUN pnpm install --frozen-lockfile --prod=false

# Copy application code
COPY --link . .

# Build application
RUN pnpm run build

# Remove development dependencies
RUN pnpm prune --prod


# Final stage for app image
FROM base

# Install packages needed for deployment
RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y chromium chromium-sandbox && \
    rm -rf /var/lib/apt/lists /var/cache/apt/archives

# Copy built application
COPY --from=build /app /app

# Start the server by default, this can be overwritten at runtime
EXPOSE 3001
ENV PUPPETEER_EXECUTABLE_PATH="/usr/bin/chromium"
CMD [ "pnpm", "run", "start" ]

With this Dockerfile setup, we finally managed to deploy to Railway and keep the bot running.

Github: https://github.com/vinibgoulart/wpp-sheets-party-list/tree/main

Photo by Mohamed Nohassi on Unsplash

Creating a express app with typescript and swc

Vinicius Blazius Goulart — Sat, 28 Oct 2023 17:26:07 +0000

Creating an Express application with TypeScript and compiling it can seem daunting, especially for beginners. In this blog post, we aim to simplify the process by providing a template for an Express application using TypeScript and compiling it with SWC.

SWC is a Rust-based transpiler and compiler that's straightforward to configure and can significantly streamline your development workflow.

Let's get started.

Setting Up Your Project

Begin by creating a new directory and initializing your project:

mkdir express-app
cd express-app
pnpm init

Installing SWC

Next, install the necessary SWC packages:

pnpm i -D @swc/cli @swc/core

With SWC, you can create a configuration file for your project. Create a .swcrc file in the project's root directory. In this file, specify that you are using TypeScript and need to compile to CommonJS:

{
  "$schema": "https://json.schemastore.org/swcrc",
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false,
      "dynamicImport": true,
      "decorators": false
    },
    "transform": null,
    "target": "es2016",
    "loose": false,
    "externalHelpers": false,
    "keepClassNames": false
  },
  "module": {
    "type": "commonjs",
    "strict": false,
    "strictMode": false,
    "noInterop": false,
    "lazy": false
  },
  "minify": true
}

Setting Up Express

To create your Express application, start by installing the Express package:

pnpm i express
pnpm i -D @types/express @types/node

Now, create two new files in the src/ directory: index.ts(the entry point of your project) and server.ts (your server app):

mkdir src
touch src/index.ts
touch src/server.ts

In server.ts, create an Express app and expose it:

// server.ts
import { createServer } from "http";
import express from "express";

export const server = async () => {
  const app = express();

  app.get("/", (req, res) => {
    res.send("Hello World!");
  });

  const server = createServer(app);

  server.listen(4000, () => {
    console.log(`Server running in 4000`);
  });
};

In index.ts, call the server to start it:

import { server } from "./server";

server();

Now, when you run your entry point (index.ts), it will call the server and create an Express app.

TypeScript Configuration

To install and configure TypeScript for your project, run the following commands:

pnpm i typescript
npx tsc --init

The tsc --init command will generate a tsconfig.json file with default settings, which you can keep as is.

Defining Scripts

With everything configured, you can create scripts for building and starting your server. Open your package.json and add the following scripts:

"scripts": {
    "build": "swc src --out-dir dist",
    "start": "node dist/index.js",
}

The build script will compile your project using SWC, and the start script will run the compiled application.

To start the server, simply execute pnpm run build and pnpm run start.

Development Workflow

For an improved development experience, you can use Nodemon to watch for changes in your project and automatically recompile and restart the server. To install Nodemon, run the following command:

pnpm i -D nodemon

Then, add a dev script to your package.json for watching changes and restarting the server:

"scripts": {
    "build": "swc src --out-dir dist",
    "start": "node dist/index.js",
    "dev": "nodemon --watch src --ext ts --exec 'npm run build && npm start'"
}

With this setup, you can use the pnpm run dev command to run your server in a development environment. Nodemon will watch for changes in your TypeScript files and automatically rebuild and restart the server, making your development workflow more efficient.

That's it! You now have an Express application with TypeScript and SWC, configured for both development and production environments. Happy coding!

Github project: https://github.com/vinibgoulart/swc-express-typescript

Updating Service Workers in Production

Vinicius Blazius Goulart — Fri, 27 Oct 2023 11:48:47 +0000

Service Workers are powerful tools within web browsers that enable a plethora of offline operations, including caching, real-time notifications, geolocation handling, and more exciting features. However, due to their separation from web applications and their role as proxy servers between connections, dealing with them in production can be quite challenging, especially when it comes to managing browser caches.

How to Update a Service Worker in Production?

There are several reasons why you might need to update a service worker in production. Consider a scenario where you want to change the path of your service worker. You previously had a service worker that only worked within the login path of your application, but now you want it to function globally.

In such cases, it's crucial to ensure that two services aren't running concurrently on the same routes, to avoid operational duplication. To address this, you can execute the following code in the entry point of your application:

if ('serviceWorker' in navigator) {
    const registrations = await navigator.serviceWorker.getRegistrations();

    const oldSw = registrations.find((registration) =>
      registration.active?.scriptURL.includes('/login/sw.js'),
    );

    if (oldSw) {
      oldSw.unregister();
    }

    navigator.serviceWorker.register('/sw.js');
}

With this code, you can identify a service worker running on a specific path, unregister it, and then re-register it with the desired path. This ensures that the service worker previously registered under /login is no longer active and allows the one registered under / to handle all the tasks.

Ensuring All Users Have the Updated Version

You can also ensure that browsers update all service workers without waiting for the entire application to restart:

self.addEventListener('install', (event) => {
  event.waitUntil(self.skipWaiting());
});

However, this action is not always recommended. It's best to wait for the complete service worker lifecycle to occur correctly. Use this approach only if your change won't result in a breaking change for the client, and avoid using it for significant changes.

Updating service workers in production requires careful planning and consideration of how changes might impact user experience. By following these best practices, you can efficiently manage service worker updates and enhance the performance and reliability of your web applications.

Photo by Joshua Rawson-Harris on Unsplash

Enhancing Test Clarity and Diagnostics in Abstractions

Vinicius Blazius Goulart — Tue, 15 Aug 2023 13:31:00 +0000

At Woovi, we strongly believe in maintaining high testing standards as an important part of our development approach. We make sure to include tests along with our features, and by using different simplifications, we ensure that we can quickly and safely put these tests together.

For both our front-end and back-end systems, we mainly use Jest as our primary testing tool. This flexible tool helps us thoroughly check how well our software parts work. Furthermore, we've created specific functions for each environment that make our testing process smoother.

The Importance of Error Stack Traces

The error stack trace is a crucial tool for diagnosing issues in our development work. It gives us valuable information about why failures happen and helps us find ways to fix them. For example:

it("should sum two numbers", async () => {
  expect(1 + 2).toBe(4);
});

In this basic example, we intentionally make a mistake. The error message that comes up won't just show that something went wrong, but it will also show exactly where the mistake happened. This makes it easier to figure out and fix the problem.

Introducing Abstractions

To demonstrate the utility of abstractions in testing, consider the following code segment:

const assertSum = (numbers: number[], result: number) => {
  const [x, y] = numbers;
  expect(x + y).toBe(result);
};

it("should sum two numbers", async () => {
  assertSum([1, 2], 4);
});

In this case, we've put the test steps inside the assertSum function, which makes it easier to reuse the code. If something goes wrong, the error message it gives will be like this:

At first glance, it looks like a useful message, it's easy to find which test broke since we only have one.

Navigating Complexity

In real-world scenarios, our codebases encompass multiple tests and numerous operations. For example:

const assertSum = (numbers: number[], result: number) => {
  const [x, y] = numbers;
  expect(x + y).toBe(result);
};

it("should sum two numbers", async () => {
  assertSum([1, 2], 3);
  assertSum([1, 6], 7);
  assertSum([9, 2], 4);
  assertSum([4, 6], 12);
});

it("should sum two numbers with two decimal places", async () => {
  assertSum([12, 21], 89);
  assertSum([16, 65], 80);
  assertSum([91, 20], 111);
  assertSum([40, 62], 102);
});

In these complex situations, doesn't this message tell us exactly where it broke, at which assertSum did it break? in which line? in a scenario closer to reality, you use your abstractions in several of your tests, and failing with that message only makes the situation worse, you don't know for sure which line failed, which of the operations failed.

Enhancing Error Diagnostics

To make our abstractions even better at diagnosing issues, we use a try-catch block:

const assertSum = (numbers: number[], result: number) => {
  const [x, y] = numbers;

  try {
    expect(x + y).toBe(result);
  } catch (error) {
    Error.captureStackTrace(error as Error, assertSum);
    throw error;
  }
};

This is the output:

This improvement makes the error stack trace more detailed, giving a complete picture of where the error happened, what was expected, and what actually occurred. This leads to a thorough diagnostic output that helps developers quickly solve the problem.

Why to abstract the `expect`

You can have an abstraction with expect in cases where you will always check the same data.

A more realistic example would be where you mock a mutation operation and ensure that the name of the next operation to be executed is the name you expect.

export const assertOperation = <T extends OperationType>(
  environment: RelayMockEnvironment,
  name: string,
) => {
  const queryOperation = environment.mock.getMostRecentOperation();

  const operationName = queryOperation.root.node.name;

  try {
    expect(operationName).toBe(name);
  } catch (error) {
    Error.captureStackTrace(error as Error, assertOperation);

    throw error;
  }
};

In Conclusion

At Woovi, our approach to testing focuses on being thorough, using abstractions, and being precise in diagnosing issues. With the help of Jest and carefully designed abstractions, we enable our development teams to create strong and top-notch software that not only meets but consistently goes beyond
expectations.

Woovi is a Startup that enables shoppers to pay as they please. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

Photo by David Travis on Unsplash

The tests are part of the feature

Vinicius Blazius Goulart — Wed, 02 Aug 2023 14:06:33 +0000

At Woovi, we make a lot of changes every day, whether they involve new features or fixes. We have a strict policy that all of our pull requests must include at least one test to validate the implemented feature or fix.

To maintain a seamless process of continuously shipping to production, it is essential to ensure that everything continues to work as expected. Therefore, we always deliver Pull Requests with associated tests to validate that the changes make sense and function correctly.

A Pull Request lacking tests indicates that either the modifications made do not have any existing tests or that they are not functioning as intended. In both cases, we adhere to the culture that a Pull Request must have tests attached to it.

We follow the culture of creating small Pull Requests. Each commit is clearly defined and has a specific purpose. By incorporating tests with each Pull Request, we can better understand the impact of each commit and easily identify the scenarios it affects. This approach significantly simplifies the reviewing process for our team.

We have implemented a range of powerful tools and processes here at our company, including an automated testing system to ensure the effectiveness of code changes.

Firstly, we retrieve the files that have been modified using the following code:

const getStagedFiles = async () => {
  const output = execSync('git diff --name-only --cached', {
    encoding: 'utf-8',
  });

  return output.trim().split('\n');
};

Once we have the modified file list, we delve into each file's directory to locate the associated test files. We look specifically for the tests folder, which houses our tests. Any .spec.ts or .spec.tsx files we find will be added to the array of files to be tested:


const findTestFiles = async (filePaths: string[]) => {
  const testFiles: string[] = [];

  for (const filePath of filePaths) {
    const fileDirectory = path.dirname(filePath);
    const testDirectory = path.join(fileDirectory, '__tests__');

    try {
      const files = await fs.readdir(testDirectory);
      const testFilesInDir = files.filter(
        (file) => file.endsWith('.spec.ts') || file.endsWith('.spec.tsx'),
      );

      testFiles.push(
        ...testFilesInDir.map((file) => path.join(testDirectory, file)),
      );
    } catch (err) {
      // Ignore if __tests__ directory does not exist
    }
  }

  return testFiles;
};

And finally, we run these tests:


const runTests = async (testFiles: string[]) => {
  if (testFiles.length === 0) {
    //eslint-disable-next-line
    console.log('No tests to run.');

    return;
  }

  const testFilesArg = testFiles.join(' ');

  try {
    execSync(`TZ=utc yarn test ${testFilesArg}`, { stdio: 'inherit' });
  } catch (err) {
    //eslint-disable-next-line
    console.error('Some tests failed.');
    process.exit(1);
  }
};

By automating this process, we can effortlessly include tests with every Pull Request we make. Whether modifying an existing test to accommodate a new flow or introducing a completely new test, the system facilitates the validation of these changes.

With these advanced automation practices in place, we are confident in the quality and reliability of our codebase. This enables us to ship faster to production while maintaining a high level of confidence in our software.

Woovi is a Startup that enables shoppers to pay as they please. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

Photo by Ryoji Iwata on Unsplash

Testing Mutations with Relay in Frontend

Vinicius Blazius Goulart — Tue, 25 Apr 2023 16:38:44 +0000

Mocking mutations in your test is the best way to test the behavior of your components after doing some mutation operation, with this we can check if an operation performed successfully as expected.

Mutation is every operation that inserts, updates or deletes data on our server. So we need to test if after deleting something it will be removed from the screen, same for inserts.

Imagine we have a page that render a user and a button to delete this user from your database. Ee start from the principle that you already have the user query and the mutation to remove created. Let's just focus on the tests.

Install the required packages:

yarn add relay-test-utils

First, create a simple test rendering the user from UserQuery, and check if the username is rendered on the screen.

import {
  fireEvent,
  render,
  screen,
  waitFor,
  act,
} from "@testing-library/react";
import { createMockEnvironment, MockPayloadGenerator } from "relay-test-utils";
import { RelayEnvironmentProvider } from "react-relay";

import Component from "../Component.tsx";

it("should remove a user", async () => {
  const user = { id: "1", name: "Vinicius" };

  const environment = createMockEnvironment();

  render(
    <RelayEnvironmentProvider environment={environment}>
      <Component />
    </RelayEnvironmentProvider>
  );

  const customMockResolvers = {
    Query: () => ({
      User: user,
    }),
  };

  act(() => {
    environment.mock.resolveMostRecentOperation((operation) =>
      MockPayloadGenerator.generate(operation, customMockResolvers)
    );
  });

  expect(screen.getByText("Vinicius")).toBeInTheDocument();
})

Find the delete button on screen and fire a click. I will search by data-testid attribute.

it("should remove a user", async () => {

  ...

  const deleteButton = await screen.findByTestId("delete-button");
  fireEvent.click(deleteButton);
});

Now create the mutation variables and assert the data between the most recent mutation and the expected mutation. After that, mock the mutation using the relay-test-utils package.

it("should remove a user", async () => {

  ...

  const variables = {
    input: {
      userId: "1",
    },
  };

  const mutationOperation = environment.mock.getMostRecentOperation();

  const operationVariables = mutationOperation.fragment.variables;

  expect(operationVariables).toEqual(variables);

  const mutationMockResolvers = {
    Mutation: () => ({
      RemoveUser: {
        error: null,
        success: "User removed successfully",
      },
    }),
  };

  act(() => {
    environment.mock.resolveMostRecentOperation((operation) =>
      MockPayloadGenerator.generate(operation, mutationMockResolvers)
    );
  });

  expect(screen.queryByText("Vinicius")).not.toBeInTheDocument();
});

Finnaly, check if the user was removed from the screen.

it("should remove a user", async () => {

  ...

  expect(screen.queryByText("Vinicius")).not.toBeInTheDocument();
});

Woovi is a Startup that enables shoppers to pay as they please. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

Photo by serjan midili on Unsplash

How to monitor an app in production using Discord channels

Vinicius Blazius Goulart — Mon, 03 Apr 2023 14:34:05 +0000

Observability is an extremely important practice for you having an idea of what is happening in your app and receive updates from new interactions.

We will see how to send new messages to a discord channel, this allows us to monitor interactions in production of our application, such as a new api call, a new login, or even a new record in the database.

In this example we will monitor a route and at each call to it you want to send a message to discord with some data.

If you do not create a project yet, just run yarn init -y to create a new.

Install some dependencies:

yarn add express axios nodemon

Create a discord channel that will be used to monitor and receive new updates. After creating it, we need to create a new webhook for this channel. Go to Server Settings > Integrations > Webhooks > New Webhook, then select the created channel and copy the link.

Go back to code... create a config.js file to define our variables:

export const config = {
  API_PORT: 4000,
  DISCORD_CHANNEL_WEBHOOK: <your discord channel webhook>,
};

Create a new express server with a simple route:

// index.js
const express = require('express')
const { config } = require('./config')
const axios = require('axios')

const app = express()

app.get('/observability', async (req, res) => {
  await axios.post(config.DISCORD_CHANNEL_WEBHOOK, { content: 'Hello World' }, {
    headers: {
      Accept: 'application/json',
      'Content-Type': 'application/json',
    }
  })
  res.send('observability done successfully')
})

app.listen(config.API_PORT, () => {
  console.log(`Server listening on port ${config.API_PORT}`)
})

Will be made a POST for this discord channel webhook with the content.

Let's run the code, open the terminal and run nodemon index.js

Now, if you access this url localhost:4000/observability you will see it:

And if you check your discord channel it has something like this:

And that's it, we have a log and observability system, feel free to run this webhook at any time in your code that you want to follow the status in production.

See the repository using typescript here: observability-with-discord

See more in my zettelkasten

Foto de Marten Newhall na Unsplash

Getting formik dirty values on submit

Vinicius Blazius Goulart — Thu, 30 Mar 2023 13:54:07 +0000

Formik is a react library to build forms, you register the values and send them in your onSubmit function. If you have an API Route that does a put, everything goes right, but you send more data than necessary in a patch.

So, how to get only dirty values in formik?

To do this, we need to compare it's current value on submit with it's initial value.

Let's start configuring formik data:

type PersonParams = {
  name: string;
  age: string;
};

const person = {
  name: 'vinicius',
  age: '19',
};

const Component = () => {
  const onSubmit = async (values: PersonParams) => {
    const payload = values;
  }

  const formik = useFormik<PersonParams>({
    initialValues: {
      name: person.name,
      age: person.age,
    },
    onSubmit,
  });

  const { initialValues } = useFormik(formik)
};

The form starts with name = 'vinicius' and age = 19. Now, imagine the user changes age to 20 and submits the form. All fields will be sent, including name which has not been changed.

Now let's create a function to get only dirty values:

const getDirtyValues = <T>(values, initialObject: T): object => {
  const data = { ...values };
  const keyValues = Object.keys(data);

  const dirtyValues = keyValues.filter(
    (keyValue) => data[keyValue] !== initialObject[keyValue],
  );

  keyValues.forEach((key) => {
    if (!dirtyValues.includes(key)) delete data[key];
  });

  return data;
};

export { getDirtyValues };

The function compares the current value with the initial value, if it is equal, it deletes.

Now instead submit all values, we call getDirtyValues function to get only dirty values.

const onSubmit = async (values: PersonParams) => {
    // payload = { age: '20' }
    const payload = getDirtyValues<PersonParams>(values, initialValues);
  }

That it's all, now we can get only the dirty fields and send them in our patch.

Gist: https://gist.github.com/vinibgoulart/845aefd6cd5c086417c7933e6760fbc6

See more in zettelkasten

Foto de No Revisions na Unsplash

How learning in public helped me in my journey

Vinicius Blazius Goulart — Mon, 13 Mar 2023 12:11:53 +0000

Learning in public became a lifestyle adopted for me last year when I started learning software development. If you don't know what it is or don't do, I strongly recommend starting as soon as possible.

This is probably the main reason why I know what I know today and how quickly I have increased my knowledge.

I would say I move faster than most who started studying with me, and one of the reasons for that was learning in public.

You can learn more about my thoughts in my zettelkasten.

Today, I'm here to share how this lifestyle helps me combine creating a product with learning a new technology.

The mindset

I have a "job" where I create a list of names for an event, but all this work was done manually, and I didn't like it. I was wasting a lot of time, and there were usually some mistakes.

I had a goal of learning new JavaScript frameworks such as KoaJS and RelayJS. Moreover, I had a few side projects, and I had rarely used other frameworks like Next.

I had a pain point and a goal, and I just combined them and made good use of my time.

I basically started from scratch on both challenges. I had never managed a product and didn't know anything about it, and I had never worked with these frameworks before.

What most people would do in this situation;

Not create a product because they're too inexperienced in the area;
Create a lot of unusual side projects before;
Wait for the best moment (which doesn't exist);
Be afraid to fail;
Give up halfway;

My thought was the opposite; I knew that in the end, I would acquire a lot of knowledge.

How I started

As I knew and admitted that I had no knowledge in the area, I needed to find a way to acquire that knowledge. I needed a way to move faster, to move consciously and correctly. And that's where learning in public came in.

Github

Most of what I learned about the technologies was by looking at other people's code on GitHub. I studied and saw how the code worked, how it ran, and why that code was there. I tried to get content from people I knew were good and believed in their potential to have written good code so I could learn from it.

Much of the base technologies I learned there; I say "base" because it is difficult to have an open-source system/product that would give me everything about the product I want to build.

Looking for issues and discussions in the technology project was also crucial. As I was learning, my doubts had most likely already been answered in some issues. Also, I learned a lot by watching people's discussions and problems.

Community

Having contact with a community of good developers was essential. I sought and followed people who dealt with what I was looking for.

Twitter

I posted my doubts on Twitter, and many people helped me. I wasn't afraid to ask stupid questions or something like that because, after all, my doubt could be someone else's in the future. Additionally, I found answers to my doubts in issues on GitHub or in other tweets.

Discord

On Discord, I had a more direct interaction with other developers, being more focused on chat. Discord provided a fluid and quick discussion on subjects.

Finn

After doing all these things, I learned a lot about how to achieve my goals, but I hadn't worked on a real project using these technologies. Then came the Finn, an idea and project by Danilo Assis, tech lead at Woovi, who proposes mentoring in a real project. Finn helped me on how to work well and following good practices with the technologies I learned... having access to a good, solid and organized code makes all the difference. In addition, I was able to learn the creation of the product and brand and how to deal with the problems that the product is trying to solve.

And that's how learn in public helped me extremely in moving quickly into topics I didn't know about.

I'm sure if I hadn't adepted this "lifestyle" I would still be doing projects consuming pokemon's API. Hahaha!

Finally, the Event List is a product in final stage of development, when it is ready I will update the link here! Landing page

Just do it
Ways to get knowledge
You shouldn't need to watch videos or lessons to learn something
blazu Thoughts

Foto de Manu Ros na Unsplash

Como escrever boas documentações na empresa

Vinicius Blazius Goulart — Thu, 01 Dec 2022 20:41:27 +0000

Estou criando este post baseado no The documentation system, mas por ele ser um artigo longo resolvi fazer um resumo dele com mais algumas coisas. Mas recomendo que você leia e estude este artigo, ele possui mais conteúdo e casos específicos com explicação e contexto para eles.

Tópicos

Uma boa documentação deve ter 4 tópicos principais:

Explicação: explicação discursiva
Referência: descrição seca
Tutorial: uma lição
Como fazer: uma série de passos

créditos: The documentation system

Como fazemos na Highsoft?

Depois de escolher um tópico para escrever e documentar, a primeira coisa a fazer é a referência e a explicação. Primeiro deve-se fazer uma explicação literal do termo, e depois explicar como tal tópico funciona em nosso sistema.

Para criar o tutorial, pegamos o tópico em questão e explicamos o procedimento de ponta a ponta, de forma simples, rápida, básica e útil.

Devemos complementar então com o como fazer, onde tratamos de assuntos mais específicos e nos aprofundamos nas explicações

Adicionamos mais um tópico para possíveis avisos e a explicação deles. Como somos um ERP, é normal dispararmos avisos nas telas para informar o que está acontecendo, e temos um tópico para descrever esses avisos e apontar possíveis problemas que podem ocorrer.

Por final, temos isso:

Lembre-se de sempre se colocar no lugar do cliente e tentar entender as possíveis respostas que ele precisa:

como fazer isso?
O que é isso?
o que eu faço quando...?
por quê isso aconteceu?

Se sua documentação tem a resposta para essas perguntas, você tem uma boa documentação. Se não, basta adicioná-lo!

How to write good company docs

Vinicius Blazius Goulart — Thu, 01 Dec 2022 20:41:23 +0000

I'm creating this post based in The documentation system but since it is a long article I decided to create a summary with of it and a few more things. But I recommend you to read and study this article, it has more contents and specific cases with explanation and context for them.

Topics

A good documentation must have 4 main topics:

Explanation: discursive explanation
Reference: dry description
Tutorial: a lesson
How to Guide: a series of steps

credits: The documentation system

How we starting at Highsoft?

After picking a topic to write and document, the first thing to do is reference and explanation, which we did together. First we take a literal explanation of the term, and after that we explain how such a topic works in our system.

To create the tutorial, we took the topic in question and explained the procedure from end to end, in a simple, quick, basic and useful way

We must complement then with the how to guide, where we deal with more specific subjects and go deeper in the explanations

We added one more thread for possible warnings and the explanation of them. As we are an ERP, it is normal for us to trigger warnings on the screens to inform what is happening, and we have a topic to describe these warnings and point out possible problems that may occur.

Finally we have this:

Remember to always put yourself in the customer's shoes and try to understand the possible answers he needs:

how to do this?
what is it?
what do i do when...?
why did this happen?

If your documentation has the answer to these questions, you have a good documentation . If not, just add it!

Just do it

Vinicius Blazius Goulart — Wed, 23 Nov 2022 18:24:32 +0000

Maybe you read this title article and think "why is he using Nike slogan?", I'm using this slogan to explain and to emphasize something that people ignore, you should take this slogan more seriously.

Stop waiting or taking a very long way to do something, just do it.

This post is not about you buy something, spend money, swear at everyone, does radical things, or anything like that. But about your delay to something useful, and above all take initiative, go straight.

Don't ask to ask, just ask
Don't ask to innovate, just innovate and show it
Don't ask what code, just code something you like
Don't wait for someone to ask you the obvious, just do it before
Don't wait for someone's answer, just find the answer yourself
Don't wait for a hard issue, just create a hard issue
Don't wait a fire idea to write, just write something you like
Just answer your own doubt and take action

Don't depend on others, if you want to reach a goal, just follow the way.

Why just do it?

"Just do it" makes you more independent, adds more value to you, you learn to learn and take initiative, not depends on others.

You start to increase yourself productivity and people's vision of you'll improve, you lead yourself.

DEV Community: Vinicius Blazius Goulart

Integrating WhatsApp with Google Sheets

TLDR

Tooling

Entry point

Mongodb

Google Sheets

WhatsApp Api

Sheet Create

Deploy

Creating a express app with typescript and swc

Setting Up Your Project

Installing SWC

Setting Up Express

TypeScript Configuration

Defining Scripts

Development Workflow

Updating Service Workers in Production

How to Update a Service Worker in Production?

Ensuring All Users Have the Updated Version

Enhancing Test Clarity and Diagnostics in Abstractions

The Importance of Error Stack Traces

Introducing Abstractions

Navigating Complexity

Enhancing Error Diagnostics

Why to abstract the expect

The tests are part of the feature

Testing Mutations with Relay in Frontend

How to monitor an app in production using Discord channels

Getting formik dirty values on submit

How learning in public helped me in my journey

The mindset

What most people would do in this situation;

How I started

Github

Community

Twitter

Discord

Finn

Related articles:

Como escrever boas documentações na empresa

Tópicos

Como fazemos na Highsoft?

How to write good company docs

Topics

How we starting at Highsoft?

Just do it

Why just do it?

Why to abstract the `expect`