DEV Community

Cover image for Say hello to GoREST v0.3
Nicolas Bonnici
Nicolas Bonnici

Posted on

Say hello to GoREST v0.3

What's New Under the Hood?

Plugins

Plugins for all, plugins everywhere, plugins for everything. Whether
custom or core features --- there's a plugin for that. Want to create
your own? Let's go!

Meme about<br>
plugins

With the release of v0.3, every feature of the GoREST core is now optional and fully configurable.

Each plugin has its own configuration in the gorest.yaml plugins
section.

Here's the list of the first available core plugins:

  • Authentication with JWT support
  • Content-type negotiation
  • Logger
  • Rate limiter
  • Request identifier
  • Security
  • CORS management
  • Health check
  • Benchmark

If you need something specific, you can build your own plugin. Here's an
example of a simple customplugin that calculates request duration time
and adds it to the response headers.

package customplugin

import (
    "fmt"
    "time"

    "github.com/gofiber/fiber/v2"
    "github.com/nicolasbonnici/gorest/plugin"
)

// TimingPlugin adds request execution time headers to all responses
type TimingPlugin struct {
    enabled bool
}

// NewTimingPlugin creates a new timing plugin instance
func NewTimingPlugin() plugin.Plugin {
    return &TimingPlugin{enabled: true}
}

func (p *TimingPlugin) Name() string {
    return "timing"
}

func (p *TimingPlugin) Initialize(config map[string]interface{}) error {
    if enabled, ok := config["enabled"].(bool); ok {
        p.enabled = enabled
    }
    return nil
}

func (p *TimingPlugin) Handler() fiber.Handler {
    return func(c *fiber.Ctx) error {
        if !p.enabled {
            return c.Next()
        }

        start := time.Now()

        // Process request
        err := c.Next()

        // Calculate duration
        duration := time.Since(start)

        // Add timing headers
        c.Set("X-Response-Time", fmt.Sprintf("%v", duration))
        c.Set("X-Response-Time-Ms", fmt.Sprintf("%.2f", float64(duration.Microseconds())/1000.0))

        return err
    }
}
Enter fullscreen mode Exit fullscreen mode

Plugins can be applied globally across the API or restricted to specific
endpoints and methods.

Plugins vs Existing Hook System

Plugins are designed for generic API functionalities, while the hook
system
lets you implement business-specific logic. You can share GoREST plugins publicly, but hooks are tied to your business objects and logic.

Flexibility Is Key

Every API has its own needs and specificities. The GoREST core focuses only on essential API behaviors --- resource interactions --- while everything else can be modular.

Performance

Performance matters. Does all this flexibility come with a cost?
Absolutely not --- on the contrary. Modularity increases performance by removing unused plugins that were previously tightly coupled to the core.

Benchmark

GoREST includes a built‑in benchmarking tool. Simply run:

make benchmark
Enter fullscreen mode Exit fullscreen mode

Below is the output, executed locally on my laptop with the following
specs, while running Debian, GNOME Shell, and several applications like a browser, IDE, and Insomnia:

11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
16GB RAM
Enter fullscreen mode Exit fullscreen mode
=========================================
      API Performance Benchmark
=========================================

[INFO] Setting up benchmark table...
[INFO] Generating test data...
[INFO] Generating models and resources...
[INFO] Building API server...
[INFO] Starting API server...
[INFO] Waiting for server to be ready...
[INFO] Server is ready

=========================================
       Running Benchmarks
=========================================

Benchmarking GET /benchmarkitems?limit=10
─────────────────────────────────────────────────────────────────
  Concurrency: 1   | RPS:       1 | p50: 871.26µs | p95: 1.433519ms | p99: 1.433519ms | Errors: 0 | Total: 5
  Concurrency: 10  | RPS:      10 | p50: 821.151µs | p95: 1.289257ms | p99: 1.597766ms | Errors: 0 | Total: 50
  Concurrency: 50  | RPS:      50 | p50: 817.202µs | p95: 1.569706ms | p99: 2.275461ms | Errors: 0 | Total: 250

