{"id":2259,"date":"2025-07-17T14:38:18","date_gmt":"2025-07-17T14:38:18","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/07\/17\/gofiber-v3-testcontainers-production-like-local-dev-with-air\/"},"modified":"2025-07-17T14:38:18","modified_gmt":"2025-07-17T14:38:18","slug":"gofiber-v3-testcontainers-production-like-local-dev-with-air","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/07\/17\/gofiber-v3-testcontainers-production-like-local-dev-with-air\/","title":{"rendered":"GoFiber v3 + Testcontainers: Production-like Local Dev with Air"},"content":{"rendered":"

Intro<\/strong><\/h2>\n

Local development can be challenging when apps rely on external services like databases or queues, leading to brittle scripts and inconsistent environments. Fiber v3 and Testcontainers<\/a> solve this by making real service dependencies part of your app\u2019s lifecycle, fully managed, reproducible, and developer-friendly.<\/p>\n\n

With the upcoming v3 release, Fiber is introducing a powerful new abstraction: Services. These provide a standardized way to start and manage backing services like databases, queues, and cloud emulators, enabling you to manage backing services directly as part of your app\u2019s lifecycle, with no extra orchestration required. Even more exciting is the new contrib module that connects Services with Testcontainers, allowing you to spin up real service dependencies in a clean and testable way.<\/p>\n\n

In this post, I\u2019ll walk through how to use these new features by building a small Fiber app that uses a PostgreSQL container for persistence, all managed via the new Service interface.<\/p>\n\n

TL;DR<\/strong><\/h2>\n

Use Fiber v3\u2019s new Services API to manage backing containers.<\/p>\n

Integrate with testcontainers-go to start a PostgreSQL container automatically.<\/p>\n

Add hot-reloading with air for a fast local dev loop.<\/p>\n

Reuse containers during dev by disabling Ryuk and naming them consistently.<\/p>\n

Full example here: GitHub Repo<\/a><\/p>\n\n

Local Development, state of the art<\/strong><\/h2>\n

This is a blog post about developing in Go, but let\u2019s look at how other major frameworks approach local development, even across different programming languages.<\/p>\n\n

In the Java ecosystem, the most important frameworks, such as Spring Boot, Micronaut and Quarkus, have the concept of Development-time services. Let\u2019s look at how other ecosystems handle this concept of services.<\/p>\n\n

From Spring Boot docs<\/a>:<\/p>\n\n

Development-time services provide external dependencies needed to run the application while developing it. They are only supposed to be used while developing and are disabled when the application is deployed.<\/em><\/p>\n\n

Micronaut uses the concept of Test Resources<\/a>:<\/p>\n\n

Micronaut Test Resources adds support for managing external resources which are required during development or testing.<\/em><\/p>\n

For example, an application may need a database to run (say MySQL), but such a database may not be installed on the development machine or you may not want to handle the setup and tear down of the database manually.<\/em><\/p>\n\n

And finally, in Quarkus, the concept of Dev Services<\/a> is also present.<\/p>\n\n

Quarkus supports the automatic provisioning of unconfigured services in development and test mode. We refer to this capability as Dev Services.<\/em><\/p>\n\n

Back to Go, one of the most popular frameworks, Fiber<\/a>, has added the concept of Services, including a new contrib module to add support for Testcontainers-backed services.<\/p>\n\n

What\u2019s New in Fiber v3?<\/strong><\/h2>\n\n

Among all the new features in Fiber v3, we have two main ones that are relevant to this post:<\/p>\n

Services<\/a>: Define and attach external resources (like databases) to your app in a composable way. This new approach ensures external services are automatically started and stopped with your Fiber app.<\/p>\n

Contrib module for Testcontainers<\/a>: Start real backing services using Docker containers, managed directly from your app\u2019s lifecycle in a programmable way.<\/p>\n

A Simple Fiber App using Testcontainers<\/strong><\/h2>\n\n

The application we are going to build is a simple Fiber app that uses a PostgreSQL container for persistence. It\u2019s based on todo-app-with-auth-form Fiber recipe<\/a>, but using the new Services API to start a PostgreSQL container, instead of an in-memory SQLite database.<\/p>\n\n

Project Structure<\/strong><\/p>\n

\n.
\n\u251c\u2500\u2500 app
\n| \u251c\u2500\u2500 dal
\n| | \u251c\u2500\u2500 todo.dal.go
\n| | \u251c\u2500\u2500 todo.dal_test.go
\n| | \u251c\u2500\u2500 user.dal.go
\n| | \u2514\u2500\u2500 user.dal_test.go
\n| \u251c\u2500\u2500 routes
\n| | \u251c\u2500\u2500 auth.routes.go
\n| | \u2514\u2500\u2500 todo.routes.go
\n| \u251c\u2500\u2500 services
\n| | \u251c\u2500\u2500 auth.service.go
\n| | \u2514\u2500\u2500 todo.service.go
\n| \u2514\u2500\u2500 types
\n| \u251c\u2500\u2500 auth.types.go
\n| \u251c\u2500\u2500 todo.types.go
\n| \u2514\u2500\u2500 types.go
\n\u251c\u2500\u2500 config
\n| \u251c\u2500\u2500 database
\n| | \u2514\u2500\u2500 database.go
\n| \u251c\u2500\u2500 config.go
\n| \u251c\u2500\u2500 config_dev.go
\n| \u251c\u2500\u2500 env.go
\n| \u2514\u2500\u2500 types.go
\n\u251c\u2500\u2500 utils
\n| \u251c\u2500\u2500 jwt
\n| | \u2514\u2500\u2500 jwt.go
\n| \u251c\u2500\u2500 middleware
\n| | \u2514\u2500\u2500 authentication.go
\n| \u2514\u2500\u2500 password
\n| \u2514\u2500\u2500 password.go
\n\u251c\u2500\u2500 .air.conf
\n\u251c\u2500\u2500 .env
\n\u251c\u2500\u2500 main.go
\n\u2514\u2500\u2500 go.mod
\n\u2514\u2500\u2500 go.sum\n<\/div>\n

This app exposes several endpoints, for \/users and \/todos, and stores data in a PostgreSQL instance started using Testcontainers. Here\u2019s how it\u2019s put together.<\/p>\n\n

Since the application is based on a recipe, we\u2019ll skip the details of creating the routes, the services and the data access layer. You can find the complete code in the GitHub repository<\/a>.<\/p>\n\n

I\u2019ll instead cover the details about how to use Testcontainers to start the PostgreSQL container, and how to use the Services API to manage the lifecycle of the container, so that the data access layer can use it without having to worry about the lifecycle of the container. Furthermore, I\u2019ll cover how to use air to have a fast local development experience, and how to handle the graceful shutdown of the application, separating the configuration for production and local development.<\/p>\n\n

In the config package, we have defined three files that will be used to configure the application, depending on a Go build tag. The first one, the config\/types.go file, defines a struct to hold the application configuration and the cleanup functions for the services startup and shutdown.<\/p>\n

\npackage config\n

import (
\n\t“context”<\/p>\n

\t“github.com\/gofiber\/fiber\/v3”
\n)<\/p>\n

\/\/ AppConfig holds the application configuration and cleanup functions
\ntype AppConfig struct {
\n\t\/\/ App is the Fiber app instance.
\n\tApp *fiber.App
\n\t\/\/ StartupCancel is the context cancel function for the services startup.
\n\tStartupCancel context.CancelFunc
\n\t\/\/ ShutdownCancel is the context cancel function for the services shutdown.
\n\tShutdownCancel context.CancelFunc
\n}\n<\/p><\/div>\n

The config.go file has the configuration for production environments:<\/p>\n

\n\/\/go:build !dev\n

package config<\/p>\n

import (
\n\t“github.com\/gofiber\/fiber\/v3”
\n)<\/p>\n

\/\/ ConfigureApp configures the fiber app, including the database connection string.
\n\/\/ The connection string is retrieved from the environment variable DB, or using
\n\/\/ falls back to a default connection string targeting localhost if DB is not set.
\nfunc ConfigureApp(cfg fiber.Config) (*AppConfig, error) {
\n\tapp := fiber.New(cfg)<\/p>\n

\tdb := getEnv(“DB”, “postgres:\/\/postgres:postgres@localhost:5432\/postgres?sslmode=disable”)
\n\tDB = db<\/p>\n

\treturn &AppConfig{
\n\t\tApp: app,
\n\t\tStartupCancel: func() {}, \/\/ No-op for production
\n\t\tShutdownCancel: func() {}, \/\/ No-op for production
\n\t}, nil
\n}\n<\/p><\/div>\n

The ConfigureApp function is responsible for creating the Fiber app, and it\u2019s used in the main.go file to initialize the application. By default, it will try to connect to a PostgreSQL instance, using the DB environment variable, falling back to a local PostgreSQL instance if the environment variable is not set. It also uses empty functions for the StartupCancel and ShutdownCancel fields, as we don\u2019t need to cancel anything in production.<\/p>\n\n

When running the app with go run main.go, the !dev tag applies by default, and the ConfigureApp function will be used to initialize the application. But the application will not start, as the connection to the PostgreSQL instance will fail.<\/p>\n

\ngo run main.go\n

2025\/05\/29 11:55:36 gofiber-services\/config\/database\/database.go:18
\n[error] failed to initialize database, got error failed to connect to `user=postgres database=postgres`:
\n [::1]:5432 (localhost): dial error: dial tcp [::1]:5432: connect: connection refused
\n 127.0.0.1:5432 (localhost): dial error: dial tcp 127.0.0.1:5432: connect: connection refused
\npanic: gorm open: failed to connect to `user=postgres database=postgres`:
\n [::1]:5432 (localhost): dial error: dial tcp [::1]:5432: connect: connection refused
\n 127.0.0.1:5432 (localhost): dial error: dial tcp 127.0.0.1:5432: connect: connection refused<\/p>\n

goroutine 1 [running]:
\ngofiber-services\/config\/database.Connect({0x105164a30?, 0x0?})
\n gofiber-services\/config\/database\/database.go:33 +0x9c
\nmain.main()
\n gofiber-services\/main.go:34 +0xbc
\nexit status 2\n<\/p><\/div>\n

Let\u2019s fix that!<\/p>\n

Step 1: Add the dependencies<\/strong><\/p>\n\n

First, we need to make sure we have the dependencies added to the go.mod file:<\/p>\n\n

Note: Fiber v3 is still in development. To use Services, you\u2019ll need to pull the main branch from GitHub:<\/em><\/p>\n

\ngo get github.com\/gofiber\/fiber\/v3@main
\ngo get github.com\/gofiber\/contrib\/testcontainers
\ngo get github.com\/testcontainers\/testcontainers-go
\ngo get github.com\/testcontainers\/testcontainers-go\/modules\/postgres
\ngo get gorm.io\/driver\/postgres\n<\/div>\n\n

Step 2: Define a PostgreSQL Service using Testcontainers<\/strong><\/p>\n\n

To leverage the new Services API, we need to define a new service. We can implement the interface exposed by the Fiber app, as shown in the Services API docs<\/a>, or simply use the Testcontainers contrib module to create a new service, as we are going to do next.<\/p>\n\n

In the config\/config_dev.go file, we define a new function to add a PostgreSQL container as a service to the Fiber application, using the Testcontainers contrib module. This file is using the dev build tag, so it will only be used when we start the application with air.<\/p>\n

\n\/\/go:build dev\n

package config<\/p>\n

import (
\n\t“fmt”<\/p>\n

\t“github.com\/gofiber\/contrib\/testcontainers”
\n\t“github.com\/gofiber\/fiber\/v3”
\n\ttc “github.com\/testcontainers\/testcontainers-go”
\n\t“github.com\/testcontainers\/testcontainers-go\/modules\/postgres”
\n)<\/p>\n

\/\/ setupPostgres adds a Postgres service to the app, including custom configuration to allow
\n\/\/ reusing the same container while developing locally.
\nfunc setupPostgres(cfg *fiber.Config) (*testcontainers.ContainerService[*postgres.PostgresContainer], error) {
\n\t\/\/ Add the Postgres service to the app, including custom configuration.
\n\tsrv, err := testcontainers.AddService(cfg, testcontainers.NewModuleConfig(
\n\t\t“postgres-db”,
\n\t\t“postgres:16”,
\n\t\tpostgres.Run,
\n\t\tpostgres.BasicWaitStrategies(),
\n\t\tpostgres.WithDatabase(“todos”),
\n\t\tpostgres.WithUsername(“postgres”),
\n\t\tpostgres.WithPassword(“postgres”),
\n\t\ttc.WithReuseByName(“postgres-db-todos”),
\n\t))
\n\tif err != nil {
\n\t\treturn nil, fmt.Errorf(“add postgres service: %w”, err)
\n\t}<\/p>\n

\treturn srv, nil
\n}\n<\/p><\/div>\n

This creates a reusable Service that Fiber will automatically start and stop along with the app, and it\u2019s registered as part of the fiber.Config struct that our application uses. This new service uses the postgres module from the testcontainers package to create the container. To learn more about the PostgreSQL module, please refer to the Testcontainers PostgreSQL module documentation<\/a>.<\/p>\n\n

Step 3: Initialize the Fiber App with the PostgreSQL Service<\/strong><\/p>\n\n

Our fiber.App is initialized in the config\/config.go file, using the ConfigureApp function for production environments. For local development, instead, we need to initialize the fiber.App in the config\/config_dev.go file, using a function with the same signature, but using the contrib module to add the PostgreSQL service to the app config.<\/p>\n\n

We need to define a context provider for the services startup and shutdown, and add the PostgreSQL service to the app config, including custom configuration. The context provider is useful to define a cancel policy for the services startup and shutdown, so we can cancel the startup or shutdown if the context is canceled. If no context provider is defined, the default is to use the context.Background().<\/p>\n

\n\/\/ ConfigureApp configures the fiber app, including the database connection string.
\n\/\/ The connection string is retrieved from the PostgreSQL service.
\nfunc ConfigureApp(cfg fiber.Config) (*AppConfig, error) {
\n\t\/\/ Define a context provider for the services startup.
\n\t\/\/ The timeout is applied when the context is actually used during startup.
\n\tstartupCtx, startupCancel := context.WithCancel(context.Background())
\n\tvar startupTimeoutCancel context.CancelFunc
\n\tcfg.ServicesStartupContextProvider = func() context.Context {
\n\t\t\/\/ Cancel any previous timeout context
\n\t\tif startupTimeoutCancel != nil {
\n\t\t\tstartupTimeoutCancel()
\n\t\t}
\n\t\t\/\/ Create a new timeout context
\n\t\tctx, cancel := context.WithTimeout(startupCtx, 10*time.Second)
\n\t\tstartupTimeoutCancel = cancel
\n\t\treturn ctx
\n\t}\n

\t\/\/ Define a context provider for the services shutdown.
\n\t\/\/ The timeout is applied when the context is actually used during shutdown.
\n\tshutdownCtx, shutdownCancel := context.WithCancel(context.Background())
\n\tvar shutdownTimeoutCancel context.CancelFunc
\n\tcfg.ServicesShutdownContextProvider = func() context.Context {
\n\t\t\/\/ Cancel any previous timeout context
\n\t\tif shutdownTimeoutCancel != nil {
\n\t\t\tshutdownTimeoutCancel()
\n\t\t}
\n\t\t\/\/ Create a new timeout context
\n\t\tctx, cancel := context.WithTimeout(shutdownCtx, 10*time.Second)
\n\t\tshutdownTimeoutCancel = cancel
\n\t\treturn ctx
\n\t}<\/p>\n

\t\/\/ Add the Postgres service to the app, including custom configuration.
\n\tsrv, err := setupPostgres(&cfg)
\n\tif err != nil {
\n\t\tif startupTimeoutCancel != nil {
\n\t\t\tstartupTimeoutCancel()
\n\t\t}
\n\t\tif shutdownTimeoutCancel != nil {
\n\t\t\tshutdownTimeoutCancel()
\n\t\t}
\n\t\tstartupCancel()
\n\t\tshutdownCancel()
\n\t\treturn nil, fmt.Errorf(“add postgres service: %w”, err)
\n\t}<\/p>\n

\tapp := fiber.New(cfg)<\/p>\n

\t\/\/ Retrieve the Postgres service from the app, using the service key.
\n\tpostgresSrv := fiber.MustGetService[*testcontainers.ContainerService[*postgres.PostgresContainer]](app.State(), srv.Key())<\/p>\n

\tconnString, err := postgresSrv.Container().ConnectionString(context.Background())
\n\tif err != nil {
\n\t\tif startupTimeoutCancel != nil {
\n\t\t\tstartupTimeoutCancel()
\n\t\t}
\n\t\tif shutdownTimeoutCancel != nil {
\n\t\t\tshutdownTimeoutCancel()
\n\t\t}
\n\t\tstartupCancel()
\n\t\tshutdownCancel()
\n\t\treturn nil, fmt.Errorf(“get postgres connection string: %w”, err)
\n\t}<\/p>\n

\t\/\/ Override the default database connection string with the one from the Testcontainers service.
\n\tDB = connString<\/p>\n

\treturn &AppConfig{
\n\t\tApp: app,
\n\t\tStartupCancel: func() {
\n\t\t\tif startupTimeoutCancel != nil {
\n\t\t\t\tstartupTimeoutCancel()
\n\t\t\t}
\n\t\t\tstartupCancel()
\n\t\t},
\n\t\tShutdownCancel: func() {
\n\t\t\tif shutdownTimeoutCancel != nil {
\n\t\t\t\tshutdownTimeoutCancel()
\n\t\t\t}
\n\t\t\tshutdownCancel()
\n\t\t},
\n\t}, nil
\n}\n<\/p><\/div>\n

This function:<\/p>\n

Defines a context provider for the services startup and shutdown, defining a timeout for the startup and shutdown when the context is actually used during startup and shutdown.<\/p>\n

Adds the PostgreSQL service to the app config.<\/p>\n

Retrieves the PostgreSQL service from the app\u2019s state cache.<\/p>\n

Uses the PostgreSQL service to obtain the connection string.<\/p>\n

Overrides the default database connection string with the one from the Testcontainers service.<\/p>\n

Returns the app config.<\/p>\n

As a result, the fiber.App will be initialized with the PostgreSQL service, and it will be automatically started and stopped along with the app. The service representing the PostgreSQL container will be available as part of the application State, which we can easily retrieve from the app\u2019s state cache. Please refer to the State Management docs<\/a> for more details about how to use the State cache.<\/p>\n\n

Step 4: Optimizing Local Dev with Container Reuse<\/strong><\/p>\n\n

Please note that, in the config\/config_dev.go file, the tc.WithReuseByName option is used to reuse the same container while developing locally. This is useful to avoid having to wait for the database to be ready when the application is started.<\/p>\n\n

Also, set TESTCONTAINERS_RYUK_DISABLED=true to prevent container cleanup between hot reloads. In the .env file, add the following:<\/p>\n\n

\nTESTCONTAINERS_RYUK_DISABLED=true\n<\/div>\n

Ryuk<\/a> is the Testcontainers companion container that removes the Docker resources created by Testcontainers. For our use case, where we want to develop locally using air, we don\u2019t want to remove the container when the application is hot-reloaded, so we disable Ryuk and give the container a name that will be reused across multiple runs of the application.<\/p>\n\n

Step 5: Retrieve and Inject the PostgreSQL Connection<\/strong><\/p>\n\n

Now that the PostgreSQL service is part of the application, we can use it in our data access layer. The application has a global configuration variable that includes the database connection string, in the config\/env.go file:<\/p>\n\n

\n \/\/ DB returns the connection string of the database.
\n\tDB = getEnv(“DB”, “postgres:\/\/postgres:postgres@localhost:5432\/postgres?sslmode=disable”)\n<\/div>\n

Retrieve the service from the app\u2019s state and use it to connect:<\/p>\n

\n \/\/ Add the PostgreSQL service to the app, including custom configuration.
\n\tsrv, err := setupPostgres(&cfg)
\n\tif err != nil {
\n\t\tpanic(err)
\n\t}\n

\tapp := fiber.New(cfg)<\/p>\n

\t\/\/ Retrieve the PostgreSQL service from the app, using the service key.
\n\tpostgresSrv := fiber.MustGetService[*testcontainers.ContainerService[*postgres.PostgresContainer]](app.State(), srv.Key())\n<\/p><\/div>\n\n

Here, the fiber.MustGetService function is used to retrieve a generic service from the State cache, and we need to cast it to the specific service type, in this case *testcontainers.ContainerService[*postgres.PostgresContainer].<\/p>\n

testcontainers.ContainerService[T] is a generic service that wraps a testcontainers.Container instance. It\u2019s provided by the github.com\/gofiber\/contrib\/testcontainers module.<\/p>\n

*postgres.PostgresContainer is the specific type of the container, in this case a PostgreSQL container. It\u2019s provided by the github.com\/testcontainers\/testcontainers-go\/modules\/postgres module.<\/p>\n

Once we have the postgresSrv service, we can use it to connect to the database. The ContainerService type provides a Container() method that unwraps the container from the service, so we are able to use the APIs provided by the testcontainers package to interact with the container. Finally, we pass the connection string to the global DB variable, so the data access layer can use it to connect to the database.<\/p>\n\n

\n\/\/ Retrieve the PostgreSQL service from the app, using the service key.
\n\tpostgresSrv := fiber.MustGetService[*testcontainers.ContainerService[*postgres.PostgresContainer]](app.State(), srv.Key())\n

\tconnString, err := postgresSrv.Container().ConnectionString(context.Background())
\n\tif err != nil {
\n\t\tpanic(err)
\n\t}<\/p>\n

\/\/ Override the default database connection string with the one from the Testcontainers service.
\n\tconfig.DB = connString<\/p>\n

\tdatabase.Connect(config.DB)\n<\/p><\/div>\n\n

Step 6: Live reload with air<\/strong><\/p>\n\n

Let\u2019s add the build tag to the air command, so our local development experience is complete. We need to add the -tags dev flag to the command used to build the application. In .air.conf, add the -tags dev flag to ensure the development configuration is used:<\/p>\n\n

\ncmd = “go build -tags dev -o .\/todo-api .\/main.go”\n<\/div>\n

Step 7: Graceful Shutdown<\/strong><\/p>\n\n

Fiber automatically shuts down the application and all its services when the application is stopped. But air is not passing the right signal to the application to trigger the shutdown, so we need to do it manually.<\/p>\n\n

In main.go, we need to listen from a different goroutine, and we need to notify the main thread when an interrupt or termination signal is sent. Let\u2019s add this to the end of the main function:<\/p>\n\n

\n\/\/ Listen from a different goroutine
\n\tgo func() {
\n\t\tif err := app.Listen(fmt.Sprintf(“:%v”, config.PORT)); err != nil {
\n\t\t\tlog.Panic(err)
\n\t\t}
\n\t}()\n

\tquit := make(chan os.Signal, 1) \/\/ Create channel to signify a signal being sent
\n\tsignal.Notify(quit, os.Interrupt, syscall.SIGTERM) \/\/ When an interrupt or termination signal is sent, notify the channel<\/p>\n

\t<-quit \/\/ This blocks the main thread until an interrupt is received
\n\tfmt.Println(“Gracefully shutting down…”)
\n\terr = app.Shutdown()
\n\tif err != nil {
\n\t\tlog.Panic(err)
\n\t}\n<\/p><\/div>\n\n

And we need to make sure air is passing the right signal to the application to trigger the shutdown. Add this to .air.conf to make it work:<\/p>\n\n

\n# Send Interrupt signal before killing process (windows does not support this feature)
\nsend_interrupt = true\n<\/div>\n\n

With this, air will send an interrupt signal to the application when the application is stopped, so we can trigger the graceful shutdown when we stop the application with air.<\/p>\n\n

Seeing it in action<\/strong><\/h2>\n\n

Now, we can start the application with air, and it will start the PostgreSQL container automatically, and it will handle the graceful shutdown when we stop the application. Let\u2019s see it in action!<\/p>\n\n

Let\u2019s start the application with air. You should see output like this in the logs:<\/p>\n\n

\nair\n

`.air.conf` will be deprecated soon, recommend using `.air.toml`.<\/p>\n

__ _ ___
\n\/ \/ | | | |_)
\n\/_\/– |_| |_| _ v1.61.7, built with Go go1.24.1<\/p>\n

