Everyone "knows" binary protocol is faster than HTTP.
I used to believe that too. Until I stopped looking at HTTP as a wire protocol and started l...
For further actions, you may consider blocking this person and/or reporting abuse
Intriguing reframe — HTTP as a "universal data layout" lines up with how HTTP/2 and HTTP/3 actually behave on the wire with stream multiplexing and HPACK/QPACK header compression. One important edge case to flag before readers rip out their gRPC: the latency win disappears on high-RTT mobile links where TLS handshake setup dominates over payload size, and binary protocols with connection reuse still win there. Would love to see a benchmark across LTE / 5G / wired to show where the crossover is.
Great points — TLS handshake dominance on high-RTT links is a real constraint, and connection reuse absolutely matters there. That's a fair benchmark challenge. Honestly these posts are just me sharing ideas during short breaks, so a full LTE/5G/wired benchmark isn't on my plate right now — but it's a good one to revisit. If anyone wants to run it first, I'd genuinely love to see the numbers. 😄
The reflection-at-startup-then-cache-as-delegate pattern is smart. You get the flexibility of dynamic discovery without the runtime overhead. I've seen frameworks that pay that cost on every call — brutal for hot paths.
The "shared channel is the single source of truth after publish" model reminds me of event sourcing but without the persistence baggage. Clean.
Curious about one thing though: when the core re-invokes a producer to recover (consumer asks for re-delivery), how do you handle idempotency? If the producer already partially processed before the failure, you'd want to avoid duplicate side effects. Or is the assumption that producers are purely functional?
Will definitely check out the gitbook. Thanks for sharing the docs.
That's a great question, and it's intentionally outside the framework's responsibility.
LuciferCore provides the infrastructure—networking, pipelines, routing, middleware, module composition, and utilities such as the scheduler for ordered and priority-based execution. It gives you the building blocks, not the business policy.
Whether a producer should be retried, how many times, with what backoff strategy, or whether an operation must be idempotent depends entirely on the application's business requirements. Those decisions are highly domain-specific, so I don't hard-code them into the framework.
My goal is to provide a fast, decoupled foundation so developers can focus on implementing their own business logic and recovery strategies where they belong.
FlatBuffers and Cap'n Proto are excellent — and yes, they achieve zero-copy too. The key difference is schema flexibility. Those formats require a compiled schema and a version contract. HttpModel requires neither. You add a header in one line, no codegen, no recompile, no client update. The zero-alloc guarantees are comparable; the extensibility is not.
Raw Span gives you the memory access but not the structure. You still need to decide how to scan, where delimiters are, which offsets map to which fields, and how to handle nesting. HttpModel is that structure — a reusable, zero-alloc layout engine built on top of spans. It's the difference between having a fast car and having a road to drive it on.
Worth clarifying: HttpModel here is not tied to HTTP/1.1 the transport protocol. It's the layout pattern — start-line, headers, body, delimited by \r\n. HTTP/2 and HTTP/3 changed the framing layer, but the layout thinking described here operates one level below that. You can apply this same DOD approach regardless of which version sits underneath.
imma keep thinking of HTTP as Request/Response, LOL🗿
That's completely fine — Request/Response is a great application of the layout. I just don't want the application to limit how you think about the foundation. Enjoy your requests and responses 😄
You're on top of the world, man. Thank you for this wonderful shift in perspective!
I’m really glad it gave you a new perspective. Appreciate your kind words — means a lot!