Benchmarking GET /benchmarkitems?limit=100
─────────────────────────────────────────────────────────────────
  Concurrency: 1   | RPS:       1 | p50: 1.965903ms | p95: 2.383311ms | p99: 2.383311ms | Errors: 0 | Total: 5
  Concurrency: 10  | RPS:      10 | p50: 1.872685ms | p95: 2.449289ms | p99: 2.95571ms | Errors: 0 | Total: 50
  Concurrency: 50  | RPS:      50 | p50: 1.706943ms | p95: 2.682877ms | p99: 5.437662ms | Errors: 0 | Total: 250

Benchmarking GET /benchmarkitems?limit=1000
─────────────────────────────────────────────────────────────────
  Concurrency: 1   | RPS:       1 | p50: 11.371178ms | p95: 14.578225ms | p99: 14.578225ms | Errors: 0 | Total: 5
  Concurrency: 10  | RPS:      10 | p50: 11.772652ms | p95: 13.573469ms | p99: 14.813448ms | Errors: 0 | Total: 50
  Concurrency: 50  | RPS:      50 | p50: 11.403417ms | p95: 13.064978ms | p99: 16.583982ms | Errors: 0 | Total: 250

=========================================
       Benchmark Complete
=========================================

[INFO] Cleaning up...
[INFO] Restoring original schema...
[INFO] Cleanup complete
Enter fullscreen mode Exit fullscreen mode

Performance Summary

Small Page Size (limit=10)

  • Concurrency 1: p50 871µs, p95 1.4ms, p99 1.4ms
  • Concurrency 10: p50 821µs, p95 1.3ms, p99 1.6ms
  • Concurrency 50: p50 817µs, p95 1.6ms, p99 2.3ms

Excellent --- sub‑millisecond median response times even under load.

Medium Page Size (limit=100)

  • Concurrency 1: p50 1.97ms, p95 2.4ms, p99 2.4ms
  • Concurrency 10: p50 1.87ms, p95 2.4ms, p99 3.0ms
  • Concurrency 50: p50 1.71ms, p95 2.7ms, p99 5.4ms

Very good --- under 2ms median for 100 items.

Large Page Size (limit=1000)

  • Concurrency 1: p50 11.4ms, p95 14.6ms, p99 14.6ms
  • Concurrency 10: p50 11.8ms, p95 13.6ms, p99 14.8ms
  • Concurrency 50: p50 11.4ms, p95 13.1ms, p99 16.6ms

Good --- around 11ms for 1000 items is reasonable.

Key Observations

  1. Zero errors across all tests
  2. Excellent scalability
  3. Consistently low latency
  4. Strong connection pooling
  5. Linear performance growth

Security

Thanks to the core security plugin, building a REST API with GoREST
gives you a highly secure framework.

We performed a security audit and penetration test using Claude AI from
Anthropic. It checked for OWASP Top 10 vulnerabilities, test coverage,
attack surface analysis, pentesting, and stress testing.

Standard Requirement GoREST Status


OWASP ASVS L2 Security headers ✅ Complete
OWASP ASVS L2 TRACE disabled ✅ Complete
OWASP ASVS L2 Rate limiting ✅ Complete
OWASP ASVS L2 JWT security ✅ Complete
OWASP ASVS L2 SQL injection prevention ✅ Complete
OWASP ASVS L2 XSS prevention ✅ Complete
OWASP ASVS L2 CSRF protection ✅ N/A (API)
CIS Benchmarks Secure headers ✅ Complete
CIS Benchmarks Method whitelisting ✅ Complete
Mozilla Observatory Security grade ✅ A+

Compliance Level: OWASP ASVS Level 2 (Standard Web Applications)

Results

  • Security Score: 10/10
  • Vulnerabilities: 0
  • Tests Passed: 27/27
  • Production Status: ✅ Approved

GoREST is now production‑ready with industry‑leading security.

What's Coming Next?

Roadmap to the v1 milestone:

  • Plugins repository
  • OAuth2 support
  • gRPC plugin
  • RBAC plugin
  • Development profiler plugin
  • Complete documentation

Contribute

Feel free to create new plugins and contribute to the library. Even a
single ⭐ can motivate continued development toward the v1 milestone.

Top comments (0)