mkdir gofiber-services\/tmp
\nwatching .
\nwatching app
\nwatching app\/dal
\nwatching app\/routes
\nwatching app\/services
\nwatching app\/types
\nwatching config
\nwatching config\/database
\n!exclude tmp
\nwatching utils
\nwatching utils\/jwt
\nwatching utils\/middleware
\nwatching utils\/password
\nbuilding…
\nrunning…
\n[DATABASE]::CONNECTED<\/p>\n

2025\/05\/29 07:33:19 gofiber-services\/config\/database\/database.go:44
\n[89.614ms] [rows:1] SELECT count(*) FROM information_schema.tables WHERE table_schema = CURRENT_SCHEMA() AND table_name = ‘users’ AND table_type = ‘BASE TABLE’<\/p>\n

2025\/05\/29 07:33:19 gofiber-services\/config\/database\/database.go:44<\/p>\n

[31.446ms] [rows:0] CREATE TABLE “users” (“id” bigserial,”created_at” timestamptz,”updated_at” timestamptz,”deleted_at” timestamptz,”name” text,”email” text NOT NULL,”password” text NOT NULL,PRIMARY KEY (“id”))<\/p>\n

2025\/05\/29 07:33:19 gofiber-services\/config\/database\/database.go:44
\n[28.312ms] [rows:0] CREATE UNIQUE INDEX IF NOT EXISTS “idx_users_email” ON “users” (“email”)<\/p>\n

