DEV Community: Lucas Andrade

You just need Postgres

Lucas Andrade — Thu, 26 Feb 2026 17:14:54 +0000

You've heard the advice: "Use the right tool for the right job." Sounds reasonable. Even wise. So you followed it. You picked Redis for caching, Elasticsearch for search, Kafka for messaging, MongoDB for documents, Pinecone for vectors, InfluxDB for time-series, and Postgres for... well, the relational stuff.

Congratulations. You now have 7 databases to maintain, 7 backup strategies to manage, 7 monitoring dashboards to watch, 7 security audits to run, and 7 monsters that can break at 3 AM.

The thing nobody talks about, cause it doesn't sell: that advice "the right tool for the right job" is the battle cry of every vendor's marketing department.

The uncomfortable truth is that PostgreSQL is not "just a relational database." It hasn't been for over a decade. It's a data platform that does what most of these specialized tools do, using the same algorithms, with a single connection string, a single backup strategy, and a single place to debug when everything breaks at 3 AM.

Not "close enough." Not "good enough at small scale." The same algorithms.

Redis
Elasticsearch
Pinecone
Kafka
MongoDB
InfluxDB

All these buzzwords, unless we're talking about truly unbelievable scale, are achievable with just Postgres.

Let me show you. Actually, no... simulate it and see for yourself.

https://youjustneedpostgres.com

Cleaning Github repositories, PRs and issues in bulk like a Pro

Lucas Andrade — Wed, 28 Jan 2026 13:04:43 +0000

Hey folks!

If you maintain multiple repositories or work with organizations on GitHub, you probably know the pain: closing stale PRs, deleting merged branches, managing Dependabot alerts, archiving old repos... It's tedious, repetitive, and takes time away from actual coding. And it's not possible to do that in bulk, I don't know why, and it bothers me.

So I built GitHub AutoMaintainer, a CLI tool in Go that automates all of this.

What it does

Close stale PRs automatically

automaintainer close-prs --org my-org --days 30

Closes PRs older than X days
Adds a comment explaining why
Supports --dry-run to preview changes

Delete merged branches

automaintainer delete-branches --org my-org --exclude main,develop

Cleans up branches already merged into default
Exclude specific branches from deletion

Close inactive issues

automaintainer close-issues --org my-org --days 90

Grace period with "stale" label before closing
Option to lock issues after closing
Filter by labels

Manage repositories in bulk

automaintainer repos list --org my-org --inactive 365
automaintainer repos archive --org my-org -i
automaintainer repos delete --org my-org -i

List repos with filters (inactive, archived)
Archive or delete in bulk
Interactive mode (-i) for visual selection

Handle Dependabot alerts

automaintainer security list --org my-org --severity high
automaintainer security dismiss --org my-org --severity low --days 180

List alerts by severity and state
Dismiss old low-priority alerts

Nice terminal UI

I used the Charmbracelet libraries to make the output actually pleasant:

Styled tables

┌────────────────────────┬───────────────┬────────────┐
│ REPOSITORY             │ LAST ACTIVITY │ STATUS     │
├────────────────────────┼───────────────┼────────────┤
│ my-org/api             │ 2024-01-15    │ ● active   │
│ my-org/legacy          │ 2022-03-10    │ ○ archived │
└────────────────────────┴───────────────┴────────────┘

Progress bars for long-running operations

Scanning repos [████████████████░░░░] 42/100 my-org/current-repo

Preview mode - select before executing

automaintainer close-prs --org my-org --preview

Opens an interactive TUI where you navigate with arrows, toggle with space, and confirm only what you want.

Other features

GitHub URLs as arguments

# Both work
automaintainer close-prs --org my-org
automaintainer close-prs https://github.com/my-org

Dry run mode - preview everything before making changes

Colored output - green for active, gray for archived, red for critical alerts

Installation

brew install olucasandrade/automaintainer/automaintainer

Or download the binary from releases.

Why Go?

Single binary, no dependencies
Cross-platform (Linux, macOS, Windows)
Great performance for bulk operations
Excellent CLI ecosystem (Cobra, Bubble Tea)

What's next

Full interactive dashboard
Label sync between repos
Exportable reports
GitHub Enterprise support

The code is fully open source: github.com/olucasandrade/homebrew-automaintainer

If you maintain repos, work with open source, or just want to automate boring GitHub tasks, give it a try and let me know what you think.

Issues, PRs, and suggestions are always welcome. The goal is simple: make life easier for those who already make life easier for others through code.

I've created a leetcode-like platform for system design

Lucas Andrade — Wed, 05 Nov 2025 13:12:22 +0000

For the past few weeks, I've been working on one of the coolest things I've ever pushed to production: a LeetCode-style platform for system design.

I've been writing about system design for a while now, and I genuinely love the topic (I talk about it weekly on my blog). I always wanted a tool to practice it without having to hunt down a billion references across the internet.

Every tool I found was either paywalled for the basics or completely abandoned. So, I built my own, and I have no intention of letting it go.

