grpc-dart is the Dart package that speaks gRPC over HTTP/2

A client package for a protocol with a mobile bias

grpc-dart is the Dart language implementation of gRPC, and the description of gRPC itself in the README sets the frame: a high performance, open source, general RPC framework that puts mobile and HTTP/2 first.

That framing is worth taking seriously, because gRPC is often introduced as the protobuf answer, and the Dart package is more specifically the answer for a client that has to live on a phone. The platform list is short and deliberate: Dart native and Flutter. There is no server framework in this package, no Dart implementation of the gRPC server side, and the package is published on pub.dev under the name grpc, with the API reference hosted alongside the other gRPC language documentation.

The learning path the project offers is three links. A Quick Start guide at grpc.io for getting an app running in minutes, an Examples directory in the repository, and the API reference. The complete documentation for the language is a separate site, grpc.io/docs/languages/dart.

The repository itself has the shape of a well-maintained language binding rather than a monorepo of everything. There is an AUTHORS file, a MAINTAINERS.md, a CHANGELOG.md, a SECURITY.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, and a build.yaml and analysis_options.yaml for the Dart toolchain. The source is in lib, the tests in test, and there is an interop directory, which in a gRPC repository is where the cross-language compatibility tests live.

Quick start: the examples directory is the tutorial

The example directory is the most informative thing in the repository for a newcomer, because it names the use cases rather than the API surface.

There is a helloworld example, which is the canonical first thing to run. There is a route_guide example, which is the well-known gRPC sample service with a server implementation, a client and a shared protobuf definition, and it is the example that shows a real service definition end to end. There is a metadata example, which covers the custom metadata that travels with a call. There is a grpc-web example, which is how the browser path is exercised. And there is a googleapis directory, which is the set of generated clients for Google's own published APIs.

Taken together those five directories describe what a Dart team actually does with gRPC. Define a service in protobuf, generate the Dart stubs, implement or call the service, attach metadata where the protocol allows it, and where a browser is involved, go through the grpc-web path.

The googleapis example is worth a second look for a different reason. It is a worked example of a large, real, publicly described API surface, and it is the case where the generated-code burden of protobuf is most visible. A team choosing gRPC is choosing a code generation step, and the googleapis directory is a reminder of what that looks like at scale.

The route_guide example is also the place to see the split between a server and a client, which is the split this package does not itself cover.

grpc-web is a separate import, not a build flag

One technical note in the README deserves its own attention, because it changes how you architect a browser client.

The note says grpc-web is supported by package:grpc/grpc_web.dart. In other words, the web transport is not the same library as the native one. A Dart application running on a device imports the normal package, and a Dart application compiled to JavaScript imports the grpc_web library instead. The two paths share the API but not the transport, and a browser build imports the web library directly rather than the default one.

The reason for the split is structural rather than stylistic. gRPC over HTTP/2 needs a client that can speak HTTP/2 with trailers, and browsers do not expose enough of the HTTP/2 stack to a page to do that. grpc-web is the protocol variant that works over a connection the browser controls, and it requires the server to support it. A Dart client in a browser therefore depends on the server side being grpc-web capable, which is a property of the service you are calling and not something this package can arrange on its own.

The second note is about transport. The unix domain socket is supported with sdk version >= 2.8.0, which is the floor for that feature. The practical relevance is for a backend service talking to a local sidecar over a socket, where a TCP port would be a larger exposure than necessary.

Together these two notes tell you where the sharp edges are: browsers need cooperation from the server, and local socket transport needs a reasonably modern SDK.

Contributions are limited and every PR needs a signature

The contributing section is short, and it is the one place where the project says plainly what it can and cannot absorb.

If you experience problems or have feature requests, the instruction is to open an issue. Then the note: the project has limited bandwidth to accept PRs, and all PRs require signing the EasyCLA. The contributor licence is a two-part arrangement, where the sign-off declares the right to grant the rights in the contribution, and the licensing itself is what puts the code under the project's terms.

This is a language binding maintained inside the gRPC organisation, and the practical effect is that the roadmap is set by what the gRPC project needs rather than by what outside contributors would like. A team that wants a Dart feature that is not on that list will not get it merged here, however good the pull request is.

For that reason, the most productive contributions to a repository like this are often not features. Documentation, examples, tests, and reporting the cases where the Dart implementation and another language implementation of the same service disagree are all things a user organisation can do without needing the maintainers' bandwidth. The interop directory in the repository, which is where cross-language compatibility is checked, is the natural place for that kind of work to land.

The presence of MAINTAINERS.md and SECURITY.md also tells you the project has a defined process for both maintainership and vulnerability reports, which matters for a package that ends up in production applications on mobile.

A 5.x line with a recent minor release

The release history is the last thing worth reading, because it tells you the cost of staying on this package.

The recent releases are v5.2.0 on 2026-10-15, v5.1.0 on 2025-12-09 and v5.0.0 on 2025-11-17. The version in the manifest is 5.x, and the last push to the repository was on 2026-10-15, the same day as the newest release. The repository is not archived, and the default branch is master.

So the package is on a 5.x line, it took two major versions across the back half of 2025, and it shipped a minor version in the last few days. For a client library, that cadence is normal and unremarkable. For a team with a Flutter application in production, it means an upgrade path through major versions is a normal cost of doing business, and the CHANGELOG.md in the repository is the document to consult before each one.

The licence is Apache-2.0, with a LICENSE file at the repository root, which is the same permissive terms the rest of the gRPC ecosystem uses. For a client library that is about as uncomplicated as it gets, and there is no copyleft reach into the application that consumes it.

One small inconsistency is worth noting for anyone filing an issue. The contributing section links the new issue URL under the dart-lang organisation, while the repository itself lives under the grpc organisation. The links may redirect, and the CHANGELOG and MAINTAINERS files are the reliable indicators of where the project considers itself to live.

Editorial conclusion

grpc-dart suits a Flutter or Dart team that already runs a gRPC service and wants a typed client without leaving the platform, and who need the streaming that the protocol offers on mobile. It is the wrong tool for a service author, since this is a client package, and the wrong tool for a browser client that has to reach a server without grpc-web support on the other end. Before you adopt it, check that the server side already exposes grpc-web if your Dart code runs in a browser, confirm your Dart SDK version is at least 2.8.0 if you rely on the unix domain socket transport, and read the Quick Start and the example directory, since the repository points at both rather than describing the API inline.

Frequently asked questions

Official sources

1. grpc/grpc-dart on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases