mrkeyoor.com_
Sun 08 Nov 07:26 UTC
Open Source3 min read

Spindle derives API validation and frontend schemas from OCaml types

Spindle documents shared type definitions for API contracts. Its bill example shows the approach; the 0.14.0 changelog identifies a handler timeout to check before adoption.

Spindle, an MIT-licensed web framework for OCaml 5, documents a way to keep API contracts in sync: derive request validation and frontend schemas from OCaml types, and generate OpenAPI documentation from routes. For OCaml developers evaluating the framework, the practical question is which definitions can be shared and which runtime limits still need attention.

The repository documents JSON derived from OCaml types, OpenAPI documentation rendered by Scalar, and Zod or Melange schemas for frontend clients. The Show HN introduction describes keeping server and client contracts in sync without separate definitions. These are documented capabilities, not evidence of when each feature first shipped. The supplied evidence contains no MrKeyoor build or benchmark results.

One declaration carries the bounds

The README's bill example defines a nonnegative total, a tip between 0 and 100, and a party size between 1 and 50. Its route reads JSON through the derived bill description. The project says each endpoint's generated reference lists its schema, the bounds from its types and every error it may return.

This gives an evaluator something concrete to inspect: whether a request constraint also appears in the generated documentation. Sharing that constraint could reduce the separate definitions an application author must update. The supplied example supports that design explanation; it does not establish how the generated interface behaves in a running application. No server execution or rendered Scalar inspection is documented in the supplied evidence.

Check the handler limit before adopting it

Spindle's changelog dates version 0.14.3 to November 2, 2026. The earlier 0.14.0 entry, dated October 27, 2026, records breaking changes to route metadata, limits and CORS configuration.

Version 0.14.0 documents a default 60-second handler timeout. Past that limit, the handler and work it started are cancelled, and the request receives 503 timed_out. The documented override locations are Server.Limits.make and the route's Route.Limits.make. Time spent waiting for the request body does not count toward this limit; a stream or socket runs after the answer.

Teams considering Spindle for typed API contracts should check those limits against their handlers and review the migration entries for the version they intend to pin. Applications with handlers that run longer than a minute need an explicit timeout decision. The shared-contract design alone does not answer that operational question.

The Show HN discussion includes a request for an example deployed in use. That request is not evidence that deployments do not exist. A useful next evaluation would trace a request constraint through validation, generated documentation and a frontend schema, then check upgrade behavior against the changelog. Those checks have not been performed in the supplied record.

Sources

  1. Spindle repository and README
  2. Spindle changelog
  3. Spindle creator presentation and discussion on Show HN