What this prompt does
This prompt gives you a defensible decision between gRPC and REST for a [project_type] project, then helps you implement the chosen path. Rather than offering a hunch, it scores both paradigms across [criteria_count] weighted criteria, designs equivalent gRPC and REST APIs for your [domain_entity] domain, benchmarks them, and proposes a hybrid architecture and migration plan. The structure forces an evidence-based answer instead of a preference, which is exactly what you need when defending the choice to a team.
The variables localize the analysis to your situation. [primary_language] shapes the tooling-maturity scoring, [domain_entity] and [streaming_use_case] ground both the protobuf and REST designs in your real model, and [benchmark_requests] plus [benchmark_environment] define a like-for-like performance test. [gateway_tool] sets the translation layer for the hybrid design, and [migration_scope] bounds the phased rollout if gRPC wins. Because the scorecard is weighted, the priorities you supply matter as much as the criteria themselves.
When to use it
- Your team is split between gRPC and REST and wants a decision backed by scoring and numbers.
- You are designing a new service and need to justify the transport choice to stakeholders.
- You want to see protobuf and OpenAPI designs for the same
[domain_entity]side by side. - You need a benchmark comparing serialization, payload size, and latency percentiles.
- You are considering a hybrid setup with gRPC internally and REST at the edge.
- You expect to migrate gradually and want a phased plan with a training estimate.
Example output
Expect a weighted scorecard table comparing gRPC and REST across your criteria, a .proto file and an OpenAPI spec for the same domain, and a benchmark comparison table with p50/p95/p99 latency and payload sizes. The later steps add a hybrid architecture description with an API gateway translation layer (mapping gRPC status codes to HTTP codes) and a phased migration plan with a rough timeline and training estimate. It is a structured report combining tables, schema files, and prose, not a single code artifact.
Pro tips
- Provide your own weights for the
[criteria_count]criteria; the scorecard is only as useful as the priorities you feed it. - Set
[primary_language]accurately, since tooling maturity and team familiarity scores hinge on it. - Choose a
[domain_entity]and[streaming_use_case]that reflect your hardest real case, not a toy example, so the streaming designs are meaningful. - Keep
[benchmark_requests]and[benchmark_environment]realistic; benchmarks on a 2-core laptop won't mirror production, and the model can only estimate. - Treat the payload-size and latency figures as informed estimates unless you actually run the generated benchmark code.
- If the answer leans hybrid, scope
[migration_scope]tightly so the migration plan stays actionable rather than a vague multi-quarter wish.
