Build a GoFr REST API by creating a Go module, registering handlers on a gofr.New() application, and starting it with app.Run(). GoFr supplies routing and operational features such as structured logs, traces, metrics, datasource clients, and graceful shutdown; whether an API is fast for your workload still depends on what it does and how you measure it.
What you need to start
GoFr’s official quick start documents a minimal Go service and says its current setup uses Go 1.25 or above. The project README surfaced a different minimum, Go 1.26 or above, so check the requirements for the GoFr release you intend to use rather than assuming those pages agree. See the GoFr Quick Start and project README.
As an Amazon Associate I earn from qualifying purchases.
Create a module and add GoFr:
go mod init github.com/example
go get gofr.devUse your own module path in place of github.com/example.
Build and run a minimal REST service
Save this as main.go:
package main
import "gofr.dev/pkg/gofr"
func main() {
app := gofr.New()
app.GET("/greet", func(ctx *gofr.Context) (any, error) {
return "Hello World!", nil
})
app.Run()
}Then resolve dependencies and start the program:
go mod tidy
go run main.goThe official example serves on port 8000 by default. A request to http://localhost:8000/greet returns a JSON-wrapped response, documented as {"data":"Hello World!"}. The handler’s documented form is func(ctx *gofr.Context) (any, error). gofr.New() initializes framework components according to configuration, and app.Run() starts the HTTP server and middleware. See the quick start.
Extend the service with CRUD routes
GoFr documents handlers for GET, POST, PUT, PATCH, DELETE, and QUERY. A conventional REST design uses GET to read, POST to create, PUT or PATCH to update, and DELETE to remove a resource. Here is the route shape for a resource named widgets:
app.GET("/widgets", listWidgets)
app.GET("/widgets/{id}", getWidget)
app.POST("/widgets", createWidget)
app.PUT("/widgets/{id}", replaceWidget)
app.PATCH("/widgets/{id}", updateWidget)
app.DELETE("/widgets/{id}", deleteWidget)Each registered handler should use GoFr’s documented handler signature. The snippet shows route registration only: it does not implement persistence, request validation, authorization, or application-specific error handling. Define those behaviors for your API rather than treating a route declaration as a complete CRUD implementation.
For a working data-backed pattern, GoFr’s examples catalogue includes a basic CRUD REST API with Redis caching, a Redis-backed REST API, generated CRUD handlers, and database migrations. Redis and a database are optional integrations, not prerequisites for the greeting service. Browse the GoFr examples for those implementations.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What GoFr adds around the routes
GoFr describes itself as an “opinionated Go framework for production microservices.” Its quick start presents routing, structured logging, OpenTelemetry traces, Prometheus metrics, datasource clients, and graceful shutdown as built-in framework capabilities. The project README also lists middleware, auth support, gRPC, Pub/Sub, circuit breakers, datasource health checks, migrations, cron jobs, Swagger rendering, abstracted file systems, and WebSockets. Feature availability and configuration should be checked against the documentation for the version you adopt.
These conveniences reduce the amount of infrastructure code an application may need to assemble, but they are not a performance guarantee. The framework’s abstractions and enabled middleware are part of the service being measured, and a database or network dependency can dominate response time.
What the published GoFr performance figures show
GoFr’s v1.56.7 release notes report improved results over v1.56.6 in the project’s own benchmark setup: an Apple M4 with GOMAXPROCS=4, covering plaintext (13 B), a small JSON object, and one path parameter. The project explicitly says results are machine-specific and should be treated as relative, not absolute. These are project-reported figures, not independent measurements or a benchmark of the sample API.
Rank #4
| Benchmark case | GoFr v1.56.6 | GoFr v1.56.7 | Reported change |
|---|---|---|---|
| Plaintext throughput | 89,835 requests/second | 133,304 requests/second | +48% |
| Small JSON throughput | 89,177 requests/second | 118,513 requests/second | +33% |
| One path parameter throughput | 87,224 requests/second | 121,159 requests/second | +39% |
| Profiled allocations per request | 132 KB | 60 KB | −54% |
| Profiled CPU per request | 33.5 microseconds | 21 microseconds | −37% |
| Plaintext p99 latency | 3.7 ms | 1.7 ms | −54% |
The release notes say the v1.56.7 request lifecycle reduced allocations and CPU in pkg/gofr. Their benchmark does not establish how a database-backed CRUD API will perform, and it is not a controlled comparison against another Go framework. Do not apply the reported rates to different hardware, operating systems, container CPU limits, core counts, payloads, or middleware without testing those conditions.
Source: GoFr v1.56.7 release notes.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to measure your API’s speed credibly
Benchmark the service you plan to deploy, not just a trivial handler. Record enough context for another engineer to understand what the result means:
Best Value
- Software and machine: GoFr version, Go version, processor and operating system, plus whether the service runs in a container.
- CPU allocation:
GOMAXPROCSand any container CPU limits. - Workload: request path, payload size and shape, concurrency, and test duration.
- Service configuration: middleware enabled, logging and instrumentation settings, and whether handlers access a database, cache, or another network service.
- Measurement method: tool and configuration, requests per second, and latency percentiles such as p50, p95, and p99. Keep the same setup when comparing builds.
Separate a lightweight handler benchmark from an end-to-end API test if you need to identify bottlenecks. A handler-only result can help isolate framework overhead; a test that includes storage and middleware better represents the deployed endpoint. State which one you ran and avoid presenting either as universal performance.
When GoFr is a sensible fit
GoFr is worth considering when you want an opinionated service framework with operational features and datasource integrations available alongside routing. If you prefer minimal dependencies or want to choose each component yourself, compare those trade-offs against a lighter router or Go’s standard library. Make any performance comparison under the same workload, hardware, Go version, middleware, and data-store conditions; the release figures above compare GoFr versions only.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