2025\/05\/29 07:33:19 gofiber-services\/config\/database\/database.go:44
\n[28.391ms] [rows:0] CREATE INDEX IF NOT EXISTS “idx_users_deleted_at” ON “users” (“deleted_at”)<\/p>\n

2025\/05\/29 07:33:19 gofiber-services\/config\/database\/database.go:44
\n[28.920ms] [rows:1] SELECT count(*) FROM information_schema.tables WHERE table_schema = CURRENT_SCHEMA() AND table_name = ‘todos’ AND table_type = ‘BASE TABLE’<\/p>\n

2025\/05\/29 07:33:19 gofiber-services\/config\/database\/database.go:44
\n[29.659ms] [rows:0] CREATE TABLE “todos” (“id” bigserial,”created_at” timestamptz,”updated_at” timestamptz,”deleted_at” timestamptz,”task” text NOT NULL,”completed” boolean DEFAULT false,”user” bigint,PRIMARY KEY (“id”),CONSTRAINT “fk_users_todos” FOREIGN KEY (“user”) REFERENCES “users”(“id”))<\/p>\n

2025\/05\/29 07:33:19 gofiber-services\/config\/database\/database.go:44
\n[27.900ms] [rows:0] CREATE INDEX IF NOT EXISTS “idx_todos_deleted_at” ON “todos” (“deleted_at”)<\/p>\n