I believe this project has the potential to build a really great community. That's why I decided to "open-source" the entire platform. It's 100% open on GitHub, and I'm already creating issues for the next planned evolutions.

How this can help you:
The idea is simple: just like LeetCode, you can submit your solution (with a diagram + textual explanation), and you can view and interact with solutions from others. No favoritism here—I truly believe there's no better way to prepare for an interview or just sharpen your skills.

I don't plan to fully "productize" this until I hit my first major goal, so feel free to play around as much as you want, and please let me know if you find any bugs.

How you can help me:
First and foremost, dropping a star on the repository is a huge boost. That alone is massive support.

But if you want to help on a deeper level, feel free to open issues or even pull requests to add new features or work on existing ones. Honestly, the potential of this platform is not something I have enough bandwidth to explore alone.

Finally, spreading the word is also a big help. I want this to reach as many people as possible who need it.

Cheers!

The link to the app is: https://systemstudio.app

If it gets some traction, I'll share the next steps for the roadmap.

lesgo

I've created an automated Github Maintainer

Lucas Andrade — Mon, 13 Oct 2025 12:41:53 +0000

Over the last few days, I found myself doing something boring.

I was going through a few repositories at Criaway (my company), closing old PRs, deleting merged branches, and reviewing things that could have easily been automated.

That’s when the thought that always drives me came up again:

“If it can be automated, I’ll automate it.”

And that’s how GitHub AutoMaintainer was born — a CLI tool written in Go to automate repetitive GitHub maintenance tasks, such as:

Closing old pull requests automatically
Deleting merged branches
Running everything with --dry-run, colored logs, and structured terminal reports
Operating globally for an organization or targeting a specific repository

No YAML. No complex setup.
Just install it with Homebrew and start using:

brew install olucasandrade/automaintainer/automaintainer

This project came from a real need I had, but the goal is for it to grow with the community.

If you maintain GitHub repositories, contribute to open source, or simply care about productivity, take a look and let me know what you think.

Check out the repository here.

What’s next?

I’m planning for the upcoming versions:

Label synchronization across repositories
Automatic removal of inactive collaborators
Safe detection and deletion of unused repositories (still exploring the best approach)
Improved Homebrew integration

Every suggestion, pull request, or piece of feedback is welcome.
The goal is simple: make life easier for those who already make life easier through code.

[PITCH] I built an online API Client (an alternative to Insomnia)

Lucas Andrade — Thu, 20 Feb 2025 15:04:15 +0000

For those who don’t know me: I’m kind of a madman, been developing software for 4+ years, and I often create random projects based on some brief pain I experience. The latest one is Trevo.rest, an online API Client I built because I was tired of opening a full-blown app on a slow PC just to send a simple request.

The other day, I had an issue with bomdemorar.com while I was out. If I could’ve tested the API from my phone—my god, life would’ve been so much easier.

So I thought: why not build a lightweight, straightforward API Client that runs entirely in the browser?

And just like that, Trevo was born. Open the site, and boom—you can send requests, test your APIs, and move on with your day. No downloads, no hassle.

Besides the basics, I’m already working on some cool upgrades:

✅ Request history to make life easier
✅ Better UX for saving and organizing requests
✅ WebSocket support (because real-time testing should be simpler)
✅ Collection export/import

I built this to solve my own problem, but if others find it useful, even better! No login required, fully online, and with request history. You can try it out right now at www.trevo.rest 🚀

Streamlining Development Workflow: Automating Tasks with GitHub Actions

Lucas Andrade — Tue, 25 Jun 2024 13:04:24 +0000

During the entire development process, from code to deployment, we encounter many repeated processes: updating snapshots, running unit tests, deploying to staging, completing production deployments... all these types of processes will inevitably become part of every task developed, without exception.

And like everything in life, it doesn't make sense to do something repetitive when you can automate it. Moreover, it doesn't make sense to work on improving other people's experiences without making our own lives easier, saving our time.

There are MANY tools that help automate your development process (a practice known as CI/CD), and one of them is directly tied to the main platform for those who work with software: GitHub.

Therefore, in this article, we will learn a bit more about GitHub Actions, so we can create, customize, and share automated workflows directly in the repository.

What is GitHub Actions?

GitHub Actions is a CI/CD service provided by GitHub. It allows you to automate various tasks in software development, such as testing, building, deployment, and much more. GitHub Actions is event-based, where each action is triggered by specific events, such as code pushes, pull request creations, or predefined schedules.

In this example above, we have an Express project with a MongoDB database. Here, as soon as we open a pull request, the pipeline defined with the help of GitHub Actions will run all the tests created in the API, in different versions of Node and the MongoDB driver (first and second number in parentheses, respectively).

Workflows

Workflows are the main units of automation in GitHub Actions. They are defined through YAML files that can be configured to respond to specific events or execute schedules. The file specifies the actions to be executed, in which environment, and in what order. These workflows can be easily configured and customized to meet the specific needs of a project.

Actions

