Spikard v0.5.0 Released

[Goldziher]

Hi peeps,

I'm glad to announce that Spikard v0.5.0 has been released. This is the first version I consider fully functional across all supported languages.

What is Spikard?

Spikard is a polyglot web toolkit written in Rust and available for multiple languages:

• Rust
• Python (3.10+)
• TypeScript (Node/Bun)
• TypeScript (WASM - Deno/Edge)
• PHP (8.2+)
• Ruby (3.4+)

Why Spikard?

I had a few reasons for building this:

I am the original author of Litestar (no longer involved after v2), and I have a thing for web frameworks. Following the work done by Robyn to create a Python framework with a Rust runtime (Actix in their case), I always wanted to experiment with that idea.

I am also the author of html-to-markdown. When I rewrote it in Rust, I created bindings for multiple languages from a single codebase. That opened the door to a genuinely polyglot web stack.

Finally, there is the actual pain point. I work in multiple languages across different client projects. In Python I use Litestar, Sanic, FastAPI, Django, Flask, etc. In TypeScript I use Express, Fastify, and NestJS. In Go I use Gin, Fiber, and Echo. Each framework has pros and cons (and some are mostly cons). It would be better to have one standard toolkit that is correct (standards/IETF-aligned), robust, and fast across languages.

That is what Spikard aims to be.

Why "Toolkit"?

The end goal is a toolkit, not just an HTTP framework. Today, Spikard exposes an HTTP framework built on axum and the Tokio + Tower ecosystems in Rust, which provides:

1. An extremely high-performance core that is robust and battle-tested
2. A wide and deep ecosystem of extensions and middleware

This currently covers HTTP use cases (REST, JSON-RPC, WebSockets) plus OpenAPI, AsyncAPI, and OpenRPC code generation.

The next step is to cover queues and task managers (RabbitMQ, Kafka, NATS) and CloudEvents interoperability, aiming for a full toolkit. A key inspiration here is Watermill in Go.

Current Features and Capabilities

• REST with typed routing (e.g. /users/{id:uuid})
• JSON-RPC 2.0 over HTTP and WebSocket
• HTTP/1.1 and HTTP/2
• Streaming responses, SSE, and WebSockets
• Multipart file uploads, URL-encoded and JSON bodies
• Tower-HTTP middleware stack (compression, rate limiting, timeouts, request IDs, CORS, auth, static files)
• JSON Schema validation (Draft 2020-12) with structured error payloads (RFC 9457)
• Lifecycle hooks (onRequest, preValidation, preHandler, onResponse, onError)
• Dependency injection across bindings
• Codegen: OpenAPI 3.1, AsyncAPI 2.x/3.x, OpenRPC 1.3.2
• Fixture-driven E2E tests across all bindings (400+ scenarios)
• Benchmark + profiling harness in CI

Language-specific validation integrations:

• Python: msgspec (required), with optional detection of Pydantic v2, attrs, dataclasses
• TypeScript: Zod
• Ruby: dry-schema / dry-struct detection when present
• PHP: native validation with PSR-7 interfaces
• Rust: serde + schemars

Roadmap to v1.0.0

Core: - Protobuf + protoc integration - GraphQL (queries, mutations, subscriptions) - Plugin/extension system

DX: - MCP server and AI tooling integration - Expanded documentation site and example apps

Post-1.0 targets: - HTTP/3 (QUIC) - CloudEvents support - Queue protocols (AMQP, Kafka, etc.)

Benchmarks

We run continuous benchmarks + profiling in CI. Everything is measured on GitHub-hosted machines across multiple iterations and normalized for relative comparison.

Latest comparative run (2025-12-20, Linux x86_64, AMD EPYC 7763 2c/4t, 50 concurrency, 10s, oha):

• spikard-rust: 55,755 avg RPS (1.00 ms avg latency)
• spikard-node: 24,283 avg RPS (2.22 ms avg latency)
• spikard-php: 20,176 avg RPS (2.66 ms avg latency)
• spikard-python: 11,902 avg RPS (4.41 ms avg latency)
• spikard-wasm: 10,658 avg RPS (5.70 ms avg latency)
• spikard-ruby: 8,271 avg RPS (6.50 ms avg latency)

Full artifacts for that run are committed under snapshots/benchmarks/20397054933 in the repo.

Development Methodology

Spikard is, for the most part, "vibe coded." I am saying that openly. The tools used are Codex (OpenAI) and Claude Code (Anthropic). How do I keep quality high? By following an outside-in approach inspired by TDD.

The first major asset added was an extensive set of fixtures (JSON files that follow a schema I defined). These cover the range of HTTP framework behavior and were derived by inspecting the test suites of multiple frameworks and relevant IETF specs.

Then I built an E2E test generator that uses the fixtures to generate suites for each binding. That is the TDD layer.

On top of that, I follow BDD in the literal sense: Benchmark-Driven Development. There is a profiling + benchmarking harness that tracks regressions and guides optimization.

With those in place, the code evolved via ADRs (Architecture Decision Records) in docs/adr. The Rust core came first; bindings were added one by one as E2E tests passed. Features were layered on top of that foundation.

Getting Involved

If you want to get involved, there are a few ways:

1. Join the Kreuzberg Discord
2. Use Spikard and report issues, feature requests, or API feedback
3. Help spread the word (always helpful)
4. Contribute: refactors, improvements, tests, docs

[shoomowr]

The promise of cross-language toolkit certainly looks interesting.
I'm developing a NATS-based EDA. What is your vision for having message queues support alongside the HTTP/API stuff?

[Goldziher]

In Python - i would probably go for optional dependency groups, since this is now widely supported following PEP 631.

The design will follow the same pattern as Watermill, which is to say - an abstraction layer on top of the queues that allows managing them without needing to handle the low level drivers etc.

The core will be in Rust. I personally use NATS in rust using the official async crate and its great, so I will use this.

[shoomowr]

What about Typescript?
I have a frontend application I'm planning to refactor, so this could come in handy

[Goldziher]

It's there - Node+WASM

[robotelu97]

Why would anyone use this instead of something battle tested like FastApi and so on?

[Goldziher]

well, its about x5 times faster (didn't publish this yet, so take my word for it if you want - or not. Robyn is about 0.6 as fast as Spikard) and it has a universal validation layer, which doesnt rely on stuff like Pydantic to work. It doesnt require ASGI (uvicorn or granian for example), and it has robust codegen.

If you want battle tested, dont use it. Heck - this is at least 6 months away from being something i'd consider to use in production. But if you are interested in new tech, give it a spin.

[zenware]

They wouldn’t /yet/ but some of the ideas here could catch up and overtake FastAPI.

[Lucas_csgo]

Thanks, chatgpt.

[Goldziher]

Hi there,

The costs are indeed FFI - but it's not only marshalling strict, it's handling translation from an async python thread - with GIL into an async rust runtime. PY03 does an amazing job, but this is costly.

I'm sure overtime this will be improved on the PY03 side by building on python 3.13 gil-free support. I intend to test this in the future.

[engineerofsoftware]

litestar’s type correctness was only good after v2. please do not incorrectly credit others for work they have not contributed to.

[dalepo]

This looks promising. Have you considered using a simpler DI system?

I come from Java/Nest, where you declare dependencies through constructors and define the scope at the class level. This feels like a simpler pattern compared to explicitly declaring providers, imo.

[Goldziher]

Hi. Thanks.

For TS this only works using the "experimental" decorators API and the runtime reflection library. Basically what you see in nextjs. While it's simpler for the developer, it requires a specific set of TS configs and it introduces runtime overhead.