# \[ANN\] gRPCServer.jl - A Native gRPC Server Implementation for Julia

**URL:** <https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053>\
**Category:** Package Announcements\
**Created:** [January 14, 2026, 10:12am UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053 "2026-01-14T10:12:08Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![scelles](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scelles/32/220408_2.png) [@scelles](https://discourse.julialang.org/u/scelles)\
**Post date:** [January 14, 2026, 10:12am UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/1 "2026-01-14T10:12:08Z")

</div>

Hi everyone! 👋

I’m excited to share a new **native Julia [gRPC](https://grpc.io/) server library** I’m working on: **gRPCServer.jl**.

🔗 _Repository:_ [https://github.com/s-celles/gRPCServer.jl](https://github.com/s-celles/gRPCServer.jl)  
_(Currently unregistered — and still in development — feedback welcome!)_

### 🧠 What is gRPCServer.jl?

`gRPCServer.jl` is a server‑side gRPC framework written in pure Julia. It makes it easy to **serve gRPC APIs from Julia applications** using Protocol Buffers for message serialization (via `ProtoBuf.jl`). This fills an important gap — while client‑side gRPC support exists in packages like [gRPCClient.jl](https://github.com/JuliaIO/gRPCClient.jl), the server story has been relatively underdeveloped. ([Julia Packages](https://juliapackages.com/p/grpcclient "GRPCClient · Julia Packages"))

Key features include:

- ✔ **All RPC Patterns** — Unary, server streaming, client streaming, bidirectional streaming
- ✔ **Type‑safe dispatch** leveraging Julia’s type system
- ✔ **High performance** – type‑stable handlers with minimal allocations
- ✔ **TLS/mTLS support** for secure communication (to be implemented)
- ✔ **Reflection & health checks**
- ✔ **Interceptors** for logging, auth, metrics, etc.
- ✔ **Julia‑idiomatic interfaces** and extensive docstrings

### 🔧 Quick Example

Here’s how to define and run a simple gRPC server:

```julia
using ProtoBuf, gRPCServer

include("generated/helloworld.jl")
using .helloworld

function say_hello(ctx::ServerContext, req::HelloRequest)::HelloReply
    HelloReply(message="Hello, $(req.name)!")
end

struct GreeterService end

function gRPCServer.service_descriptor(::GreeterService)
    ServiceDescriptor(
        "helloworld.Greeter",
        Dict(
            "SayHello" => MethodDescriptor("SayHello", MethodType.UNARY,
                                           "helloworld.HelloRequest",
                                           "helloworld.HelloReply",
                                           say_hello)
        ),
        nothing
    )
end

server = GRPCServer("127.0.0.1", 50051)
register!(server, GreeterService())
run(server)

```

You can then test it locally:

```bash
grpcurl -plaintext -d '{"name":"Julia"}' localhost:50051 helloworld.Greeter/SayHello

```

### 📦 Why This Package?

Many Julia tools and ecosystems lack a complete gRPC server solution. While there are client libraries (e.g., `gRPCClient.jl` for making requests), the server side has been largely missing or experimental until now. This package aims to provide:

- A gRPC server for Julia
- Secure and extensible infrastructure for RPC
- A foundation for building distributed and service‑oriented Julia applications

### 💡 Requirements

- Julia **1.10+**
- `ProtoBuf.jl` for protocol buffers support ([Julia Packages](https://juliapackages.com/p/protobuf "ProtoBuf · Julia Packages"))

### 📣 Feedback, Collaboration & Registration

This package is currently **unregistered** , and I’d love to get early user feedback, feature requests, and collaborators! If you find this useful or want to help polish it for registration on the General registry — please comment below.

🔗 Repository: [https://github.com/s-celles/gRPCServer.jl](https://github.com/s-celles/gRPCServer.jl)

Thanks, and happy coding! 🙌

* * *

---

<div class="post-metadata">

**Author:** ![tp2750](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tp2750/32/207806_2.png) [@tp2750](https://discourse.julialang.org/u/tp2750)\
**Post date:** [January 14, 2026, 6:18pm UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/2 "2026-01-14T18:18:01Z")

</div>

This is awesome. Thank you for sharing!

---

<div class="post-metadata">

**Author:** ![csvance](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/csvance/32/218927_2.png) [@csvance](https://discourse.julialang.org/u/csvance)\
**Post date:** [January 14, 2026, 8:22pm UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/3 "2026-01-14T20:22:50Z")

</div>

It looks like gRPC support in the Julia ecosystem is shaping up big time in 2026! I had originally planned to write this sometime this year, but I’m honestly relieved someone else is driving the effort. Thank you!

I’m going to open an issue at ProtoBuf.jl to bump the version tonight. Once that is done we can also get gRPCClient.jl 1.0.0 released so you can depend on it for testing for your own package registration.

EDIT: made an issue and associated pull request here: [Release 1.2.1 · Issue #290 · JuliaIO/ProtoBuf.jl · GitHub](https://github.com/JuliaIO/ProtoBuf.jl/issues/290)

---

<div class="post-metadata">

**Author:** ![scelles](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scelles/32/220408_2.png) [@scelles](https://discourse.julialang.org/u/scelles)\
**Post date:** [January 14, 2026, 9:36pm UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/4 "2026-01-14T21:36:14Z")

</div>

Feel free to look at code, [ROADMAP.md](https://github.com/s-celles/gRPCServer.jl/blob/develop/ROADMAP.md) and [DeepWiki](https://deepwiki.com/s-celles/gRPCServer.jl) to see if something is missing. Very pleased to have some testers and contributors.  
Thanks for PR in ProtoBuf.jl  
I will try to also look at gRPCClient.jl code and see if there is some room for improvements.

---

<div class="post-metadata">

**Author:** ![rkube](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rkube/32/211198_2.png) [@rkube](https://discourse.julialang.org/u/rkube)\
**Post date:** [January 14, 2026, 9:51pm UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/5 "2026-01-14T21:51:09Z")

</div>

Fantastic! Thanks for developing this package.

---

<div class="post-metadata">

**Author:** ![simsurace](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simsurace/32/30216_2.png) [@simsurace](https://discourse.julialang.org/u/simsurace)\
**Post date:** [January 15, 2026, 4:21pm UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/6 "2026-01-15T16:21:21Z")

</div>

The hello world example in the README does not work for me. I get `Failed to dial target host "localhost:50051": context deadline exceeded` from `grpcurl`. There are no warnings/errors on the Julia side.

gRPC server support would of course be hugely beneficial to have, but it is an enormous undertaking especially without a solid http/2 foundation to build on. Taking even a quick glance at one of the lowest level of the stack (the Huffman code for HPACK header compression), 13 out of the first 15 codes seem to be wrong:

| i | gRPCServer.HUFFMAN\_CODES[i] | RFC 7541 Appendix B |
| --- | --- | --- |
| 2 | 0x03ffffe2 | 0x0fffffe2 |
| 3 | 0x03ffffe3 | 0x0fffffe3 |
| 4 | 0x03ffffe4 | 0x0fffffe4 |
| 5 | 0x03ffffe5 | 0x0fffffe5 |
| 6 | 0x03ffffe6 | 0x0fffffe6 |
| 7 | 0x03ffffe7 | 0x0fffffe7 |
| 8 | 0x03ffffe8 | 0x0fffffe8 |
| 9 | 0x07ffffea | 0x00ffffea |
| 11 | 0x03ffffe9 | 0x0fffffe9 |
| 12 | 0x03ffffea | 0x0fffffea |
| 14 | 0x03ffffeb | 0x0fffffeb |
| 15 | 0x03ffffec | 0x0fffffec |

My understanding of these matters is limited, but it seems unlikely that this library can communicate with clients over http/2 if they use different encodings for header compression.

---

<div class="post-metadata">

**Author:** ![scelles](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scelles/32/220408_2.png) [@scelles](https://discourse.julialang.org/u/scelles)\
**Post date:** [January 16, 2026, 4:29am UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/7 "2026-01-16T04:29:29Z")

</div>

cross checking every table from RFC is a good idea. Thanks for checking this one. It should be fixed now. Sorry about that.

Maybe testing against [GitHub - http2jp/hpack-test-case: HPACK Test Case](https://github.com/http2jp/hpack-test-case)  
could help improving quality of this package.

Their work is mentioned in [https://http2.github.io/](https://http2.github.io/)

Unfortunately http2jp/hpack-test-case still have two 8 yo issues ;-(

---

<div class="post-metadata">

**Author:** ![simsurace](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simsurace/32/30216_2.png) [@simsurace](https://discourse.julialang.org/u/simsurace)\
**Post date:** [January 16, 2026, 10:13am UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/8 "2026-01-16T10:13:24Z")

</div>

Why not develop on top of the HTTP.jl branch that is supposed to be released as v2?

---

<div class="post-metadata">

**Author:** ![csvance](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/csvance/32/218927_2.png) [@csvance](https://discourse.julialang.org/u/csvance)\
**Post date:** [January 16, 2026, 2:31pm UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/9 "2026-01-16T14:31:56Z")

</div>

> [@simsurace](#):
>
> Why not develop on top of the [HTTP.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/HTTP) branch that is supposed to be released as v2?

There is also the option of using nghttp2. Late last year I had started work on on a package that builds ontop of the JLL package to make it easier to use from Julia as part of my server efforts.

---

<div class="post-metadata">

**Author:** ![scelles](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scelles/32/220408_2.png) [@scelles](https://discourse.julialang.org/u/scelles)\
**Post date:** [January 19, 2026, 9:34am UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/10 "2026-01-19T09:34:14Z")

</div>

Thanks for the suggestions @simsurace and @csvance!

I’m taking a **top-down, Spec-Driven Development approach** (SDD) here, with AI assistance to help accelerate the implementation. The idea is to start from the gRPC specification and work downward, getting a functional server working first before diving deep into lower-level optimizations.

Focusing too much on the HTTP/2 foundation details right now would be **premature optimization** — I’d rather have a working gRPC server that can evolve, than spend months perfecting HTTP/2 internals before having anything usable.

That said, the HTTP/2 layer I’m building is designed with extraction in mind. In a future iteration, it should be entirely possible to **spin out a standalone HTTP2.jl package** from this work, which could benefit the broader Julia ecosystem (and potentially even feed back into HTTP.jl efforts).

Regarding quality assurance: **HPACK is now being tested against [http2jp/hpack-test-case](https://github.com/http2jp/hpack-test-case)**, which provides a comprehensive test suite used by many HTTP/2 implementations. This should help catch encoding issues like the ones @simsurace spotted earlier (thanks again for that!).

I’m very open to collaborating on the HTTP/2 layer once the gRPC functionality is more mature — contributions and feedback are always welcome!

@csvance I’m eagerly waiting for the new gRPCClient.jl release — it will be very useful for testing gRPCServer.jl.

---

<div class="post-metadata">

**Author:** ![simsurace](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simsurace/32/30216_2.png) [@simsurace](https://discourse.julialang.org/u/simsurace)\
**Post date:** [January 19, 2026, 10:31am UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/11 "2026-01-19T10:31:20Z")

</div>

I’d be happy to try it out again once the hello world example works end-to-end.

---

<div class="post-metadata">

**Author:** ![csvance](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/csvance/32/218927_2.png) [@csvance](https://discourse.julialang.org/u/csvance)\
**Post date:** [August 29, 2026, 7:46pm UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/12 "2026-08-29T19:46:35Z")

</div>

@scelles and I decided to work together on this, taking the best parts of our respective packages and combining them together. The result is the v0.1.0 release of gRPCServer.jl on the general registry 🥳

- Github: [GitHub - JuliaIO/gRPCServer.jl: Julia gRPC Server · GitHub](https://github.com/JuliaIO/gRPCServer.jl)
- Docs: [Home · gRPCServer.jl](https://juliaio.github.io/gRPCServer.jl/dev/)

Here are a few highlights of the release:

- All four RPC patterns: unary + request, response, and bidi streaming
- Production ready HTTP.jl 2.X backend; much work has been done to avoid unneeded payload copying, future releases should be able to get us to zero beyond what HTTP.jl requires internally.
- Tested with the gRPCClient.jl benchmark / stress test suite and the code has undergone several rounds of security audits using models like GLM 5.3.
- IDE friendly code generation hooking into ProtoBuf.jl the same way that gRPCClient.jl does.
- Allows for partial decoding required for things like gRPC gateways and reverse proxies via a raw bytes interface.
- Extensible with a swap-able backend interface where each implementation declares its capabilities. The frontend API stays the same regardless of which backend you use, which hopefully will make it easy to experiment with and extend.

To be fully transparent, coding agents were used heavily for most parts of gRPCServer.jl during its development. With that being said, the design is true to our intent and has undergone many rounds of refinement/real world tests over the past several months in order to make it the best we could for this release. We wanted to get something out there instead of having it languish in [sources] forever blocking registration of other packages; that is the purpose of 0.1.0 release. Expect it to be solid, but with some rough edges that will be ironed out moving forward.

---

<div class="post-metadata">

**Author:** ![tp2750](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tp2750/32/207806_2.png) [@tp2750](https://discourse.julialang.org/u/tp2750)\
**Post date:** [August 30, 2026, 4:39am UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/13 "2026-08-30T04:39:59Z")

</div>

This is great.  
Thank you very much for sharing this.

---

<div class="post-metadata">

**Author:** ![laborg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/laborg/32/5474_2.png) [@laborg](https://discourse.julialang.org/u/laborg)\
**Post date:** [August 30, 2026, 5:23am UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/14 "2026-08-30T05:23:02Z")

</div>

Thank you for the package!

Is it trimmable?

---

<div class="post-metadata">

**Author:** ![csvance](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/csvance/32/218927_2.png) [@csvance](https://discourse.julialang.org/u/csvance)\
**Post date:** [August 30, 2026, 7:01pm UTC](https://discourse.julialang.org/t/ann-grpcserver-jl-a-native-grpc-server-implementation-for-julia/135053/15 "2026-08-30T19:01:44Z")

</div>

> [@laborg](#):
>
> Is it trimmable?

Currently that depends on whether Reseau.jl and ProtoBuf.jl are trimmable. Creating a backend that is trim compatible should be possible provided ProtoBuf.jl can be trimmed; we would need some sort of trim compatible TLS/sockets layer together with nghttp2.