_______ __
\n \/ ____(_) \/_ ___ _____
\n \/ \/_ \/ \/ __ \/ _ \/ ___\/
\n\/ __\/ \/ \/ \/_\/ \/ __\/ \/
\n\/_\/ \/_\/_.___\/___\/_\/ v3.0.0-beta.4
\n————————————————–
\nINFO Server started on: http:\/\/127.0.0.1:8000 (bound on host 0.0.0.0 and port 8000)
\nINFO Services: 1
\nINFO [ RUNNING ] postgres-db (using testcontainers-go)
\nINFO Total handlers count: 10
\nINFO Prefork: Disabled
\nINFO PID: 36210
\nINFO Total process count: 1\n<\/p><\/div>\n\n

If we open a terminal and check the running containers, we see the PostgreSQL container is running:<\/p>\n\n

\ndocker ps
\nCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
\n8dc70e1124da postgres:16 “docker-entrypoint.s\u2026” 2 minutes ago Up 2 minutes 127.0.0.1:32911->5432\/tcp postgres-db-todos\n<\/div>\n\n

Notice two important things:<\/p>\n\n

the container name is postgres-db-todos, that\u2019s the name we gave to the container in the setupPostgres function.<\/p>\n

the container is mapping the standard PostgreSQL port 5432 to a dynamically assigned host port 32911 in the host. This is a Testcontainers feature to avoid port conflicts when running multiple containers of the same type, making the execution deterministic and reliable. To learn more about this, please refer to the Testcontainers documentation<\/a>.<\/p>\n

