ChilliCream graphql-platform: Hot Chocolate, Strawberry Shake and Nitro in one .NET repository

Three products, one repository, one licence file

The repository is not a single library. It is the home of three separate products. Hot Chocolate is the GraphQL server and gateway for .NET. Strawberry Shake is the GraphQL client for .NET, aimed at Blazor and MAUI UIs. Nitro is a GraphQL IDE built on Monaco, shipped as a desktop app, a web app, a .NET middleware and a NodeJS middleware. Green Donut sits underneath as the DataLoader that handles batching and caching.

The practical consequence is that a single clone or a single GitHub watch gives you a server, a client and a developer tool. That is convenient if you are standardising a .NET team on one GraphQL vendor. It is less convenient if you only want one of the three, because issues, releases and documentation all live in the same project. The README points each product at its own documentation path under chillicream.com, so the separation exists at the docs level even though the code is shared.

The licence split is worth reading carefully. The README states that the source code is MIT licensed, and then adds that the MIT License covers the source code only: it does not cover the ChilliCream name and trademarks, the logos and package icons, or the website content and design. TRADEMARKS.md holds the details. That is a normal arrangement for a company-backed open source project, but it means "MIT" here describes the code you compile, not the brand you might want to put on a fork.

What Hot Chocolate solves that a REST controller does not

The README frames the goal as strongly typed schemas that match your APIs, efficient data fetching that reduces cost, and consumer-friendly, declarative, self-documented APIs. Read that as three concrete promises. The schema is derived from your .NET types rather than hand-written. Queries fetch only the fields the client asked for. The schema itself is the documentation, introspectable by any GraphQL tool.

The audience is .NET developers and companies with existing APIs who want a GraphQL layer over them, and teams building a GraphQL gateway in front of several services. The topics list on the repository includes graphql-gateway and graphql-fusion, which tells you federation-style composition is part of the intended scope, not an afterthought.

Where this stops being the right tool: if your team has no .NET footprint, Hot Chocolate is not a neutral choice. You would be adopting the .NET runtime and the ASP.NET Core hosting model along with GraphQL. A Node GraphQL server would be a smaller conceptual step for a JavaScript team, even if the schema-first workflow looks similar on both sides.

Getting Hot Chocolate from NuGet and where the README sends you

The README does not print a quickstart. It links Hot Chocolate to its NuGet package, HotChocolate, and to the documentation at chillicream.com/docs/hotchocolate. The package name is the only install detail the README itself gives, so the honest starting point is the NuGet page and the documentation site rather than a command copied out of the repository root.

What the README does confirm is the middleware surface. It names HotChocolate.AspNetCore as the .NET middleware for Nitro, and @chillicream/nitro-express-middleware as the NodeJS one. Those two package names are the concrete artifacts you can look up today. The README does not document which .NET runtime versions the packages target, whether a template exists, or what the default endpoint path is. The repository does carry a templates/ directory at the top level, so project templates appear to exist, but the README does not describe them and I will not guess at their contents.

If you want a browser UI before writing any server code, Nitro is available as a web app at nitro.chillicream.com and as a desktop app from get-nitro.chillicream.com. Neither requires you to install a .NET package first.

Green Donut and the N+1 problem

The README describes Green Donut as a lightweight DataLoader that simplifies batching, caching, and solves the N+1 problem. That is the mechanism that makes a GraphQL server usable against a relational database. Without batching, a query for a list of orders with their customers issues one customer lookup per order. With a DataLoader, the resolver requests individual keys and the loader coalesces them into one call.

Two things follow from that design. First, resolver code has to be written to go through the loader rather than calling the database directly; the batching only happens for keys that pass through it. Second, caching is part of the same component, so the cache lifetime and scope become a correctness question, not just a performance one. A request-scoped cache and a longer-lived cache give different answers when the underlying data changes.

The README does not document the cache scoping rules or the batch scheduling behaviour, and it does not state which of these are configurable. The documentation link the README gives for Green Donut is chillicream.com/docs/hotchocolate/fetching-data/dataloader. If your resolvers depend on per-request consistency, that page is the one to read before you write the resolvers, not after.

Strawberry Shake generates types, and that constrains your build

Strawberry Shake is positioned against most .NET GraphQL clients by generating .NET types from your GraphQL schema out of the box, and it ships a reactive store in the style of Relay and Apollo Client, which the README cites by name. The reactive store is what lets you build client-side caching and data-fetching strategies into a .NET UI without hand-rolling a cache.

