DEV Community: Davide Imola

I Rebuilt My Site Twice. Here's What the Second Time Taught Me.

Davide Imola — Fri, 27 Mar 2026 09:26:35 +0000

I rebuilt my personal site. Then I rebuilt it again.

The first time I thought the problem was the old site. The second time I realized the problem was how I was working.

Two versions, same problem

The original site was built in Astro. I chose Astro because I wanted to experiment with something new. I'd been doing mostly backend and infrastructure work at the time, and my frontend skills were, let's say, still developing. The result was functional and completely forgettable: white text on a black background, no real personality, nothing that said anything about who I was or what I did.

So I decided to rebuild it using AI. I had access to Cursor through work, so I started there. The workflow was straightforward: describe what you want, get a plan, let it generate most of the site at once.

It was better. Some things were genuinely nice: red underlines styled like brushstrokes, a layout that felt more composed. But it was also a mess. Too many color variations that didn't quite agree with each other. And at some point, because I'd mentioned that I love Japanese culture and aesthetics, the AI decided the obvious move was to add kanji characters to the design.

I don't speak Japanese. I removed the kanji.

The core issue wasn't the kanji. That was just the most visible symptom. The real problem was that I'd handed over a vague brief ("I like Japanese aesthetics") and gotten back a literal interpretation, with all the inconsistencies that come from generating a whole site in one go. The design system wasn't solid because I'd never defined one. Everything was a bit improvised.

Still not working. But now I knew why.

Starting over with a different question

I could have kept patching the Cursor version. Instead I started from scratch. Partly out of frustration, mostly out of curiosity. I'd been reading and watching more about AI-assisted development, and I wanted to try a fundamentally different approach.

The question wasn't "can AI build my site?" I already knew it could. The question was: what happens if I stop treating AI as a site generator and start treating it as a collaborator?

I switched to Claude Code and gave myself one constraint before touching a single component: I would define the design system first.

Design system first, everything else second

This sounds obvious in retrospect. It wasn't obvious to me at the time.

I'm not a designer. I can look at something and know whether it works, but I struggle to build the underlying system that makes it consistent. What I needed wasn't something to generate components. I needed something that would push back when my decisions were incoherent.