Actions are the reusable components that make up a workflow. They are the fundamental building blocks of GitHub Actions. Actions can be created by the community or the development team and shared with other users. There are pre-made actions available on the GitHub Marketplace, as well as other custom actions that can be developed internally. Actions can be combined to create complex and customized workflows.

*Creating Our Workflow
*

In a project, let's start by going to the "Actions" tab and clicking on "set up a workflow yourself";

Now, we can define the details of the YAML file on the next screen, that is, the definition of our workflow. On the right, we can see that GitHub Actions has a marketplace with several well-known and pre-made workflows (consider using this option to find a useful one and enhance it);

We can define the events that will trigger the workflow. For example, to trigger the workflow whenever a push occurs on the main branch, we can do something like this:

on:
  push:
    branches:
      - main

Then, we add the steps that will be executed in the workflow. For example, let's add a step to install the project's dependencies and another to run the tests. In this case, we would do:

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Install dependencies
      run: npm install

    - name: Run tests
      run: npm test

Where:

jobs defines the tasks to be executed in the workflow. You can have multiple jobs within a workflow, allowing different actions to be executed simultaneously;
build is the name given to the job. You can give a descriptive name to each job in your workflow, such as "build", "test", "deploy", among others;
runs-on specifies the environment in which the job will be executed. In this example, we are using "ubuntu-latest", which is an Ubuntu operating system image in the most recent environment available on GitHub Actions. There are other options available, such as Windows and macOS;
steps defines the individual steps that will be executed within the job;
name is the name given to each step. It serves to identify the step in the workflow execution log, making it easier to understand what happens at each step;
uses specifies a marketplace action that will be used in the step. In the given example, we are using the actions/checkout@v2 action, which allows checking out the repository's source code; run executes commands or scripts in the step. In the given example, we are using the npm install command to install the project's dependencies and npm test to run the tests.

The definition of the YAML file can also be done directly in your development environment; I just exemplified it with the more user-friendly approach.

GitHub Actions usage examples

The test example is the most basic, but there are countless ways to leverage the power of GitHub Actions to automate tasks in a development workflow. Some common examples include:

Continuous deployment to a production environment after a pull request approval;
Automatic generation of documentation from the source code;
Notifying the team about changes or issues in the repository;
Performing routine tasks such as database cleaning or backup creation.

Github Actions Pros

Seamless integration with GitHub: As a native GitHub feature, GitHub Actions integrates perfectly with the existing workflow and allows direct automation in the repository;
Flexible configuration: Workflows can be easily configured and customized to fit the specific requirements of the project;
Wide variety of actions: The GitHub Marketplace has a wide range of pre-made actions that can be used, covering various technologies and use cases;
Efficient collaboration: Automated workflows facilitate collaboration among team members.

Simple, right? Did you like the tip? Leave your suggestion or comment and see you next time!

Boosting your code with Python Decorators

Lucas Andrade — Thu, 22 Feb 2024 12:16:30 +0000

There are various programming concepts that spread across different languages. One of them is the decorator, which exists in Python. In this article, we'll understand why to use it, how it works, and the different applications of decorators with Python.

What is a decorator?

A decorator is a feature that allows modifying or enhancing the behavior of functions, methods, or classes.

They are functions that wrap around other functions to extend or modify them, adding behaviors without modifying the original code of the function.

So imagine there are different functions going through the same step, but not necessarily a step that is part of the logic of the function itself. It's in this context that we'll use decorators.

Still confused? Be relax, I'll start with some basic examples! But first, let's understand how the syntax of a decorator works.

How to declare a decorator?

A decorator in Python is created using the following syntax: you define a function that will act as the decorator and also receives a function as an argument. Inside it, we'll return another function that, in addition to executing the original function, will concentrate all the "extended" behavior. The syntax looks like this:

def decorator(func):
  def innerFunction():
    # additional behavior
    print('Hello world')
    func()
  return innerFunction

How to call a decorator?

The syntax for calling a decorator is also simple. Basically, we use the symbol '@' followed by the name of the decorator function. This is placed above the function, method, or class you want to modify.

When the "decorated" function is called, it is replaced by the modified version returned by the decorator:

@decorator
def sum(a, b):
  return a + b

print(sum(2, 2)) # 4
                 # Hello world

Importance of functools.wraps in decorators

In my examples below, I'll use the @wraps decorator from functools to declare the decorators. Decorators are usually declared like this to preserve the metadata of the original function. When you define a decorator without wraps, you may lose important information about the original function. This can affect, for example, the documentation of the function and access to specific attributes of it.

Let's use an example of a decorator without functools.wraps:

def decorator_without_wraps(func):
    def inner_function(*args, **kwargs):
        print('This is a decorator')
        return result
    return wrapper

@decorator_without_wraps
def hello_world():
    print("Hello")

hello_world() # This is a decorator
              # Hello
print(hello_world.__name__) # inner_function

Note that if I wrap the function in a decorator without wraps, the decorator will assume all the metadata of the decorated function.

Using wraps, the entire signature of that function remains:

from functools import wraps