The trade-off is a code generation step in the build. Your client types are a build artifact derived from a schema, so the schema has to be reachable and current when you build. That is a different failure mode from a hand-written client: a stale schema produces stale types, and the compiler will happily accept them. Teams that already run code generation for protobuf or OpenAPI will recognise the workflow. Teams that do not may find that the generated types add a step to CI that the README does not spell out.

The README does not document the generated API surface, the store's cache invalidation rules, or how schema changes are detected. Those are documentation questions for chillicream.com/docs/strawberryshake, not answers available in the repository README.

Nitro as an IDE, and where it does not fit

Nitro is a Monaco-based GraphQL IDE, which the README calls an API cockpit for exploring, sharing and testing any GraphQL API. The distribution options matter more than the feature list. It can be installed as a desktop app from get-nitro.chillicream.com, used as a web app at nitro.chillicream.com, installed through the browser as a web app, or embedded as middleware on your own GraphQL endpoint. The middleware packages named in the README are HotChocolate.AspNetCore for .NET and @chillicream/nitro-express-middleware for NodeJS.

The middleware route is the interesting one for teams that do not want developers pointing a third-party hosted tool at an internal API. Serving Nitro from your own endpoint keeps the schema and the traffic inside your infrastructure. The README says more middlewares will follow, which is a statement about current coverage, not a roadmap with dates.

For a non-.NET team, Nitro is the one piece of this repository that is genuinely stack-neutral, since the web app and the Express middleware work without .NET. But if the GraphQL IDE is the only thing you need, pulling in the wider platform is unnecessary. GraphQL Playground and GraphQL Voyager are the alternatives people search for, and both are standalone tools rather than parts of a server-plus-client platform.

Maintenance, release cadence and upgrade cost

The repository is not archived, and the last push was on 2026-09-22, so the source tree is current. The releases visible here are prerelease builds: 16.7.0-p.9 on 2026-09-21, 16.7.0-p.8 on 2026-09-18 and 16.0.0-p.8 on 2026-09-18. The -p suffix marks them as previews. Anyone consuming the NuGet packages should check which stable version is available rather than assuming the release list here represents what you will resolve.

Two version lines appear in that list at once, 16.7.0 and 16.0.0, which suggests parallel preview trains. That is common for a project of this size but it does mean "upgrade to the latest" is not a single instruction. The repository uses a global.json at the top level, so the SDK version expected by the build is pinned in the repository rather than left to the machine.

Upgrade cost is dominated by the schema and the generated client types rather than by the server package itself. If you use Strawberry Shake, a schema change regenerates client code, and that regeneration is where breaking changes surface. The README does not document a migration guide or a compatibility policy between major versions, so plan to read the release notes for each jump. On licensing, the MIT terms apply to the source code; the trademark carve-out in the README and TRADEMARKS.md is the part to check if you intend to redistribute under the ChilliCream name.

Who this repository is actually for

The repository is a good fit for a .NET team that has decided on GraphQL and wants the server, the client and the developer tool from one place, with a permissive licence on the code. The combination of Hot Chocolate, Strawberry Shake and Green Donut means the schema, the resolver batching and the client types are designed to work together, and the shared repository makes that visible.

It is a poor fit for three situations. A team that only needs a GraphQL IDE should use Nitro directly and ignore the rest. A team on Node, Python or Go should look at that ecosystem's GraphQL server rather than adopting .NET for the sake of the schema tooling. And a team that needs a long-lived stable release line should check the current stable NuGet version before designing around the preview trains that dominate the release list here.

The repository also carries an AGENTS.md and an .mcp.json at the top level alongside the usual CONTRIBUTING.md and SECURITY.md. Those files are aimed at contributors and tooling, not at consumers, but they are a signal about how the project expects work to be done in the tree.

Editorial conclusion

Adopt it if you are building a GraphQL API or a GraphQL-consuming UI on .NET and want the schema, the client types and the DataLoader batching to come from one vendor, MIT licensed at the source level. Do not adopt it if your stack is Node or Python and you were only looking for a GraphQL IDE, or if you need a stable release train, since the releases visible here are prerelease builds such as 16.7.0-p.9. Verify three things first: which HotChocolate package version you actually resolve from NuGet, whether your use of the ChilliCream name or logos needs a separate permission under TRADEMARKS.md, and whether the DataLoader in Green Donut matches your batching and caching requirements before you design resolvers around it.

Frequently asked questions

Official sources

1. ChilliCream/graphql-platform on GitHub
2. License: MIT
3. Project website
4. README
5. Releases