Fast Dev Loop<\/strong><\/p>\n\n

If we now stop the application with air, we see the container is stopped, thanks to the graceful shutdown implemented in the application.<\/p>\n\n

But, best of all, if you let air handle reloads, and you update the application, air will hot-reload the application, and the PostgreSQL container will be reused, so we do not need to wait for it to be started! Sweet!<\/p>\n\n

Check out the full example in the GitHub repository<\/a>.<\/p>\n\n

Integration Tests<\/strong><\/p>\n\n

The application includes integration tests for the data access layer, in the app\/dal folder. They use Testcontainers<\/a> to create the database and test it in isolation! Run the tests with:<\/p>\n\n

\ngo test -v .\/app\/dal\n<\/div>\n

In less than 10 seconds, we have a clean database and our persistence layer is verified to behave as expected!<\/p>\n\n

Thanks to Testcontainers, tests can run alongside the application, each using its own isolated container with random ports.<\/p>\n\n

Conclusion<\/strong><\/h2>\n\n

Fiber v3\u2019s Services abstraction combined with Testcontainers unlocks a simple, production-like local dev experience. No more hand-crafted scripts, no more out-of-sync environments \u2014 just Go code that runs clean everywhere, providing a \u201cClone & Run\u201d experience. Besides that, using Testcontainers offers a unified developer experience for both integration testing and local development, a great way to test your application cleanly and deterministically\u2014with real dependencies.<\/p>\n\n

Because we\u2019ve separated configuration for production and local development, the same codebase can cleanly support both environments\u2014without polluting production with development-only tools or dependencies.<\/p>\n\n

What\u2019s next?<\/strong><\/h2>\n\n

Check the different testcontainers modules in the Testcontainers Modules Catalog<\/a>.<\/p>\n

Check the Testcontainers Go<\/a> repository for more information about the Testcontainers Go library.<\/p>\n

Try Testcontainers Cloud<\/a> to run the Service containers in a reliable manner, locally and in your CI.<\/p>\n

Have feedback or want to share how you\u2019re using Fiber v3? Drop a comment or open an issue in the GitHub repo<\/a>!<\/p>","protected":false},"excerpt":{"rendered":"

Intro Local development can be challenging when apps rely on external services like databases or queues, leading to brittle scripts […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[4],"tags":[],"class_list":["post-2259","post","type-post","status-publish","format-standard","hentry","category-docker"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/2259","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=2259"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/2259\/revisions"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=2259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=2259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=2259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}