DEV Community: Thiago Avelino

How to reuse workflow in GitHub Action pipeline

Thiago Avelino — Thu, 27 Apr 2023 00:00:00 +0000

Before I tell you how to do it, I will describe the problem I needed to solve and why I believed that reuse would be the best option to reduce duplicate code.

I maintain an Open Source project called moclojer written in Clojure and we use GraalVM Native Imagem to distribute the software in binary format (with everything self-contained).
The configuration of native-image receives several parameters, some refer to libraries used in the project code and it depends on a .jar file, so there are some steps before "running" the command that generates the binary.

Steps to generate the moclojer binary:

generate the .jar file
generate the configuration file reflect.config.json from the .jar.
generate the binary using .jar and reflect.config.json
test if the binary is working correctly - run the software
upload artifact (file) to generate software release on GitHub

In moclojer I needed to run the pipeline that creates the .jar in every push and pull request, we had the same duplicate code in this pipeline and in the pipeline to generate the binary (Graalvm Native Image).

When opening "pull request " I don't need to generate the binary every time just once when everything is right with the contribution, but every "push " I want to generate the .jar to validate that everything is working.

## How to reuse the workflow in GitHub Action pipeline?

Now that we are clear on the need, let's get to the point of how to do it.

In a job you have the parameter jobs.<job-name>.uses which accepts .yml file (another workflow), when it reaches this step it will call the external workflow and wait for the output, example:

jobs:
  call-build:
    uses: moclojer/moclojer/.github/workflows/build-native-image.yml@main

In the example above I pass the path of the workflow build-native-image.yml which is in the GitHub organization moclojer (first parameter), in the repository moclojer (second parameter) and in the branch main (comes after the name of the file .yml starting with @).

<github-org-OR-profile>/<repo-name>/.github/workflows/<workflow-file-name>@<branch-or-tag>

If the workflow being invoked depends on any permissions, the main workflow needs to have the same permissions.

See the workflow we used for release from moclojer.

Learn more about workflow reuse in the official GitHub documentation.

Reporting a problem in an Open Source project is as important as contributing code

Thiago Avelino — Sat, 22 Apr 2023 00:00:00 +0000

I constantly hear people saying that to contribute to an Open Source project you need to be able to program very well, have a lot of knowledge, be able to handle code criticism, etc.

I see the above statements as excuses and focus in the wrong place.

In the last few months, I haven't had as much time to contribute to open source projects as I like (writing code), but that didn't stop me from contributing. Actually, the lack of priority (not lack of time) has made me contribute by reporting problems that I run into in the projects/software I use in my day-to-day life and this has been more work than writing code with a defined specification (issue that someone invested time detailing).

Generally, reporting a problem is not just opening an issue exposing the back trace, we need to understand what generated the problem, so the person who helps to maintain the project can reproduce it "locally" (in the development environment) to think of the best solution without breaking other existing features in the software.

How do I write a very detailed issue?

Whenever I am communicating with someone, I assume that everything that is obvious to me is not so obvious to the person and I put as much context as possible in the conversation, helping the person to make the best decision.

When I am opening an issue it is no different, I will describe the problem to the person who will read (solve) it, not to me, i.e. everything that is obvious to me is probably not obvious to other people.

Code is important, but not only code

Open Source projects exist to solve problems and are made by people for people, investing time in opening a detailed issue demonstrates that you care about the project and empathize with the people who are helping to maintain the project.

Avoid leaving to report the issue later, you will probably forget important details.

this blogpost came up after I reported an issue in a project and the first comment was from a person saying he had run into the same problem "yesterday".
what came to my mind was: why didn't the person report this issue yesterday?

Query that I am constantly following on GitHub to keep track of the issues I opened, looking today there are 1.1k issues in public repositories.

From wanting to be part of the CTO

Thiago Avelino — Wed, 08 Jun 2022 11:00:26 +0000

After seeing the initiative Buser had to train people at home with the Buser Tech program (led by Renzo as Buser’s head of education), I wanted to approach them somehow — I didn’t know how or what to do, but I wanted to be part of the “party”.

