Dynamic Configuration for lura project

[AnujaKalahara99]

Is your feature request related to a problem? Please describe.
Hi Lura Team—really enjoying the project, However, the static configuration is a limitation for my architecture. I need the ability to dynamically manage and update Lura's configuration at runtime using an external control plane.

Describe the solution you'd like
Is there a recommended way to implement dynamic configuration? I know Lura’s incredible speed relies heavily on static configs, so I’d like guidance on how to build a dynamic control plane integration without compromising that core performance.

Describe alternatives you've considered
I've considered workarounds like:

-Watching a directory to trigger hot reloads.

(Note: The main issue is managing the existing connections, like when using custom websocket plugin).

Additional context
Any architectural pointers, or feedback on whether a dynamic config approach aligns with Lura's roadmap, would be hugely appreciated. Thanks for the great work!

[foxcool]

Hi, wanted to share a production implementation of dynamic configuration I built a few years ago on top
of KrakenD, and what I'd do differently today.

What I built (~2020)

A REST API (backed by MongoDB) stored "policies" — each mapping to a KrakenD endpoint+backend pair with
auth rules, headers, caching, etc. On startup the gateway built config.ServiceConfig programmatically
from those policies. When any policy changed, the router goroutine was cancelled and restarted:

func New(params KrakendParams, repo PolicyRepository) {
for {
revision, _ := repo.GetLastPolicyTime()
ctx, cancel := context.WithCancel(context.Background())
go Run(ctx, buildServiceConfig(params, repo))

      for revision == newRevision {
          time.Sleep(time.Second)
          newRevision, _ = repo.GetLastPolicyTime()
      }
      cancel()
  }

}

Run() calls routerFactory.NewWithContext(ctx).Run(cfg) — blocks until context is cancelled. Process never
restarts, only the proxy pipeline gets rebuilt. Worked in production, but had obvious flaws: 1s polling,
no graceful drain of in-flight requests.

What I'd build today

• gRPC control plane for config mutations and streaming watch
• PostgreSQL with LISTEN/NOTIFY instead of polling — config change triggers a DB notification instantly;
  JSONB for flexible schema, ACID for atomic multi-endpoint updates
• Graceful reload — drain in-flight requests via http.Server.Shutdown before cancelling the old context
• Validate before switching — run serviceConfig.Init() on the new config before cancelling the old router

What would help from lura's side

The core pattern already works perfectly. But two primitives would make this first-class rather than
something each team reimplements:

1. A ConfigProvider interface — e.g. Watch(ctx) (<-chan ServiceConfig, error) — so backends (file, DB,
   etcd) are pluggable
2. A GracefulReloader helper wrapping the cancel-and-restart dance with proper drain semantics

Happy to discuss further or sketch out what those interfaces might look like.