So I started with tokens: background colors, text hierarchy, border values, a single accent color (Akane red, #C91F37). I set strict rules. The AI started flagging things I wouldn't have caught on my own: too many color variations, inconsistent visual language, patterns that looked fine in isolation but clashed in context.

"Too many colors. Pick a few that work together and stick to them."

That kind of feedback is what a designer gives you. I was getting it from an AI, but only because I'd asked the right questions and constrained the scope. Working on one isolated part of the project at a time, not the whole thing, made the feedback loops tight and the outcomes predictable.

The result was a design system I actually understood. Building the site on top of it was a completely different experience.

The voice input accident

Somewhere in the middle of the second rebuild, I started using voice input.

I didn't plan to. I'd seen someone mention it in a video, tried it out of curiosity, and kept using it because it worked better than I expected.

The difference isn't speed. Typing is faster for precise, short instructions. The difference is how you think. When you speak, you reason out loud. You self-correct in real time. You catch yourself saying "actually, no, wait, what I really mean is..." and that process of rephrasing turns out to be genuinely useful.

I started with the voice input built into Claude, then experimented with other tools. The prompts I produced with voice were longer, more specific, and more honest. I said things I wouldn't have bothered typing.

I'm not claiming it's some revolutionary technique. It's just a different input method that, for me, unlocked a different way of communicating with the AI. Your mileage may vary.

The result: a terminal that works

The site is live at davideimola.dev.

The thing I'm most happy with is the terminal aesthetic: commands as navigation, monospace headings, a design language that feels like it was made by a developer, not by someone using a portfolio template. That direction came from the AI noticing what I kept gravitating toward and suggesting something more committed.

It has character now. The old site didn't.

The tech stack is Next.js, Tailwind v4, TypeScript. Everything I'd have chosen anyway, but this time built on a design system that makes the codebase coherent instead of a collection of decisions made in different moods.

What's next

The rebuild was the experiment. What I took away from it was a method: a way of working with AI that I've since applied to other projects.

I extracted that method into something replicable. That's the next post.

2023 Retrospective

Davide Imola — Thu, 28 Dec 2023 10:18:00 +0000

Here it is, the end of 2023. What a year it has been. I've been thinking about what I want to do in 2024, but before I do that, I want to take a look back at 2023.

I am writing this retrospective for the second year in a row. I think it is a good way to reflect on the year and to think about what I want to do in the next year.

I am going to use more or less the same format as last year, but I am going to add a few more sections.

Check-in on 2023 Goals
Business
Health
Friends & Family
Community, Networking, and Speaking
Learning
Hobbies
- Series and Films
- Music
- Games
Travel
2024
Conclusions

Check-in on 2023 Goals

I had a few goals for 2023. Let's see how I did. I am going to put a ✅ if I did it, a ❌ if I did not do it, and a 🟡 if I did it, but not as much as I wanted.

For each goal, I am going to write a few words about it.

❌ Eat healthier and try to lose some weight 🥒 I did not do this. I did not eat healthier, and I did not lose any weight. I tried for a while, but I did not stick with it. I am going to try again in 2024, but for sure I need to go to an expert to help me with this.
✅ Stay healthy (you don't say) 👨🏻‍ For sure I can improve this by reducing my weight, but I think I did a good job this year. I did not get sick, and I did not have any injuries.
🟡 Read more books 📚 I read more books than last year, but I did not read as many as I wanted. I would like to read more in 2024.
✅ Improve my Skills (Golang, Kubernetes)👨🏻‍💻 This thing is based on my feelings, but I think I improved my skills this year quite a lot. I have not been certified in Kubernetes yet, but I am working on it.
🟡 Start learning Rust 🦀 I started learning Rust, but I did not do it as much as I wanted. I am going to continue learning it in 2024.
✅ Finish the work in the house and move in with Sara 🏡 We did it! We finished the work in the house, and we moved in. We are very happy with the result. We still have some things to do, but we are living in the house, and we are very happy.
✅ Make a long trip (January is coming… Emirates-Qatar-Oman… 🛳️🤫) I went in a cruise in January in Emirates, and it was amazing. I am going to write a more detailed thing in the travel section.
✅ Try to organize something incredible for the community ❤️ I organized the Open Source Day 2023, and it was amazing. I am going to write a more detailed thing in the community section.
✅ Have a speech at a conference or meetup Oh yes! I did it!!! I had the pleasure to speak to 5 different conferences. I am going to write a more detailed thing in the speaking section.

At the end, I am happy with what I did. I did not do everything I wanted, but I did a lot of things. I am going to try to do better in 2024.

Of course, my greatest delusion is not losing weight. But, as I already said, I am going to try again in 2024.

Business

Pretty much the same as last year. I am still working at RedCarbon, and I am still very happy with it.

My role is still the same, but I am doing a lot more things. I am working on a lot of different projects, and I am learning a lot of new things.

My commitment is always at my best, and I am truly happy that is recognized by my colleagues and my boss. In fact, I got a promotion and a bonus this year, and I am very proud of myself.

Health

As the previous year, I need to focus more on this. I am not eating healthier, and I am not doing so much exercises.

I know that my actual status is not so good, a lot of friends told me that, and I know that I need to change it. I am going to try to do better in 2024.

Friends & Family

I moved in with Sara (my girlfriend), and we are very happy. We are still working on the house, but we are living in it, and we are very happy. Finally, I can invite my friends to my house, where we can play board games, watch series, and have fun.
I am still in touch with my friends, I'm usually hanging out with them once a week, and I am very happy about it. Also, I made some new friends by organizing the Open Source Day and going to conferences.

In conclusion, I can say that I am pretty satisfied with this part of my life.

Community, Networking, and Speaking

Here it is, one of the newest additions to the retrospective. I am going to talk about the community, networking, and speaking.
2023 was game-changing for me. I started to be more active in the community, and I started to speak at conferences.

First of all, I have been one of the organizers for the Open Source Day 2023. It was a great experience, and I am very happy about the outcome. I met a lot of new people, and I learned a lot of new things. I am going to organize it with the SH folks again in 2024, and I am going to try to make it even better.

Visualizza questo post su Instagram
Un post condiviso da Davide Imola (@davideimola)

Second, I had the courage to start proposing talks, and unexpectedly, I got accepted to speak at 4 different conferences. I am going to list them here:

This was a great achievement for me. By speaking at these conferences, I met a lot of new people, and I learned a lot of new things. I am going to try to speak at more conferences in 2024.

Visualizza questo post su Instagram
Un post condiviso da Davide Imola (@davideimola)

Third, I have finally organized a few meetups in my hometown. Probably, this was one of the most beautiful things I did in 2023. The reasons are pretty simple. Verona is not a big city, and it is not easy to find meetups here. I wanted to change this, and I did it! I organized 3 meetups in 2023, thanks to AQuest, and I am going to organize more in 2024.

Learning

Learning is one of the most important things for me. I am always trying to learn new things, and I am always trying to improve my skills.
This year is no different. I started to learn Rust, and I am going to continue learning it in 2024.

I also started to increase my knowledge about Kubernetes and Go, and finally I can say that I am pretty confident with them. Of course, I still have a lot to learn!

This year I also understand that I'd like to learn more about security, Artificial Intelligence, and mobile development. I am going to try to learn more about these topics in 2024.

Hobbies

For this year retro, I'd like to give more space to my hobbies. I think it is important to talk about them, and I think it is important to write about them, so people can know me better.
I am going to talk a little more deeply about series and films, music, and games.

Series and Films

Ok let's start with series and films. Starting from the series, I watched a lot of them, and I am going to list a few of them here, in no particular order like an honorable mention:

The Bear: What is this one?! Frustration, anger, stress, and a lot of other feelings. This is a short series, and it is very well done. It is a great cooking serie, but not only that. I am not going to spoil anything, but I can say that it is worth watching it.
DAHMER - Monster: This is a great series. It is about the life of Jeffrey Dahmer, a very famous serial killer. It's not easy to watch it, but it is very well done.
The Good Place: This is a comedy series, and it is very funny. I really enjoyed it.

Now, let's talk about films. I really love going to the cinema, and I really love watching films. I watched a lot of films this year, and I am going to list a few of them here, in no particular order like an honorable mention:

Oppenheimer: Christopher Nolan. I should not say anything else. One of the best biographical films I have ever seen. Through the life of J. Robert Oppenheimer, we can see the story of the atomic bomb. I do love the way the film brings you some very deep thoughts.
Barbie: I went to the cinema with my girlfriend to watch this film, but I did not expect it to be so good. Fun but also deep. I really enjoyed it.
Top Gun: Maverick: I like the first Top Gun, so I watched this sequel. In my opinion, this is better than the first one.
The Northman: I recovered this film this year. For sure, I can say I am a huge fan of the Vikings mythology, and this film does not disappoint me. I really enjoyed it.
The Lego Movie: Another film that I recovered this year. I do love Lego, but I have always thought that this film was for kids. I was wrong. It is a very funny film with a lot of references to other series or films!

Music

I think one image may be enough to describe my music taste. My Spotify Wrapped 2023:

Games

From my childhood, I have always loved playing games. From video games to board games, I love them all. Unfortunately, I am not very consistent with them. I play a lot for a few months, and then I stop playing for a few months.
This year, also because of the house renovation, I did not have a lot of time to play, but I played a few games that I really enjoyed.

The Legend of Zelda: Tears of the Kingdom: Breath of the Wild is one of my favorite games ever, so I was very excited to play this sequel. I pre-ordered it as soon as I could, and I played from the Day One. Unfortunately, I did not have the time to finish it, but I am really enjoining it. If BOTW was good, this one is even better.
Hogwarts Legacy: I am a huge fan of Harry Potter, and I am a huge fan of RPG games. This game is a dream come true for me. I can not explain the feelings I had when I saw for the first time Hogwarts in this game. Probably, is not the best game ever, but I can not be objective with this one. I love it.
Munchkin: As I said earlier, I also love bord games. I played a few of them this year, but I'd like to mention Munchkin. It is a very fun game to play with friends.
Si, Oscuro Signore!: This is an Italian game, and it is very fun to play with friends. This is a very interesting game because you have to create stories and characters. It is like a Dungeons and Dragons, but far more simple. You don't need a game master, and you don't need to create a character. You just need to play as a Goblin or the Dark Overlord.
Ka-Blab: This is one of my latest purchases. I got it quite by accident, as I was looking for a simple game to play with a few friends. It is a very simple game, but it is very fun to play.

Travel

Finally, I can talk about travel. I love traveling, and I love visiting new places. This year I did not travel a lot, but I did a few things.
I had a cruise in January, and it was amazing. I visited a lot of new places!

I visited Dubai and Abu Dhabi in the Emirates. I went to the top of the Burj Khalifa, and it wasn't so amazing, because I suffer from vertigo. 🤦🏻‍
I also visited the Sheikh Zayed Grand Mosque, and it was by far one of the most luxurious places I have ever seen.

Visualizza questo post su Instagram
Un post condiviso da Davide Imola (@davideimola)

Everything is so big there. Including the malls. They also have a ski slope inside a mall. It is crazy!

In the same cruise, I also visited Doha in Qatar. Qatar was the country that hosted the 2022 FIFA World Cup, so I found a lot of things still related to football. As I understood from the locals, Doha is a very modern city, and it is growing very fast. So I think it is worth visiting it again in a few years.

Last, but not least, I visited Muscat in Oman. Unfortunately, I did not have a lot of time to visit it, but I really enjoyed it. I visited the Sultan Qaboos Grand Mosque, and it was amazing. I also visited the Mutrah Souq, and it was very interesting.

In this year, I also visited a few places in Italy. I visited Trento and Arco in Trentino Alto Adige. I have also been three times in Florence this year, I can say I am starting to know it very well!

Udine, or better, San Daniele del Friuli (for the ham) and Torino, are the other two cities I visited this year. I don't have a lot to say about them, but I would like to mention one thing about Torino. The Egyptian Museum, I had the opportunity to visit it with a guide thanks to my company. It is something out of this world. It gives me the chills just thinking about it. I can not explain the feelings I had when I saw the mummies. I think it is something that everyone should see at least once in their life. Now, I would like to return in Egypt to see the pyramids and the other things I did not have the opportunity to see.

2024

I think I have talked enough about 2023. Now, it is time to look forward to 2024. As the last year, I want to set some goals for the next year.
For the next year, I want to focus more on my health and my hobbies. I know, as a developer, it is not easy to find the time to do everything, but I think it is important to find the time to do the things you love.

So, let's start:

I want to lose weight. I know it is not easy, but I want to try. I want to start going to walk more and try to eat better.
My girlfriend has gifted me a board game of the Lord of the Rings. I want to organize a good campaign with my friends!
Start playing at role-playing games again. But this time, I want to do it more consistently.
I want to organize more and more meetups in Verona!
I want to learn more about security, Artificial Intelligence, and mobile development.
I would love to organize a better event for the next Open Source Day!
Create more content for my blog, YouTube channel, and Twitch channel.

Conclusions

And that's all. It seems that only yesterday I was writing the 2022 retrospective, and now I am writing the 2023 one. Time flies, and I think it is important to stop and think about what you have done in the last year. I think it is important to think about what you have done, and what you want to do in the next year.

I hope you enjoyed reading this post, and I hope you will have a great 2024!

Level UP your RDBMS Productivity in GO

Davide Imola — Tue, 05 Dec 2023 13:30:00 +0000

IMPORTANT: All the things in this article are highly opinionated, and they are not a standard. I'm just sharing my experience and what I think is the best way to do it.
If you have a better way to do it, please let me know in the comments. Examples are in PostgreSQL, but you can use the same approach for MySQL, SQLite, etc.

No DB have been harmed in the making of this article, but a couple was truncated. 🤫

Let's start with the actual status

Handling SQL DataBases in GO, as for different languages, can bring a lot of pain and frustration.

We may encounter a lot of problems, like:

Handling the DB Code

For sure, you have seen a lot of code like this:

func (s *Store) ListUsers(ctx context.Context) ([]User, error) {
    rows, err := s.db.QueryContext(ctx, "SELECT * FROM users")
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var users []User
    for rows.Next() {
        var user User
        if err := rows.Scan(&user.ID, &user.Name, &user.Email); err != nil {
            return nil, err
        }
        users = append(users, user)
    }
    if err := rows.Err(); err != nil {
        return nil, err
    }
    return users, nil
}

Isn't it beautiful? ?? Let's be honest! It's not! Who loves writing again and again all this code? I don't!

No, Copilot (or any generative AI 🤖) is not the solution.

Finding hidden errors in SQL

We may have a lot of errors in our SQL code that we can't find until we run the code.

Let's play! Can you find the error in this code? If, yes write it in the comments.

func (s *Store) ListUsers(ctx context.Context) ([]User, error) {
    rows, err := s.db.QueryContext(ctx, "SELECT * FROM upsers")
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var users []User
    for rows.Next() {
        var user User
        if err := rows.Scan(&user.ID, &user.Name, &user.Email); err != nil {
            return nil, err
        }
        users = append(users, user)
    }
    if err := rows.Err(); err != nil {
        return nil, err
    }
    return users, nil
}

SQL Injection

Security? What is that? 🤔 Let's take this code as example:

func (s *Store) GetUser(ctx context.Context, id string) (*User, error) {
    var user User
    row := s.db.QueryRow(ctx, fmt.Sprintf("SELECT * FROM users WHERE id = %s", id)

    var u User

    err := row.Scan(&u.ID, &u.Name)
    return &user, nil
}

As you see, we are using fmt.Sprintf to build our query. This is a very bad practice because we are exposing ourself to SQL Injection.

SQL Injection is a code injection technique that might destroy your database. It is one of the most common web hacking techniques.

For example, in this case, if the user pass as id the value 1 OR 1=1 the query will be:

SELECT * FROM users WHERE id = 1 OR 1=1

And this will return all the users in the database.

Code and Database Synchronization

Maintaining synchronization between code and the database schema is critical to avoid runtime errors:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
);

func (s *Store) ListUsers(ctx context.Context) ([]User, error) {
    rows, err := s.db.QueryContext(ctx, "SELECT * FROM upsers")
    // ...
}

Adding a new column in the database without updating the code could lead to errors.

Manual type sync and possible downtimes

Doing things manually is always a bad idea. Because we are humans and we make mistakes.

And if we are going to do things manually, we may have some downtime in our application. Because we need to stop the application, run the migration, and then start the application again.

This is not a good idea, especially if we have a lot of users.

Automated tests with DB (Why mocking is not a good idea)

When performing unit tests, we are always going to mock the DB, because we don't want to bring the DB up and down for every test.

But, mocking the DB is not a good idea, because we are not testing the real code. We are testing a fake code that we wrote.

So, if we have a bug in our SQL code, we are not going to find it, until we are gonna run it somewhere.

What can we do?

Ok, we have seen a lot of problems, but what can we do to solve them? 🤔

In this article, we are gonna see how to solve all these problems with the help of some tools and paradigms.

SQL-first approach
Migrations
Test containers (or Docker test)

SQL-first approach

The SQL-first approach is a paradigm that focuses on writing the SQL code first and then generate the code.

This approach is very useful because we are gonna focus on the SQL code and not how to handle it inside the code.

There are other approaches which you can use, like:

ORM (Object Relational Mapping)
Query Builders

ORM

ORM is a programming technique that enables a seamless conversion between data stored in a relational database table to an object-oriented programming language.

So you are going to create a code like the following:

// Read
var product Product
db.First(&product, 1) // find product with integer primary key
db.First(&product, "code = ?", "D42") // find product with code D42

// Update - update product's price to 200
db.Model(&product).Update("Price", 200)
// Update - update multiple fields
db.Model(&product).Updates(Product{Price: 200, Code: "F42"}) // non-zero fields

I don't like so much, not ony because I think the APIs built for Go are not ugly, but you are not writing SQL code, you are writing code that is going to generate SQL code. Also, you can't use all the features of the DB.

Query Builders

Query Builders are tools or libraries that provide a way to programmatic and or fluent way to create SQL queries.

For example, you can write code like this:

users := sq.Select("*").From("users").Join("emails USING (email_id)")

active := users.Where(sq.Eq{"deleted_at": nil})

sql, args, err := active.ToSql()

sql == "SELECT * FROM users JOIN emails USING (email_id) WHERE deleted_at IS NULL"

The problem with this approach is that you don't generate type-safe code. You are just generating a string that you are going to pass to the DB.

So, you still need to map your data and maintains all the types.

Also, just for the record, I don't like the syntax of this library. I think it's not so readable. Because, you are mixing the SQL code with the Go code.

SQL-first approach vs ORM vs Query Builders

I think the SQL-first approach is the best approach because you are writing SQL code and you are generating type-safe code.

Also, you can use all the features of the DB, like JSONB filtering, etc.

So I have made this table to compare the different approaches:

Feature	SQL-first	ORM	Query Builders
Type-safe	✅	✅	❌
All DB features	✅	❌	✅
Protect you from SQL Injection	✅	✅	❌
Clean API	✅	❌ (in GO)	❌
Code generation	✅	❌	❌
I like it	✅✅✅✅	❌	❌

Use a mixed approach

The best thing you can do is to use a mixed approach. You can use the SQL-first approach for the most common queries and then use the ORM or Query Builders for the rest.

Because, not all the queries are the same. Some queries are very simple and you don't need to write a lot of code, but some queries are very complex and you need to write a lot of code.

Also they may change during the execution depending to different factors. So, an SQL-first approach is not the best solution in this case.

Migrations

Migrations are a way to keep your DB schema in sync with your code. They are very useful because you can keep track of all the changes you made to the DB.

Also, you can use them to create the DB schema from scratch.

The migrations consists of 2 parts:

Up - The code that is going to be executed when you are going to run the migration
Down - The code that is going to be executed when you are going to rollback the migration

For example, let's say that we want to create a table called users with the following schema:

-- migrate:up

CREATE TABLE users (
    id VARCHAR PRIMARY KEY,
    name VARCHAR NOT NULL,
    email VARCHAR NOT NULL,
    created_at TIMESTAMP NOT NULL DEFAULT NOW(),
    updated_at TIMESTAMP NOT NULL DEFAULT NOW()
);

-- migrate:down

DROP TABLE users;

Migrations are usually stored inside a directory within the source code and they are named with a timestamp and a name.

They can be executed in 2 ways:

Manually: You can run the migration manually with a CLI
Automatically: You can run the migration automatically when the application starts
- By running the migration inside the code
- By running the migration through a Job or a CronJob

Evolutionary Database Design

Evolutionary Database Design is a technique that allows you to evolve your database schema in a simple and agile way.

The idea is to create a migration for every change you make to the DB schema. So, you can keep track of all the changes you made.

If you want to add a breaking change, you must introduce it in multiple steps. Because, you can't break the application.

If you want to learn more about this technique, I suggest you to read the following article at this link.

Test containers (or Docker Test)

Of firstly we have talked about the problems of mocking the DB. So, how can we test our code without mocking the DB?

The answer is simple: Test containers.

Test containers are a way to run a real DB instance inside a container and then run the tests against it. So, we are going to test the real implementation of the code.

For example, let's say that we want to test a code which is going to interact with a DB.

With test containers, we can run a real DB instance inside a container and then run the tests against it.

There's no magic here. We are just running a real DB in a "Dockerized" environment. So, you are sure that the code is working as expected where it's gonna run.

Also, you can run the tests in parallel, because you are not sharing the DB instance with other tests.

The best thing is that you can run the tests in your CI/CD pipeline. So, you are sure that the code is working as expected. You must simply have a Docker environment.

This thing does not apply only to the DB, but to all the external services you are using in your application, like Redis, Kafka, etc.

Let's code

Ok, now that we have seen the theory, let's see how to do it in practice.

For the purpose of this article, we are going to set up a simple application that is going to handle users.

The application is going to expose the following proto service.

service UsersService {
  rpc CreateUser(CreateUserRequest) returns (CreateUserResponse) {}
  rpc ListUsers(ListUsersRequest) returns (ListUsersResponse) {}
  rpc DeleteUser(DeleteUserRequest) returns (DeleteUserResponse) {}
  rpc GetUser(GetUserRequest) returns (GetUserResponse) {}
}

I have decided to use gRPC because it's a very simple protocol and it's very easy to use.

So, let's start with the code.

Create the schema

The first thing we are going to do is to create the schema of the DB.

As we want to maintain the track of our changes to the DB, we are going to use migrations. In this case, we are going to use dbmate. But, you can use any other tool you want.

So, let's create the first migration by performing the following commands in the terminal:

dbmate n init_users_table

This is going to create a new migration file called XXXXXXXXXXXXX_init_users_table.sql, where XXXXXXXXXXXXX is a timestamp.

Now, let's open the file and write the following code:

-- migrate:up

CREATE TABLE users (
    id VARCHAR PRIMARY KEY,
    name VARCHAR NOT NULL,
    created_at TIMESTAMP NOT NULL DEFAULT NOW(),
    updated_at TIMESTAMP NOT NULL DEFAULT NOW()
);

-- migrate:down

DROP TABLE users;

As you see, we have created a table called users with the following columns:

id - The ID of the user
name - The name of the user
created_at - The creation date of the user
updated_at - The update date of the user

Now, let's run the migration by creating a .env file with the environment variable with the DB connection string, and after performing the following command in the terminal:

dbmate up

This is going to create the table in the DB and a schema file which is going to be used by the code generator.

Generate the code

Now, we are going to generate the code. For this purpose, we are going to use sqlc.

First of all we need to create a sqlc configuration file called sqlc.yaml with the following content:

version: "2"
sql:
  - engine: "postgresql"
    queries: "internal/queries/"
    schema: "db/migrations/"
    gen:
      go:
        package: "queries"
        out: "internal/queries/"
        sql_package: "pgx/v5"

This is going to tell sqlc where to find the queries and the schema files, and where to generate the code.

Now, let's create the queries file called internal/queries/users.sql with the following content:

-- name: ListUsers :many
SELECT * FROM users LIMIT sqlc.arg('limit') OFFSET sqlc.arg('offset');

-- name: CountUsers :one
SELECT COUNT(*) FROM users;

-- name: CreateUser :one
INSERT INTO users (name) VALUES (@name) RETURNING *;

-- name: DeleteUser :one
DELETE FROM users WHERE id = @id RETURNING *;

-- name: GetUser :one
SELECT * FROM users WHERE id = @id LIMIT 1;

As you see, we have created the queries we need to handle the users. We have also added some arguments to the queries.

Now, let's generate the code by performing the following command in the terminal:

sqlc generate

This is going to generate the code inside the internal/queries directory.

Going back to the implementation of the service we are going to import the generated package and by using the generated Queries struct.

For example, let's say that we want to implement the ListUsers method. We are going to write the following code:

type srv struct {
    q *queries.Queries
}

func NewUsersService(q *queries.Queries) usersv1connect.UsersServiceHandler {
    return &srv{
        q: q,
    }
}

func (s srv) ListUsers(ctx context.Context, req *connect_go.Request[v1.ListUsersRequest]) (*connect_go.Response[v1.ListUsersResponse], error) {
    users, err := s.q.ListUsers(ctx, queries.ListUsersParams{
        Offset: req.Msg.Offset,
        Limit:  req.Msg.Limit,
    })
    if err != nil {
        return nil, err
    }

    tot, err := s.q.CountUsers(ctx)

    res := make([]*v1.User, len(users))
    for i, user := range users {
        res[i] = newUser(user)
    }

    return connect_go.NewResponse(&v1.ListUsersResponse{
        Users: res,
        Totat: int32(tot),
    }), nil
}

As you see, we are using the generated Queries struct to perform all the queries we need.

Run the tests

Now, let's run the tests. For this purpose, we are going to use dockertest, but test containers is also a good solution.

First of all, we need to configure the Postgres container, in dockertest, first of all we need to create a Pool and creating the resource.

The resource can be internally expose py performing a port mapping. In this case, we are going to expose the port 5432/tcp as we are working with Postgres, dockertest is going to find a free port and expose it.

The container can be configured by passing environment variables, arguments, etc.

As the code is a bit long, I'm not going to paste it here, but you can find it here.

Now, let's write the actual test. Firstly we need to perform the InitPostgres function to initialize the Postgres container inside the TestMain function.

Then, we need to create a new Queries struct by passing the connection string to the NewUsersService function.

Now, we can perform the tests. For example, let's say that we want to test the ListUsers method. We are going to write the following code:

func TestListEmptyUsers(t *testing.T) {
    ctx := context.Background()
    req := connect.NewRequest(&v1.ListUsersRequest{
        Offset: 0,
        Limit:  10,
    })

    resp, err := usersCli.ListUsers(ctx, req)
    if err != nil {
        t.Fatalf("Could not list users: %s", err)
    }

    assert.Nil(t, err)
    assert.Equal(t, int32(0), resp.Msg.Totat)
}

By running the test, we are going to see that the test is passing!

Conclusions

In this article, we have seen how to improve our RDBMS productivity in GO. We have seen how to use the SQL-first approach, migrations, and test containers.

We have also seen the benefits of using these tools and how to use them in a real application.

If you want to see the full code, you can find it here.

I hope you have enjoyed this article. If you have any questions, please let me know in the comments.

Securing Secrets in the Age of GitOps

Davide Imola — Fri, 27 Oct 2023 09:07:21 +0000

Kubernetes and GitOps offer a powerful way to manage your infrastructure and applications. However, when it comes to securing sensitive information like passwords, tokens, and certificates, challenges arise. In this article, we'll explore different methods to secure secrets in the GitOps era and how to seamlessly integrate them into your workflows.

The Power of Kubernetes Secrets

Kubernetes provides a dedicated solution for safeguarding sensitive data: Secrets. These are Kubernetes objects designed to securely store information like passwords, OAuth tokens, and SSH keys. Using Secrets is a safer and more versatile approach compared to embedding sensitive data directly into Pod definitions or container images.

But, as powerful as Secrets are, there's a significant challenge when it comes to managing them within a GitOps workflow.

The GitOps Conundrum

GitOps revolves around using Git as the single source of truth for declarative infrastructure and applications. With Git at the heart of your delivery pipelines, developers can accelerate application deployments and streamline operations tasks in Kubernetes through pull requests.

However, when it comes to secrets, things get complicated. Secrets can't be stored directly in a Git repository because the data isn't encrypted; it's merely encoded in base64. Here's an example:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
  namespace: default
data:
  foo: YmFy

To highlight the security issue with this approach, let's decode the data:

$ echo YmFy | base64 -d
bar

As you can see, if someone gains access to the Git repository, they can effortlessly decode the data and compromise the secret.

Introducing Sealed Secrets

The solution to this problem is Sealed Secrets, a Kubernetes Custom Resource Definition Controller. It enables the encryption of Secrets, allowing you to store them in Git repositories safely. A Sealed Secret is shareable, even in public repositories, and can be given to colleagues, all while remaining impenetrable. Only the controller running in the target cluster can decrypt the Sealed Secret.

Using Sealed Secrets is straightforward. First, install the controller in your cluster using a Helm chart:

$ helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
$ helm install sealed-secrets sealed-secrets/sealed-secrets

After installation, you can use the kubeseal CLI to retrieve the public key and encrypt your secrets with it:

# Retrieve the public key
$ kubeseal --fetch-cert --controller-namespace=sealed-secrets --controller-name=sealed-secrets > pub-cert.pem

# Encrypt a secret
$ kubeseal --cert=pub-cert.pem --format=yaml < mysecret.yaml > mysealedsecret.yaml

The beauty of Sealed Secrets is that you can store the sealed secret in a Git repository and apply it to the cluster. The controller will decrypt the secret, creating the original Secret without requiring any changes to your app's Deployment.

Exploring Secrets Managers

Another approach for managing secrets in a GitOps workflow is using a Secrets Manager. These tools offer secure storage and management of secrets and come with numerous features, including encryption, access control, auditing, secret rotation, and more. Notable examples include:

While Secrets Managers offer robust security, they come with certain drawbacks, such as not being Kubernetes-native, a steep learning curve, costs (except for HashiCorp Vault's open-source version), and complex installation and maintenance.

Bridging the Gap with Secret Store CSI Driver

To incorporate a Secrets Manager seamlessly into your GitOps workflow, consider using the Secret Store CSI Driver. It's a Kubernetes CSI driver that allows you to store and manage secrets in Kubernetes using your preferred Secrets Manager. This Kubernetes-native solution is easy to install and maintain, free, and open source. It supports a variety of Secrets Managers through provider-specific modules:

For detailed guidance on implementing these providers, refer to the documentation.

Leveraging SDKs

Alternatively, you can integrate a Secrets Manager into your GitOps workflow by using SDKs provided by the Secrets Manager. These SDKs are available for various programming languages and can be incorporated into your application code to retrieve secrets. This approach offers flexibility but comes with the need to modify application code, manage SDKs within the application, and control access to the Secrets Manager.

Making the Right Choice

In this post, we've explored multiple methods for securing secrets in a GitOps workflow. The decision ultimately rests with you, as you choose the solution that best aligns with your specific needs. However, it's crucial to prioritize security in your decision-making process. Choose wisely, and ensure your secrets remain safe and sound.