I have helped many engineering people evolve professionally (that's 0.001%), but I have never trained anyone from scratch and I felt it was time to learn from those who have been doing it for a few years.

I have known Tony (ex-CTO of Buser) for many years, in late 2021 I took the liberty to message him and express my interest.

I didn’t feel comfortable coming into Buser to suck knowledge, so I proposed to join the engineering team as a developer and follow what is going on in Buser Tech.

In the 1:1 with Tony he shared with me that he was looking for someone to take over the CTO role at Buser. I confess I didn’t understand why he was sharing that with me, the only answer that came to me at the moment was:

“If you are saying this for me to be CTO you are saying it to the wrong person.”

Upon arriving and bumping into the software we developed at Buser I started to wonder how the folks in the Buser Tech program (with virtually zero software development experience) were going to get up the development environment that I with a few years of engineering experience was having some friction. I took this as my first challenge to reduce the friction of onboarding the engineering team by bringing a developer experience look.

After a few days/weeks I felt that we could improve our people and project management, I went to talk to Tony and made myself available to help as Tech Manager.

The subject of possibly being a CTO stayed in my mind for days and days, I even indicated a CTO for the position that unfortunately did not match, but life goes on, and my internal monsters kept haunting me about the CTO position.

Usually when I get a chill in my stomach it sounds like I am looking at a big challenge and there is a big unknown — especially what I need to evolve as a person and a manager, in this case a company with more than 500 people.

After being an entrepreneur for a few years, I don’t want to make a company from scratch until I reach 500 people (Buser’s current moment), but I am sure that the challenge of Scale-up a startup takes me closer to my professional goal.

Even though my stomach is chilly and I believe I have many skills to evolve, I am taking on the CTO position at Buser.

Is Tony leaving Buser? No, he is moving back closer to the engineering and education team — where he feels he delivers much better results for the company. See here the post he made publicly about this move (publication written in Portuguese).

Clojure Twitter community

Thiago Avelino — Wed, 16 Feb 2022 20:08:46 +0000

Twitter community for talking and sharing content from the Clojure ecosystem

https://twitter.com/i/communities/1494013093059432451

We are more than 75,000 people (stars 🌟) — awesome-go

Thiago Avelino — Thu, 03 Feb 2022 12:06:10 +0000

I've been meaning to write this blogpost since when we reached 10,000 stars 🌟 (I never imagined it would reach that number of people), but every day I reached more (and more) people and always thought the text would get outdated.

Today is the day to thank everyone who uses, contributes and follows awesome-go, it's time to celebrate 🎉🙌 — regardless of the number we reach and the people we help in some way.

Awesome-go was born on 2014-07-06 inspired by the awesome-python project, after the first commit containing 3 categories I messaged some friends who used Go at work to help list the libraries they used in their day-to-day work.

I never imagined that a “no code” project would receive so many contributions (we are more than 2000 contributors).

As the number of pull requests grew, reviewing the contributions became impossible, and we had to invest time to automate our review work as much as possible by bringing in an automated process via CI to optimize the time of all maintainers of the project (now using code), running on each open pull request.

Thanks to 🙏

I’m grateful to our community for all the support, I am excited by the number of people we reach and somehow help them find the best library for their project 💜.

Here is my eternal gratitude to all the people who send in their libraries and who help me keep awesome-go running (the maintainers, you are amazing).

👉 Help us reach 100k! 🌟 http://github.com/avelino/awesome-go

Constant work to onboarding new members into engineering team

Thiago Avelino — Fri, 07 Jan 2022 20:43:19 +0000

Developing the "onboarding" process for a new person in an engineering team takes a lot of dedication, and keeping this process fluid takes even more work (with as little friction as possible).

This issue is challenging for any team working full time, it is even worse for Open Source projects where contributors usually work in their spare time. We should make this process as fluid as possible so that people don't get discouraged by the complexity of getting up there and testing, until they make their first pull request.

Configure development environment

Every developer has a different way of setting up a development environment, even if it is in a popular technology (programming language) with lots of documentation, text editor extensions (emacs, vim, vscode, ...), etc.

We developers are used to “our way” of doing things, it is common for us to create resistance when someone presents a different way and I do it another way.

In the vast majority of applications they depend on external resources such as databases, APIs, tokens, etc., if we force the developer (user) to read all the project documentation before having the first contact with the project it is very likely that we will lose his engagement, and some frustrations in him, such as:

I just wanted to test
I have to read all this to see it working
What a complicated project
I have to install X, Y and Z services/software on my machine
I don't know the programming language used in the project, which plugins should I install in my editor?
... and much more.

There are some tools to assist project maintainers (open source or private) to generate an onboarding process with as little friction as possible.

Configuring editor (with all the necessary plugins and parameters), all the services the project needs to run, environment variables configured, database running with initial data load, data viewer configured (software to manage data from the database), etc.

To the point where the developer “clicks a button” and magically has the development environment ready to test the software.

In the last few months we at prestd have been working on improving our documentation (it is far from being good documentation) and removing as much friction as possible in the process of getting a new development environment up, some issues we have implemented until we got to what we have today:

Improve local tests execution — it is frustrating that someone wants to contribute and cannot run the local tests (we use e2e tests, making requests to prestd's own API), a way was implemented where the tests run inside docker using docker-compose;
Documentation: new content architecture — thinking of a person who has never had contact with prestd and wants to test or use it in a production environment, both people should get into the documentation and be able to do what they want to do (bring up the environment);
Onboarding of new contributor: using devcontainer — prepare the development environment with "1 click" using devcontainers (GitHub Codespaces support).

See prestd's development guide page here.

It is not nice to have the engineering team working in a bad environment, we need to think more about our team and make the team experience fluid.
people > technology

Focus on the developer (user)

The prestd exists open source since 2016, I particularly like the project very much and believe it is a great solution to accelerate the development of a RESTful API for existing database and especially development of a new API (project starting from scratch).

But for many years we turned to developing the software didn't look at documentation with the dedication we should, causing the contributor base to shrink (existing and new) — people going through open source project, hardly stayed for many years, so we always have to have the most rounded onboarding process possible.

Given this problem I started to look at the documentation with more dedication and every decision in prestd from now on will be thinking about the developer (user) experience, answering the following questions:

Will this improve the developer experience using the project?
Will this make the project easier to use?
Will this make it easier to maintain the development of the project?

When all 3 questions are “yes”, we will proceed with the implementation, regardless of what it is: feature, improvement, fix, etc.

7 subjects (and GitHub repositories) to become a better Go Developer

Thiago Avelino — Sun, 11 Jul 2021 18:43:05 +0000

With the high adoption of the Go language by developers and large companies, this has led companies to search for engineers with experience in Go.

This can create a lot of pressure of what to study to become a better engineer, this is very personal, it requires planning of what and when to study other subjects (even outside the engineering area).

In this blogpost some topics (with repositories and links) that I think are important to know in order to become an engineer person with even better Go knowledge, follow good practices for writing code, concepts of code structure (usually using design pattern), scalable code and clean code.

Style guide

I can't list only one link (repository) for this topic, I would recommend you to read for these 3 links and bring to your team's day to day life what best fits their reality — remember to use as base the official language documentation and add what makes sense from the other links

Effective Go

uber-go / guide

The Uber Go Style Guide.

This repository holds the Uber Go Style Guide, which documents patterns and conventions used in Go code at Uber.

Style Guide

See Uber Go Style Guide for the style guide.

Translations

We are aware of the following translations of this guide by the Go community.

中文翻译 (Chinese): xxjwxc/uber_go_guide_cn
繁體中文 （Traditional Chinese）：ianchen0119/uber_go_guide_tw
한국어 번역 (Korean): TangoEnSkai/uber-go-style-guide-kr
日本語訳 (Japanese): knsh14/uber-style-guide-ja
Traducción al Español (Spanish): friendsofgo/uber-go-guide-es
แปลภาษาไทย (Thai): pallat/uber-go-style-guide-th
Tradução em português (Portuguese): lucassscaravelli/uber-go-guide-pt
Tradução em português (Portuguese BR): alcir-junior-caju/uber-go-style-guide-pt-br
Tłumaczenie polskie (Polish): DamianSkrzypczak/uber-go-guide-pl
Русский перевод (Russian): sau00/uber-go-guide-ru
Français (French): rm3l/uber-go-style-guide-fr
Türkçe (Turkish): ksckaan1/uber-go-style-guide-tr
Український переклад (Ukrainian): vorobeyme/uber-go-style-guide-uk
ترجمه فارسی (Persian): jamalkaksouri/uber-go-guide-ir
Tiếng việt (Vietnamese): nc-minh/uber-go-guide-vi

If you have a translation, feel free to submit a PR adding it to the list.

View on GitHub

Google Style Guides

Go standards and style guidelines | GitLab

Best Practices

Francesc Campoy gave an excellent talk at OSCON 2015 on this subject, where he covered best practices for developing software using the Go language.

Slides

Twelve Go Best Practices

Algorithms Implemented

TheAlgorithms / Go

Algorithms and Data Structures implemented in Go for beginners, following best practices.

The Algorithms - Go

Algorithms implemented in Go (for education)

The repository is a collection of open-source implementation of a variety of algorithms implemented in Go and licensed under MIT License.

Read our Contribution Guidelines before you contribute.

List of Algorithms

Packages:

ahocorasick

Functions:

Advanced: Advanced Function performing the Advanced Aho-Corasick algorithm. Finds and prints occurrences of each pattern.
AhoCorasick: AhoCorasick Function performing the Basic Aho-Corasick algorithm. Finds and prints occurrences of each pattern.
ArrayUnion: ArrayUnion Concats two arrays of int's into one.
BoolArrayCapUp: BoolArrayCapUp Dynamically increases an array size of bool's by 1.
BuildAc: Functions that builds Aho Corasick automaton.
BuildExtendedAc: BuildExtendedAc Functions that builds extended Aho Corasick automaton.
ComputeAlphabet: ComputeAlphabet Function that returns string of all the possible characters in given patterns.
ConstructTrie: ConstructTrie Function that constructs Trie as an automaton for a set of reversed & trimmed strings.
…

View on GitHub

This repository contains Go based examples of many popular algorithms and data structures.

Each algorithm and data structure has its own separate README with related explanations and links for further reading.

Clean Code

A reference for the Go community that covers the fundamentals of writing clean code and discusses concrete refactoring examples specific to Go.

Pungyeon / clean-go-article

A reference for the Go community that covers the fundamentals of writing clean code and discusses concrete refactoring examples specific to Go.

Clean Go Code

Preface: Why Write Clean Code?

This document is a reference for the Go community that aims to help developers write cleaner code. Whether you're working on a personal project or as part of a larger team, writing clean code is an important skill to have. Establishing good paradigms and consistent, accessible standards for writing clean code can help prevent developers from wasting many meaningless hours on trying to understand their own (or others') work.

We don’t read code, we decode it – Peter Seibel

As developers, we're sometimes tempted to write code in a way that's convenient for the time being without regard for best practices; this makes code reviews and testing more difficult. In a sense, we're encoding—and, in doing so, making it more difficult for others to decode our work. But we want our code to be usable, readable, and maintainable. And that requires…

View on GitHub

Clean Architecture

In his book “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” famous author Robert “Uncle Bob” Martin presents an architecture with some important points like testability and independence of frameworks, databases and interfaces.

bxcodec / go-clean-arch

Go (Golang) Clean Architecture based on Reading Uncle Bob's Clean Architecture

go-clean-arch

Changelog

v1: checkout to the v1 branch
Proposed on 2017, archived to v1 branch on 2018
Desc: Initial proposal by me. The story can be read here: https://medium.com/@imantumorang/golang-clean-archithecture-efd6d7c43047
v2: checkout to the v2 branch
Proposed on 2018, archived to v2 branch on 2020
Desc: Improvement from v1. The story can be read here: https://medium.com/@imantumorang/trying-clean-architecture-on-golang-2-44d615bf8fdf
v3: checkout to the v3 branch
Proposed on 2019, merged to master on 2020.
Desc: Introducing Domain package, the details can be seen on this PR #21
v4: master branch Proposed on 2024, merged to master on 2024.
Desc:
- Declare Interfaces to the consuming side,
- Introduce internal package
- Introduce Service-focused package.
Details can be seen in this PR #88.

Author's Note

You may notice it diverges from the structures seen in previous versions. I encourage you to explore the branches for each version to select the structure that appeals to…

View on GitHub

Elton Minetto has written two excellent blogposts on the subject:

Awesome Go

I couldn't leave out the awesome-go project (which I started in 2014 and today many contributors help me maintain)

avelino / awesome-go

A curated list of awesome Go frameworks, libraries and software

Awesome Go

We use the Golang Bridge community Slack for instant communication, follow the form here to join.

Sponsorships:

Special thanks to

Your app, enterprise-ready. Start selling to enterprise customers with just a few lines of code. ^{Add Single Sign-On (and more) in minutes instead of months.}	An open, source-available software licensing and distribution API. Securely license and distribute Go applications with a single API. ^{Add auto updates with only a few lines of code.}

Awesome Go has no monthly fee, but we have employees who work hard to keep it running. With money raised, we can repay the effort of each person involved! You can see how we calculate our billing and distribution as it is open to the entire community. Want to be a supporter of the project click here.

A curated list of awesome Go frameworks, libraries, and software. Inspired by awesome-python.

Contributing:

…

View on GitHub

A collection of awesome Go libraries and resources. This repository contains a list of variety of frameworks, template engines, articles and post, documentations, reactive and functional programming and much more which will increase your resourcefulness and might also help you to choose the tech stack for your next projects.

Project Guideline

This is a complicated subject, there is no standard that will work perfectly for what you are developing, I recommend understanding the concept of project architecture (not only Go) and together with your team understand what works for you, even though there are thousands of books to give you knowledge about the subject I recommend putting your hands in the code and allow you to make mistakes, it is the best way to evolve.

Read this content before any other

How to Write Go Code

Now that you have read the previous link I will recommend a controversial repository by its name, it is not "Golang standards project layout", but there is a project structure that can help in the development of a new project - understand what makes sense for you (and your team), what doesn't, just ignore it.

golang-standards / project-layout

Standard Go Project Layout

Translations:

Overview

This is a basic layout for Go application projects. Note that it's basic in terms of content because it's focusing only on the general layout and not what you have inside. It's also basic because it's very high level and it doesn't go into great details in terms of how you can structure your project even further. For example, it doesn't try to cover the project structure you'd have with something like Clean Architecture.

This is NOT an official standard defined by the core Go dev team. This is a set of common historical and emerging project layout patterns in the Go ecosystem. Some of these patterns are more popular than others. It also has a number of small enhancements along with several supporting…

View on GitHub

Read why I said this project is controversial

Vote Of Thanks

Thank you so much for reading this post and I hope you find these repositories as useful as I do and will help you to become better go developer. Feel Free to give any suggestions and if you like my work you can follow me on Twitter

When is the best time to share a "new" product?

Thiago Avelino — Fri, 09 Jul 2021 00:17:23 +0000

Is now (as soon as possible), even if it's not the way you want it

pREST exists since 2016 and today I remembered to publish it on Product Hunt, without having much expectation on the engagement.

To my surprise, has a much higher engagement than I imagined, especially in the installation of binary (software).

We will be a software for API development based on PostgreSQL database (new or existing) with low-code, there is a lot of work to be done... we are just in the beginning.

// Detect dark theme var iframe = document.getElementById('tweet-1412956727822200835-533'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1412956727822200835&theme=dark" }

prest / prest

PostgreSQL ➕ REST, low-code, simplify and accelerate development, ⚡ instant, realtime, high-performance on any Postgres application, existing or new

pRESTd

pREST (PostgreSQL REST), is a simple production-ready API, that delivers an instant, realtime, and high-performance application on top of your existing or new Postgres database.

PostgreSQL version 9.5 or higher

Contributor License Agreement -

Problems we solve

The pREST project is the API that addresses the need for fast and efficient solution in building RESTful APIs on PostgreSQL databases. It simplifies API development by offering:

A lightweight server with easy configuration;
Direct SQL queries with templating in customizable URLs;
Optimizations for high performance;
Enhanced developer productivity;
Authentication and authorization features;
Pluggable custom routes and middlewares.

Overall, pREST simplifies the process of creating secure and performant RESTful APIs on top of your new or old PostgreSQL database.

Why we built pREST

When we built pREST, we originally intended to contribute and build with the PostgREST project, although it took a lot…

View on GitHub

https://www.producthunt.com/posts/prest

Full Text Search in PostgreSQL

Thiago Avelino — Sat, 02 Jan 2021 19:20:54 +0000

When the subject is search engine (inverted index) it is extremely common to think of solutions like Apache Solr or Elastic (former elasticsearch), but why don't we remember the Full Text Search feature we have native in PostgreSQL?

The full text search feature in PostgreSQL became native in version 9.4, but before that we had the GiST Indexes, which was used as the basis for the development of Full Text Search (tsvector).

What Is Full Text Search Anyway?

(...) full-text search refers to techniques for searching a single computer-stored document or a collection in a full text database; (...) distinguished from searches based on metadata or on parts of the original texts represented in databases (such as titles, abstracts, selected sections, or bibliographical references). Wikipedia

In other words, imagine you have a set of text documents stored in a database. These documents are not just meta-data items like an author name or a country of origin, but rather an abstract for an article, or full text articles themselves, and you want to find out if certain words are present or not in them.

E.g. you want to search all the news that has subistantive related to "dog" or "fox" (we are talking about animals) are present so if they are in their singular form, you'll find them with the ILIKE keyword...

SELECT * FROM news  
WHERE  
(body ILIKE '%fox%' OR
body ILIKE '%dog%');

... but you'll also find stuff like "foxtrot" or "Dogville", which is not quite what you intended, you had to declare in which field you would search, if you did not have the terms searched in the field will not bring record.

Another problem is that if you search for a word such as "query", and if it's present in its plural form "queries", then you won't find it if you try a simple pattern search with LIKE, even though the word is, in fact, there. Some of you might be thinking to use regular expressions, and yes, you could do that, regular expressions are incredibly powerful, but also terribly slow.

A more effective way to approach this problem is by getting a semantic vector for all of the words contained in a document, that is, a language-specific representation of such words. So, when you search for a word like "jump", you will match all instances of the word and its tenses, even if you searched for "jumped" or "jumping". Additionally, you won't be searching the full document itself (which is slow), but the vector (which is fast).

That is, in a nutshell, the principle of full text search, thinking about problems related to this was developed data type tsvector.

What do you need to know to use tsvector?

PostgreSQL has two functions that do exactly what we intend to do:

to_tsvector for creating a list of tokens (the tsvector data type, where ts stands for "text search");
to_tsquery for querying the vector for occurrences of certain words or phrases.

For example, to create a vector for the sentence "the quick brown fox jumped over the lazy dog":

SELECT to_tsvector('The quick brown fox jumped over the lazy dog.');

Which will return a vector where every token is a lexeme (unit of lexical meaning) with pointers (the positions in the document), and where words that carry little meaning, such as articles (the) and conjunctions (and, or) are conveniently omitted:

                      to_tsvector
-------------------------------------------------------
 'brown':3 'dog':9 'fox':4 'jump':5 'lazi':8 'quick':2

By default, every word is normalized as a lexeme in _English+ (e.g. "jumped" becomes "jump"), case depending on the localization settings of your PostgreSQL installation.

A common doubt is about support for other languages (e.g. Brazilian Portuguese). The good news is that we have support for several languages, see the list:

SELECT cfgname FROM pg_ts_config;

cfgname
--------
simple
arabic
danish
dutch
english
finnish
french
german
hungarian
indonesian
irish
italian
lithuanian
nepali
norwegian
portuguese
romanian
russian
spanish
swedish
tamil
turkish

Deeper into the PostgreSQL text search configuration.

Real example generating tokens

We have news table with title field, description and other meta data:

CREATE TABLE news (
    id SERIAL PRIMARY KEY,
    title text NOT NULL,
    description text NOT NULL,
    created_at timestamp without time zone NOT NULL DEFAULT now(),
    last_update timestamp without time zone NOT NULL DEFAULT now(),
    tokens tsvector
);

The way it is when creating a record will not be created the tokens to do textual search, how will we solve this?

We can create a trigger that listens to all the creation and updating, joins the text of the title and description and generates the tokens automatically:

CREATE OR REPLACE FUNCTION set_full_text_search_on_news()
RETURNS TRIGGER AS $$
BEGIN
       NEW.tokens = to_tsvector(concat(NEW.title, ", ", NEW.description))
       RETURN NEW;
END;
$$ language 'plpgsql';

CREATE TRIGGER update_new_full_text_search
       BEFORE UPDATE ON news
       FOR EACH ROW EXECUTE PROCEDURE set_full_text_search_on_news();

Inserting a Record:

INSERT INTO news (title, description)
VALUES
('dog history', 'The quick brown fox jumped over the lazy dog');

The tokens field will be generated automatically, thus remaining:

'caolha':4 'da':2 'de':5 'em':12 'fax':9 'gigant':11 'história':1 'java':6 'mandar':8 'new':13 'para':10 'querem':7 'york':14 'zebrazebra':3

It is now possible to do text search using the full text search feature (function to_tsquery):

SELECT * FROM news WHERE tokens @@ to_tsquery('fox');

Return:

 id |    title    |                 description                  |         created_at         |        last_update         | client_id |                                 tokens
----+-------------+----------------------------------------------+----------------------------+----------------------------+-----------+------------------------------------------------------------------------
  1 | dog history | The quick brown fox jumped over the lazy dog | 2020-12-11 15:58:55.298558 | 2021-01-02 16:05:21.088482 |         1 | 'brown':4 'dog':1,10 'fox':5 'historyth':2 'jump':6 'lazi':9 'quick':3
(1 row)

How to use this feature in pREST?

prest / prest

PostgreSQL ➕ REST, low-code, simplify and accelerate development, ⚡ instant, realtime, high-performance on any Postgres application, existing or new

pRESTd

pREST (PostgreSQL REST), is a simple production-ready API, that delivers an instant, realtime, and high-performance application on top of your existing or new Postgres database.

PostgreSQL version 9.5 or higher

Contributor License Agreement -

Problems we solve

The pREST project is the API that addresses the need for fast and efficient solution in building RESTful APIs on PostgreSQL databases. It simplifies API development by offering:

A lightweight server with easy configuration;
Direct SQL queries with templating in customizable URLs;
Optimizations for high performance;
Enhanced developer productivity;
Authentication and authorization features;
Pluggable custom routes and middlewares.

Overall, pREST simplifies the process of creating secure and performant RESTful APIs on top of your new or old PostgreSQL database.

Why we built pREST

When we built pREST, we originally intended to contribute and build with the PostgREST project, although it took a lot…

View on GitHub

This feature was implemented in version 1.0.5 as a search filter and works like this:

GET /{DATAVASE}/{SCHEMA}/news?tokens:tsquery=fox

[
    {
        "id": 1,
        "title": "dog history",
        "description": "The quick brown fox jumped over the lazy dog",
        "created_at": "2020-12-11T15:58:55.298558",
        "last_update": "2021-01-02T16:05:21.088482",
        "client_id": 1,
        "tokens": "'brown':4 'dog':1,10 'fox':5 'historyth':2 'jump':6 'lazi':9 'quick':3"
    }
]

Read more about pREST search filters here.

Difference between INSERT and COPY in PostgreSQL

Thiago Avelino — Wed, 30 Dec 2020 21:13:42 +0000

Quite a number of reasons, actually, but the main ones are:

Typically, client applications wait for confirmation of one INSERT's success before sending the next. So there's a round-trip delay for each INSERT, scheduling delays, etc (pREST supports pipelineing INSERTs in batches). This point is the most significant, It's all about network round-trips and rescheduling delays;
Each INSERT has to go through the whole executor. Use of a prepared statement bypasses the need to run the parser, rewriter and planner, but there's still executor state to set up and tear down for each row. COPY does some setup once, and has an extremely low overhead for each row, especially where no triggers are involved.

pREST of COPY batches "INSERT's" support?

Yes, we support the insertion operation using COPY when explained in the http protocol header.

Prest-Batch-Method: copy, when not declared pREST will use INSERT.

pREST Celebrating 2,441 GitHub Stars ✨

Thiago Avelino — Wed, 11 Nov 2020 19:44:50 +0000

pREST just received it's 2,441th star on GitHub. We'll use this milestone to recap pREST’s growth and other important milestones since its beginning as an experimental project in 2016. We've accomplished lot of great things together.

prest / prest

PostgreSQL ➕ REST, low-code, simplify and accelerate development, ⚡ instant, realtime, high-performance on any Postgres application, existing or new

prestd

pREST (PostgreSQL REST), simplify and accelerate development, instant, realtime, high-performance on any Postgres application, existing or new

PostgreSQL version 9.5 or higher

Contributor License Agreement -

Problem

There is PostgREST written in Haskell, but keeping Haskell software in production is not an easy job. With this need prestd was born. Read more.

Test using Docker

To simplify the process of bringing up the test environment we will use docker-compose

# Download docker compose file
wget https://raw.githubusercontent.com/prest/prest/main/docker-compose-prod.yml -O docker-compose.yml
# Up (run) PostgreSQL and prestd
docker-compose up
# Run data migration to create user structure for access (JWT)
docker-compose exec prest prestd migrate up auth

# Create user and password for API access (via JWT)
## user: prest
## pass: prest
docker-compose exec postgres psql -d prest -U prest -c "INSERT INTO prest_users (name, username, password) VALUES ('pREST Full Name', 'prest', MD5('prest'))

…

View on GitHub

While tracking the success of an open source project is known to be a hard problem, we've a few metrics available to us. Currently 42 developers have contributed to some of the 1239 commits of the pREST repository made available in 20 releases. And this is only data from the main pREST repo.

The number of stars of a GitHub project is yet another indicator, because it means people are adding the project to their list of favorites. However, people that starred pREST are not necessarily users and many users don’t star pREST (if that applies to you, consider giving us a star!), therefore its not a precise metric. Till date pREST has 50k+ all-time users during the span of an year. Which includes ~4k+ monthly users.

Milestones like this are proud moments for the developers & community, help motivate more work & new developments. If you'd like to support pREST open source project, consider looking at the discussion page on GitHub.

This will be added to the greatest moment's timeline.

Immense thanks to all the contributors who dedicated part of their time to contribute to the project. Felipe Oliveira for starting this project with me in 2016, his experience in software engineering and staying active until today.

Behind Open Source projects there are people

Thiago Avelino — Thu, 09 Jul 2020 21:15:27 +0000

Many engineers forget when contributing to Open Source projects that behind all projects we have people.

We don't know the people on the other side (project maintainers) and how they will receive our contribution, this generates the need for communication to be clear and we don't assume that the maintainers (contributors) have the same knowledge as us (we have no way to know what other people have knowledge), even concepts that we find obvious is important to make clear in communication (issue, pull request and so on).

Don't be attached to code - code is a way to get to the solution of a problem. It may be that your implementation of code or communication is not clear, do not take negative feedback to the personal side, in general contributors look at the implementation that is coming - but remember that this is not a rule, I cannot speak for all projects and/or people.

When you're on the project maintainer side: look at each contribution as the best possible contribution from the person, they (the person who built it) have left their tasks to contribute to a project that isn't theirs, try to understand why they had an affinity to the project - this will help you create a community (you'll have help to maintain the project). One of the things that I think is "successful" is when you have a community involved with people with diverse realities and needs, it helps the project grow. Especially when we can give attention to new contributors, training leaders is essential to any project.

Good contribution my friends, I hope I have encouraged you to contribute with some Open Source project.

See the projects that I maintain and already contribute, you need help to contribute and/or maintain Open Source project contact me t AT avelino DOT xxx. Stay informed about what's new in the Open Source world by subscribing this newsletter.