Show HN: Schema Gateway v0.1 – type-safe API gateway with metrics
https://github.com/AncientiCe/schema-gateway
Hi HN!A few weeks ago I shared Schema Gateway, a small API gateway I built to enforce type-safe APIs with schema-driven routing and validation. At the time, it was mainly about reducing boilerplate and keeping strong API contracts across microservices.
Since then, I hit a wall in debugging issues in production—even with type safety, requests were failing silently or services were misbehaving. That forced me to build full metrics and observability, so now the gateway exposes:
Request/response counts by endpoint
Validation failures per service
Latency and error tracking for each route
The v0.1 release also formalizes the schema-driven design into a stable package. The goal is still the same: let the schema define the API surface, not handwritten validators, but now you can actually see what’s happening in real time.
Some lessons learned along the way:
Type safety is not enough – without metrics, bugs in downstream services can silently break your API contracts.
Observability + schema-first is surprisingly lightweight – you can automatically generate dashboards without extra code in your services.
Schema-first helps enforce contracts – but real confidence comes from seeing traffic and failures in production.
Repo & docs: https://github.com/AncientiCe/schema-gateway
I’d love feedback on:
API patterns you’ve found useful for schema-driven systems
Approaches to lightweight observability in microservices
Pitfalls I might not have noticed
Thanks for checking it out!
Your approach of schema-first with observability layer makes sense. Schema gives you the contract, metrics give you truth about what's actually happening.
Building something adjacent at toran.sh - API observability focused on agent workloads. Similar motivation: see actual traffic, not just trust the schema.
Question: how are you handling observability for services that call external APIs? The internal → external boundary is where I've found the most surprising failures.
shared HTTP client wrappers emitting OTel metrics
alerting on downstream service error spikes (often external root cause)
occasional shadow schema checks + CI drift detection for critical externals
Can be considered for the future though, glad you mentioned it.