Hi Juno, Thanks for the FIP, great initiative.
A question that comes to my mind: Why not expose metrics via vendor neutral OTEL instead of limiting it to Prometheus? -- Best, MKO > On 30.07.2026, at 12:23, Forward Xu <[email protected]> wrote: > > Thanks junbo, > > The proposal looks good to me in general. +1 > > Best, > Foward > > Junbo Wang <[email protected]> 于2026年7月30日周四 11:49写道： > >> Hi all, I'd like to start a discussion on FIP-49: Fluss Gateway REST API. >> >> The proposal is available here: >> https://cwiki.apache.org/confluence/spaces/FLUSS/pages/444334561/FIP-49+Fluss+Gateway+REST+API >> >> This FIP is an extension of FIP-32 (Multiprotocol Query Gateway) [1] and >> does not conflict with it. Following the earlier suggestion to split the >> gateway work into focused FIPs, FIP-49 defines the REST write path and DDL >> / metadata management in detail, while REST read and the SQL path remain in >> the scope of FIP-32. >> >> In short, it proposes a standalone, stateless fluss-gateway process (Rust, >> axum + tokio, built on fluss-rust) providing: >> >> HTTP/JSON ingestion into KV and Log tables, at-least-once, with per-row >> success/failure reporting >> Full database / table / partition DDL >> Pluggable client authentication, and a service / user (act-as) identity >> mode towards Fluss >> Multi-cluster routing, Prometheus metrics, a unified error model >> >> No Fluss server-side changes are required— the gateway accesses existing >> clusters purely as a fluss-rust client. >> >> Looking forward to your feedback and suggestions. >> >> >> >> [1] https://lists.apache.org/thread/sf0qfxhr9j2g0dtxvp586p9zknxvpx6x >> >> >> Best regards, >> Junbo Wang >> >>