def decorator_with_wraps(func):
    @wraps
    def inner_function(*args, **kwargs):
        print('This is a decorator')
        return result
    return wrapper

@decorator_without_wraps
def hello_world():
    print("Hello")

print(hello_world()) # This is a decorator
                     # Hello world
print(hello_world.__name__) # hello_world

Examples of decorator usage

@timer

import time
from functools import wraps

def timer(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        result = func(*args, **kwargs)
        end = time.perf_counter()
        print(f'{func.__name__} took {end - start:.6f} seconds to complete')
        return result
    return wrapper

In this case, the timer function is defined as a decorator. Inside it, there is an inner function called wrapper. This function accepts any number of positional and named arguments.

Next, the start time of the execution of the original function using time.perf_counter() is measured.

The original function (func) is then called with the arguments passed to wrapper, and the result is stored. The end time of the execution is recorded using time.perf_counter() again.

A message is printed, indicating the name of the function and the time it took to execute, formatted with six decimal places. Finally, the result of the original function is returned:

import requests

@timer
def generate_lorem_ipsum():
    rootApi = 'http://asdfast.beobit.net/api/'
    response = requests.get(rootApi).json().get('text')
    return response

generate_lorem_ipsum() # generate_lorem_ipsum took 1.063780 seconds to complete

Note: here and in the other decorators, I'm using *args and **kwargs in the decorator parameters. This is to allow functions that accept a variable number of arguments and pass these arguments forward smoothly. You can read more about it here.

@repeat

def repeat(num_times):
    def decorator_repeat(func):
        def wrapper_repeat(*args, **kwargs):
            for _ in range(num_times):
                value = func(*args, **kwargs)
            return value
        return wrapper_repeat
    return decorator_repeat

Note that this decorator is wrapped in another wrapper, and this is because it receives a parameter. The outer function repeat accepts num_times as an argument and returns the inner function decorator_repeat.

Inside decorator_repeat, which is the decorator itself, the inner function wrapper_repeat is defined. This function, in turn, wraps the execution of the original function in a loop, repeating it num_times times.

The for loop iterates the number specified by num_times, calling the original function func on each iteration. The result of the last call is stored in value. Finally, wrapper_repeat returns this value, representing the result of the last execution of the original function after all repetitions:

@repeat(num_times=3)
def hello_world():
    print('Hello world')

hello_world() 
# Output:
# Hello world
# Hello world
# Hello world

@login_required

from functools import wraps
from flask import abort, request
from services import validate_token

def login_required(func):
    @wraps(func)
    def inner_function(*args, **kwargs):
        if not validate_token(request.headers.Authorization):
            return abort(401)
        return func(*args, **kwargs)
    return inner_function

This is an example for a Flask API, but it can be adapted for any Python API. The login_required decorator is designed to ensure that only authenticated users can access certain routes or functions in your application.

Inside the decorator, the inner function inner_function is defined. This function performs an authentication check before allowing the execution of the original function. If the Authorization header is somehow invalid, access is denied with an HTTP response code 401.

If the authentication check is successful, the original function (func) is called with the passed arguments. This decorator can be applied to specific routes in a Flask application, ensuring that only authenticated users have access, improving the security of the API. This approach is easily adaptable to other Python APIs, providing an effective means of protecting sensitive resources:

@app.route('/protected')
@login_required
def protected():
    return 'Protected route'

@rate_limit

from functools import wraps
from redis import Redis
from datetime import datetime, timedelta

redis = Redis(host='127.0.0.1', port=6379)

def rate_limit(limit, per):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            key = f'{request.remote_addr}:{func.__name__}'
            count = redis.get(key)
            if count is not None and int(count) > limit:
                reset_time = datetime.now() + timedelta(seconds=per)
                headers = {'X-RateLimit-Reset': reset_time
                           .strftime('%Y-%m-%d %H:%M:%S')}
                return Response(status=429, headers=headers)
            redis.incr(key)
            redis.expire(key, per)
            return func(*args, **kwargs)
        return wrapper
    return decorator

This decorator is much more complex, using Redis and also receiving parameters. It should be used in an API context and is also highly adaptable.

The rate_limit decorator is designed to apply rate limits to a function in an API, controlling the number of times it can be called within a certain interval. It uses Redis as an external storage to keep track of the number of allowed calls.

By receiving the limit (maximum call limit) and per (time period in seconds) parameters, the decorator creates an inner function called wrapper. Within this function, a unique key is generated using the remote client's address and the name of the original function. This allows tracking the number of calls made by a client for a specific function.

The counter associated with the key is retrieved from Redis, and if the number of calls exceeds the defined limit, a 429 (Rate Limit Exceeded) response is returned with a header indicating the reset time.

If the rate limit is not exceeded, the counter in Redis is incremented, and the key is set to expire after the per period, ensuring that the counter is reset after the defined interval.

Finally, the original function (func) is called with the passed arguments.

This decorator is highly adaptable and can be applied to different functions in an API, especially to enforce access limits to certain routes, preventing DDoS attacks:

@app.route('/limited')
@rate_limit(limit=10, per=60)
def limited_route():
    return 'You are within the rate limit!'

Advantages of Decorator

As you may have noticed in these examples, the decorator has numerous advantages in Python. Among them, we have:

Modularity Improvement: Decorators can be useful for separating specific concerns and improving code modularity. By applying decorators appropriately, it's possible to isolate specific functionalities, making it easier to maintain and understand each component.
Code Reusability: the use of decorators can promote code reuse since certain functionalities can be encapsulated and applied to various functions. This can reduce code duplication and facilitate the application of consistent patterns in different parts of the system.
Ease of Adding Functionality: Decorators offer a flexible way to add functionality to existing functions without directly modifying the source code of the function. This can be useful for incorporating new features or behaviors without affecting existing code.

Risks of Decorator

Like everything in programming, the decorator also has its risks and dangers. These are:

Traceability Loss: Depending on the context, decorators can make code traceability difficult, making it challenging to understand the origin of modifications and identify the behavior of a decorated function.
Excessive Dependency: Intensive use of decorators can create dependencies between functions, increasing complexity and making maintenance difficult, especially when many decorators are applied in various parts of the code.
Confusion in Decorator Chains: by putting many decorators in a single function, reading the order of application and understanding the execution flow can cause potential confusion in the execution logic.

When using a decorator, it's important to keep it simple, readable, tested, and well-applied, avoiding excessive use, which can become a bad practice.

Well, thank you for reading! I hope I've helped you better organize your journey. Well, if you have any suggestions or useful decorators to mention and contribute to the community, don't forget to leave your comment!

Until next time!

Writing and "publishing" your first package in Go

Lucas Andrade — Tue, 30 Jan 2024 12:14:05 +0000

For a few months now I've been venturing into Go on my company projects. I have much more experience with Javascript/Typescript on the frontend, and on the backend and when writing scripts, I have much more experience with Python. So I'm trying to get used to some of Go's quirks, but there are many reasons why I chose Go as my main personal language. I will leave those reasons for another article.

Oh, I swear, it's not because of the cuteness of the mascot...

...but look at this...

Anyway!

Recently I wrote a package that analyzes some data from an url and returns a relation with that data:

{ "LoadTime":"488.837125ms","HTTPRequestsCount":3,"PageSize":53 }

You can check out and use this package here.

In detail, it's not the focus of this article to explain why the package was made, how it was made, how to develop it... My goal is for this reading to end with you understanding how to release a package in Go, so that you can release any package you want.

But without further ado, let's go step by step!

Disclaimer: I'm assuming in this step-by-step guide that you've already created a Go project, whether it's a simple one or a more complex API, so I'll spare you some basic explanations.

Step 1: Defining and creating your package

Let's start with the basics, which is creating the package in Golang. In the example in the article, I'll explain it as if I were creating the package I've already created, url-analyzer itself.

In theory, everything you create in go is a "package". So the first step will be no different from what is already done in any project, which is to start the package in go inside the project folder, either by cloning a repository created on Github, or by creating a folder directly with the project name:

go mod init github.com/your-username/url-analyzer

It will create a go.mod in your package with something like that:

module github.com/your-username/url-analyzer

go 1.21.5

Step 2: Creating your package features

In the root of your project, create a file for the package that contains the functions, classes, or types you want to import externally. It can be called main.go, but it's recommended to create it with the name of your package, since it's not a program to run on its own, so I created a folder called url-analyzer, which contains the only method in my package:

package url_analyzer

import (
 "github.com/olucasandrade/url-analyzer/models"
 "github.com/olucasandrade/url-analyzer/services"
)

func Analyze(url string) (*models.PerformanceData, error) {
    as := &services.AnalyzerService{}
    return as.AnalyzeURL(url)
}

In my case, I use other folders for the architecture, such as models, services, and helpers, to facilitate unit testing and organization (you can see more at the repository link), but the same logic applies to any project, even if it's a method that adds two values.

Step 3: Publish your package on Github

With the package itself already created, we just need to follow the steps to host it correctly in your repository. In my case, I used Github.

It's no different than uploading any code:

git add url-analyzer
git commit -m "..."
git push origin main

Unlike Python with Pypi and Node with npm, in Go the download of a package happens directly where it is hosted, making life much easier for those who publish the package.

That's it! Your package is now public and available to everyone.

Importing and Testing Your Package

As mentioned above, in Go, downloading a package happens right where it is hosted, so we can create a project for testing in the same way:

go mod init github.com/your-username/url-analyzer-tests

Then get the package with go get:

go get github.com/olucasandrade/url-analyzer

and in the main.go folder I'll test if my method Analyze works correctly:

package main

import (
  "fmt",
  "github.com/olucasandrade/url-analyzer"
)

func main() {
  response, err := url_analyzer.Analyze("www.criaway.com")
   if (err != nil) {
    panic(err)
   }
  fmt.Println(response.HTTPRequestsCount, "-", response.LoadTime, "-", response.PageSize)
  // 3 - 114.285791ms - 53
}

I hope you like it! As mentioned above, I'm also learning Go, so any comments, suggestions or the like are welcome! See you in the next article!

~~React 5 times to show support~~ 🥰

10 Chrome extensions to increase your productivity as a developer

Lucas Andrade — Tue, 22 Aug 2023 13:21:20 +0000

As a developer, productivity is of utmost importance to achieve greater efficiency in our work. Fortunately, there are numerous resources available to aid in this endeavor, and some of them can be found in the form of Chrome extensions. These extensions are small add-ons that can be directly installed in Chrome, offering supplementary tools and enhancing the overall development experience.

In this article, we will explore 10 Chrome extensions that can enhance our development process:

Clear Cache

This resource enables developers to easily clear their browser cache, ensuring that the most recent code and design changes are immediately reflected. By eliminating all cached data, this extension prevents display issues and facilitates a more agile development experience. With just one click and without any pop-ups, it effectively clears your data and can be customized in terms of the amount of data you wish to remove.

JSON Viewer

This extension provides an efficient and improved method for viewing structured data in JSON format directly within your browser. When working with APIs or JSON files, you can utilize this viewer to easily analyze data in a more organized and readable manner. It highlights syntax and formatting clearly, allowing you to better understand and assess the information.

Wappalyzer

This extension is truly remarkable. Once activated, Wappalyzer will identify the technologies and tools employed by any visited website. When activated, Wappalyzer analyzes the website's code and furnishes comprehensive details about the content management system (CMS), front-end frameworks, JavaScript libraries, web servers, plugins, and much more. Wappalyzer provides valuable insights into the technologies adopted across various websites, and this information can be leveraged for diverse purposes.

Smart Color Picker

This extension enables developers to quickly identify the color their mouse is pointing to. You can hover over any color on your webpage and copy the RGB or hexadecimal value of that color. Moreover, Smart Color Picker provides extra features such as a color palette and the ability to save frequently used colors. This proves handy when you need to obtain a color from elsewhere to use in your webpage via CSS, for instance.

actiTIME Time Tracking & Project Management

This extension provides an integrated solution for tracking your time and managing your projects, making it valuable for developers who aim to enhance their productivity and efficiency.

With this extension, you can effortlessly log the time spent on specific tasks and allocate working hours to individual projects. Additionally, the extension includes time tracking dashboards, goal setting features, and can be used collaboratively among users, such as when working with a coworker, for instance.

Window Resizer

With this extension, you can resize the browser window to simulate common tablet, laptop, desktop, and mobile dimensions. This assists you in observing how your website or application will function on various devices. This is crucial to ensure a more consistent user experience based on window size. Additionally, the extension provides preset sizes and allows users to define custom dimensions.

CSSViewer

This useful tool offers web developers a simple method to inspect and analyze CSS properties directly on any webpage. Once the extension is activated, developers can effortlessly hover over elements to instantly observe their applied CSS styles, such as font, color, margin, padding, and more. It's even more straightforward than using DevTools inspect. This real-time CSS inspection feature streamlines the process of comprehending and resolving issues in website designs.

React Developer Tools

Specifically tailored for React developers, this robust extension offers an indispensable tool for debugging and inspecting React components directly within the browser. Through seamless integration with the React ecosystem, "React DevTools" enables developers to delve into the component hierarchy, scrutinize component props and states, and monitor real-time component updates. This smooth integration streamlines the development process, empowering React developers to swiftly identify and address issues, enhance performance, and attain deeper insights into their application's behavior. Ultimately, this enriches the overall React development experience.

Fake Filler

This handy tool is specifically designed to streamline form filling during web development and testing. With "Fake Filler," developers can effortlessly generate realistic placeholder data for input fields, such as names, email addresses, phone numbers, addresses, and more. By automating the process of populating forms with diverse and authentic-looking information, "Fake Filler" saves developers valuable time during testing and debugging phases. This extension is particularly useful for ensuring proper functionality and responsiveness of web forms, without the need to manually input test data repeatedly. Overall, "Fake Filler" greatly enhances the efficiency and accuracy of form testing, making it an indispensable resource for web developers.

Web Developer

Tailored for web developers and designers, this extension equips users with a comprehensive set of features to streamline their development workflow. From inspecting and modifying HTML/CSS elements to analyzing page performance and testing responsiveness, "Web Developer" offers an array of utilities in a user-friendly interface. Developers can easily disable JavaScript, clear cookies, display image dimensions, and examine page structure, among other functionalities. This all-in-one extension empowers developers with quick access to essential web development tools, facilitating efficient debugging, testing, and optimization of websites and web applications.

GraphQL vs. REST: Choosing the right approach for your application

Lucas Andrade — Thu, 06 Jul 2023 14:35:46 +0000

The API concept started some decades ago, and it is increasingly gaining popularity as time goes by until today. The acronym, which means Application Programming Interface, refers to an interface that intermediates between two or more applications. For example: A server connected to a database that delivers this data to a website asynchronously.

Since then, the API concept has had different protocols and architectures until the early 2000s when REST consolidated as the main way to build APIs in most languages. It continues to be used in different software around the world. For most of these years, we didn't have a popular alternative to REST until 2012 when Facebook decided to release a new technology in their API called GraphQL.

More than 10 years have passed, and this technology has grown in different use cases. However, there are many discussions about when and how to use GraphQL or REST. The answer will always be "It depends". That's why I decided to write this article explaining the proposed use of GraphQL over REST in an API.

How an REST API works?

Basically, a REST API uses the HTTP protocol for data transfer and manipulation in most cases. It functions similarly to a website when it comes to the concept of requests. In summary, a client (another application) makes a call to the server, which then responds with data or modifies it based on the type of method used. The server can also provide conditional data based on its API.

In a basic example, our client will be a website that displays a list of profiles on the main screen. Each profile will be represented by a clickable card, showing the user's name, photo, and state.

Clicking on the card, the client navigates to another page that displays profile details, such as the user's job position and description.

Well, this data is not located in our client but on our server. When requested, the server provides the data as a JSON object, like this:

{
 "name": "Lucas Andrade",
 "state": "Rio de Janeiro",
 "description": "Tech. Music. Society. Software Developer at Geekie, co-founder at Criaway, learning to learn and teach.",
 "employment": "Software Engineer"
}

Furthermore, we have another table in our database that contains user photos: one main photo and one secondary photo. Let's assume that the client needs to display the secondary photo on the first screen and the main photo on the details page. To fulfill this requirement, an additional request would be made, returning a JSON object like this:

{
 "user": "1",
 "primaryPicture": "firsturl.png",
 "secondaryPicture": "secondurl.png"
}

For these two pages, our client will request the same server, which will provide this specific JSONs.

Although, this basic example exposes some problems, which GraphQL proposes to solve.

Overfetching

Basically, it occurs when a server provides unnecessary data that the client doesn't need. This results in increased resource usage on the server, leading to higher latency and expenses. In our example, the client only needs the user's name and state on the main page, while other information is required only on the details page. One solution for this example would be to create an additional endpoint, which would further increase the resource requirements.

Underfetching

On the other hand, underfetching occurs when there is not enough data retrieved with a single call to an endpoint, forcing you to make a second endpoint call. In our example, the client had to make two different requests for similar things (one to fetch users, another to fetch images). In addition to spending more resources, it also requires higher network performance.

Weak Typing

In an API written in languages like JavaScript or Python, we sometimes encounter a problem when type checking is skipped. For example, it becomes more cumbersome to verify if the field name is provided as a string, number, null, undefined, or any other unexpected data type.

These are the problems, along with several others, that GraphQL aims to solve.

How a GraphQL API works?

For the beginning, when we talk about GraphQL, we no longer discuss distinct routes or endpoints. Each request is made to the same route, using the POST method, and the details are provided in the request body, like this:

query getUser($where: UserInputWhere!, $pictureType: _PictureEnum) {
   name
   state
   description
   employment
   pictures (pictureType: $pictureType)
 }

Where:

Query is the type of operation (in this case, the client is making a query to retrieve information).
getUser is the name of the operation, allowing the API to identify the specific action to perform.
$id and $where are variable names used in the query. For instance, id is being passed as a variable, enabling the API to find the user based on the provided ID.
name, state, description, employment, and pictures are the fields returned by the API in response to the query.

To gain a basic understanding of how GraphQL works on the server side, I created a simple implementation:

Firstly, we will define the Input, which will be used as an argument for the query. In our example, we will call it UserInputWhere and it will have a strongly-typed and required ID (defined by "!"):

input UserInputwhere {
  id: ID!,
}

Now, we define the Type that will be used for the query return. In this case, we will have the same fields as our REST API, but they will be strongly typed and required. Additionally, we will have a field called pictures, which will be a list of strings. I will explain how it works later:

type User { 
  name: String!
  state: String!
  description: String!
  employment: String!
  pictures (picture Type: _PictureEnum): [String]
}

The pictures field will receive an argument, as a query inside another query. The argument is not required (indicated by the absence of "!") and has the type _PictureEnum. This type is used to restrict the options that can be passed and ensure that only values from the Enum options are accepted:

enum _PictureEnum {
  PRIMARY 
  SECONDARY
  ALL
  NONE
}

After that, we will define the query as getUser, with Input being UserInputWhere and returning the type User:

query getUser(where: UserInputwhere!): User

Finally, we will define the resolvers. A resolver is a function that's responsible for populating the data for a single field in your schema. Your can read more about this in Apollo Docs:

const resolvers = {
  Query: {
    getUser: (root, args) => users.findOne({ _id: args.id }),
  },
  User: {
    picture: (root, args) => resolverPicture(args.where),
  }
}

A GraphQL advantage is the typing. If our client sends something like:

{ id: "invalid id" }

GraphQL will not accept this query because we don't have a valid ID. This helps a lot in weakly typed languages. If our resolver returns a null value in the name field, for example, GraphQL will also throw an error.

Another strong GraphQL advantage is the Query. In the case of our client above, if we need another page just for searching the user's state, I can only remove the other fields inside the object, like this:

query getUser($where: UserInputWhere!, $pictureType: PictureEnum) { 
  state
}

This way, the query will not return any fields that our client doesn't need, avoiding the overfetching mentioned before.

Furthermore, we have one of the biggest advantages of GraphQL. Do you remember the field pictures defined above? We can use an intermediary function to find the images related to users according to the argument passed on pictureType and return them all in the same query without needing different endpoints! When we don't need to get the images, we can just remove the field from the same object, avoiding another overfetching case and, in this case, saving up network bandwidth by making two database queries on the same endpoint!

In our client example, we can pass a { pictureType: PRIMARY } on the first page and a { pictureType: SECONDARY } on the second page! Or even a { pictureType: ALL } in case we need all the photos.

To finish this example, we will create another query responsible for finding all users, reusing the majority of Types and Inputs, and returning an user required array:

query getUsers (where: Users Inputwhere!): [User]!

const resolvers = { 
const resolvers = {
  Query: {
    getUser: (root, args) => users.findOne({ _id: args.id }),
    getUsers: (root, _args) => users.find({}),
  },
  User: {
    picture: (root, args) => resolverPicture(args.where),
  }
}

GraphQL x REST

Briefly, GraphQL is recommended and can be an alternative in cases of:

Applications with different client types where we need to build different implementations
Applications that need a lot of nested data
Applications where our API finds data from another different API, also with nested data

Conclusion

Even with its advantages, GraphQL definitely must not be used for situations with no difference or impact. Problems like overfetching or typing have different alternatives, and GraphQL is just one more. But an excellent alternative.

In this article, we explored how to implement an API in two ways, and we explain basically why GraphQL gained so much strength in the last few years and is a valid alternative.

Useful links

10 awesome Github repositories that everyone should know

Lucas Andrade — Thu, 15 Jun 2023 18:25:30 +0000

The technology field is vast, and many people may struggle to organize their studies and start a career, especially in the beginning. Despite the abundance of resources available, the sheer breadth of the field can leave us feeling lost when searching for resources, assistance, ideas, and other things.

And that's completely normal! That's why there are numerous open repositories on GitHub created by people who want to help in various areas and cover different topics, precisely to enhance your studies. Knowing the abundance of useful repositories, I couldn't help but write about the 10 that I enjoyed the most on the platform and that can help you as they have helped me.

1. Design Resources for developers

As the name implies, this repository stores a variety of free resources related to design, providing a one-stop destination for front-end developers to explore. From photos and icons to use in your projects, to CSS libraries or frameworks like React and Vue, it is indeed a vast and valuable repository for your projects or simply for learning purposes.

2. Awesome Hacking Resources

Ideally for info-sec students, this repository contains various study materials about this topic. YouTube channels, malware analysis, and forums are just a few of the many subjects that include valuable references and external links.

3. App Ideas

One of the most creative and organized repositories that I've ever seen is App Ideas. It is a repository that provides developers with several ideas to create their own applications.

However, it has some distinctive features. Its readme file categorizes the ideas based on the knowledge level required. For beginners, there are calculators and previewers. Intermediate level ideas include currency converters and Chrome extensions. For more advanced individuals, there is even an Instagram clone.

Furthermore, this repository includes a to-do list within each idea, serving as a requirement list to track progress over time.

4. Free Programming Books

The Ebook Foundation created this amazing repository full of free books for those who enjoy reading about programming and technology. The repository contains books in different languages and is categorized into various topics within the tech field. Just enjoy!

5. Public APIs

Who hasn't experienced a headache without ideas, and just by seeing an API, wanted to implement something with it? This repository includes several APIs to help you with that, sorted by themes and indicating whether they require authentication or not, among other things. I'm already going to use some APIs from there for a project, maybe...

6. Javascript Testing: Best Pratices

This repository contains several texts, created and translated into multiple languages, about JavaScript testing and Node. Covering good practices on the topic, this repository will provide you with an enjoyable reading experience.

7. Developer Roadmap

This repository is really, really, really amazing! One of the most famous on GitHub, updated every year, The Developer Roadmap helps you follow a learning path to become a developer in various topics. There are many subjects for each area, ranging from optional to required.

8. Clean Code

This book is famous, and you've probably heard about it. Clean Code helps you create clean, readable, and easily maintainable code. However, there are repositories on GitHub with information about this book adapted for various languages and technologies. So, here's a simple list:

9. Coding Interview University

Coding Interview University is a repository that gathers topics to prepare you in big tech selection processes as Google, Amazon, Facebook and Microsoft. If you study this repository, you definetly will be prepared.

10. The Art of Command Line

For Linux enthusiasts, this repository allows you to explore the primary system resources, exclusively on the terminal. With detailed reading, you can learn numerous topics about Linux on the command line. I started reading more about it because there is a wealth of content available.