# RemoteBMI fully replacing grpc4bmi in the future

**URL:** <https://forum.csdms.io/t/remotebmi-fully-replacing-grpc4bmi-in-the-future/204>\
**Category:** BMI\
**Created:** [October 15, 2026, 9:45am UTC](https://forum.csdms.io/t/remotebmi-fully-replacing-grpc4bmi-in-the-future/204 "2026-10-15T09:45:13Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![BSchilperoort](https://yyz2.discourse-cdn.com/flex012/user_avatar/forum.csdms.io/bschilperoort/32/14_2.png) [@BSchilperoort](https://forum.csdms.io/u/BSchilperoort)\
**Post date:** [October 15, 2026, 9:45am UTC](https://forum.csdms.io/t/remotebmi-fully-replacing-grpc4bmi-in-the-future/204/1 "2026-10-15T09:45:13Z")

</div>

For context: in the [eWaterCycle projects](https://research-software-directory.org/projects/ewatercycle-ii) “we” developed [grpc4bmi](https://grpc4bmi.readthedocs.io/en/latest/) as a way to enable cross-language and cross-container communication for BMI.

However, more recently @sverhoeven developed the alternative RemoteBMI, based on an [OpenAPI spec](https://redocly.github.io/redoc?url=https://github.com/eWaterCycle/remotebmi/raw/main/openapi.yaml). The immediate reason was to natively support Julia and R. However, there are also other reasons to switch over to RemoteBMI from grpc4bmi in the future.

## grpc4bmi issues

For a long time I had mostly seen gRPC as the “high performance” interface, while RemoteBMI was the “easier but less performant” one.

However, the features that make gRPC useful are not (well) used by grpc4bmi:

- concurrent calls do not work anyway, because the models don’t support it
- with BMI we have many very tiny calls (where there isn’t really much advantage of gRPC)
- with BMI we also have big transfers (where gRPC4BMI doesn’t make use of RPC streams).
- Protobuf seem to perform worse than, e.g., zstd encoded binary streams, when it comes to data compression
- Protobuf needs extra copies on server+client side which impacts performance

Lastly, gRPC is more difficult to implement and not always well supported. A simple HTTP protocol like RemoteBMI fits much better for our use cases.

I tested the performance of the Julia implementation of RemoteBMI vs. grpc4bmi, and it was many times faster.

## RemoteBMI speed up

In one of our projects we are going to be coupling models with large data transfers, likely between Python and Julia. Therefore I can spend some time on improving RemoteBMI.

I am planning to work on a highly performant Rust server+client with PyO3 bindings, while keeping the (slow) OpenAPI Python stack as a fallback and reference implementation.

Preliminary testing has shown round-trip overhead for RemoteBMI calls can be \<30μs (\>5x faster than grpc4bmi), and data transfer can reach speeds of many GB/s on the same machine (or ~0.5 GB/s when transfering compressed data over a slower network link). This should allow us to do serious model coupling without too much of a performance hit.

* * *

Have you tried using either of these in the past? What kind of coupling overhead is acceptable for your application? Let me know here 🙂