Repository files navigation

webrpc is a schema-driven approach to writing backend servers for the Web. Write your server'sAPI interface in a schema format ofRIDL orJSON,and then runwebrpc-gen to generate the networking source code for your server and client apps. From the schema,webrpc-gen will generate application base class types/interfaces, JSON encoders, and networking code. In doingso, it's able to generate fully functioning and typed client libraries to communicate with your server. Enjoystrongly-typed Web services and never having to write an API client library again.

Under the hood, webrpc is a Web service meta-protocol, schema and code-generator tool forsimplifying the development of backend services for modern Web applications.

• Getting started
• Code generators
• Quick example
  • Example apps
• Why
• Design / architecture
• Schema
• Development
  • Building from source
  • Writing your own code-generator
  • Format ridl files
• Authors
• Credits
• License

1. Installwebrpc-gen
2. Write+design awebrpc schema file for your Web service
3. Run the code-generator to create your server interface and client, ie.
   • webrpc-gen -schema=example.ridl -target=golang -pkg=service -server -client -out=./service/proto.gen.go
   • webrpc-gen -schema=example.ridl -target=typescript -client -out=./web/client.ts
4. Implement the handlers for your server -- of course, it can't guess the server logic :)

another option is to copy thehello-webrpc example, and adapt for your own webapp and server.

Btw, check outhttps://marketplace.visualstudio.com/items?itemName=XanderAppWorks.vscode-webrpc-ridl-syntax for VSCodeplugin for RIDL synx highlighting.

..contribute more!webrpc generators are just Go templates (similar toHugo orHelm).

Here is an example webrpc schema in RIDL format (a new documentation-like format introduced by webrpc)

webrpc = v1name = your-appversion = v0.1.0struct User  - id: uint64  - username: string  - createdAt?: timestampstruct UsersQueryFilter  - page?: uint32  - name?: string  - location?: stringservice ExampleService  - Ping()  - Status() => (status: bool)  - GetUserByID(userID: uint64) => (user: User)  - IsOnline(user: User) => (online: bool)  - ListUsers(q?: UsersQueryFilter) => (page: uint32, users: []User)error 100 RateLimited     "too many requests"   HTTP 429error 101 DatabaseDown    "service outage"      HTTP 503

Generate webrpc Go server+client code:

webrpc-gen -schema=example.ridl -target=golang -pkg=main -server -client -out=./example.gen.go

and see the generated./example.gen.go file of types, server and client in Go. This is essentiallyhow thegolang-basics example was built.

TLDR; it's much simpler + faster to write and consume a webrpc service than traditional approacheslike a REST API or gRPC service.

1. Code-generate your client libraries in full -- never write another API client again
2. Compatible with the Web. A Webrpc server is just a HTTP/HTTPS server that speaks JSON, and thusall existing browsers, http clients, load balancers, proxies, caches, and tools workout of the box (versus gRPC). cURL "just works".
3. Be more productive, write more correct systems.

Writing a Web service / microservice takes a lot of work and time. REST is making me tired.There are many pieces to build -- designing the routes of your service, agreeing on conventionsfor the routes with your team, the request payloads, the response payloads, writing the actual serverlogic, routing the methods and requests to the server handlers, implementing the handlers, andthen writing a client library for your desired language so it can speak to your Webservice. Yikes, it's a lot of work. Want to add an additional field or handler? yea, youhave to go through the entire cycle. And what about type-safety across the wire?

webrpc automates a lot the work for you. Now from a singlewebrpc schema file,you can use thewebrpc-gen cli to generate source code for:

• Strongly-typed request / response data payloads for your target language
• Strongly-typed server interface and methods on the service, aka the RPC methods
• Complete client library to communicate with the web service

webrpc services speak JSON, as our goals are to build services that communicate with webapps.We optimize for developer experience, ease of use and productivity when building backendsfor modern webapps. However, webrpc also works great for service<->service communication,but it won't be as fast as gRPC in that scenario, but I'd be surprised to hear if for the majorityof cases that this would be a bottleneck or costly tradeoff.

webrpc is heavily inspired by gRPC and Twirp. It is architecturally the same and has a similarworkflow, but simpler. In fact, the webrpc schema is similar in design to protobuf, asin we have messages (structs) and RPC methods, but the type system is arguably more flexible andcode-gen tooling is simpler. Thewebrpc schema is a documentation-likelanguage for describing a server's api interface and the type system within is inspired by Go,Typescript and WASM.

We've been thinking about webrpc's design for years, and were happy to see gRPC and Twirpcome onto the scene and pave the way with some great patterns. Over the years and after writingdozens of backends for Javascript-based Webapps and native mobile apps, and even built priorlibraries likechi, a HTTP router for Go -- we asked ourselves:

Why have "Rails" and "Django" been such productive frameworks for writing webapps? And the answerwe came to is that its productive because the server and client are the same program,running in the same process on the same computer. Rails/Django/others like it, when renderingclient-state can just call a function in the same program, the client and the serverare within the same domain and same state -- everything is a function-call away. Compare this tomodern app development such as writing a React.js SPA or a native iOS mobile app, where the appspeaks to an external API server with now the huge added effort to bridge data/runtime fromone namespace (the app) to an entirely other namespace (the server). It's too much work andtakes too much time, and is too brittle. There is a better way! instead of writing the code..just generate it. If we generate all of the code to native objects in both app/server,suddenly, we can make a remote service once again feel like calling a method on the sameprogram running on the same computer/process. Remote-Procedure-Call works!

Finally, we'd like to compare generated RPC services (gRPC/Twirp/webrpc/other) to the mostcommon pattern to writing services by "making a RESTful API", where the machinery is similarto RPC services. Picture the flow of data when a client calls out to a server -- from a clientruntime proxy-object, we encode that object, send it over the wire, the server decodes it intoa server runtime proxy-object, the server handler queries the db, returns a proxy object,encodes it, and sends the function return data over the wire again. That is a ton of work,especially if you have to write it by hand and then maintain robust code in both the client andthe server. Ahh, I just want to call a function on my server from my app! Save yourself the workand time, and code-generate it instead - Enter gRPC / Twirp .. and now, webrpc :)

Future goals/work:

1. Add RPC streaming support for client/server
2. More code generators.. for Rust, Python, ..

The webrpc schema type system is inspired by Go and TypeScript, and is simple and flexible enoughto cover the wide variety of language targets, designed to target RPC communication with Webapplications and other Web services.

High-level features:

• RIDL, aka RPC IDL, aka "RPC interface design language", format - a documentation-like schemaformat for describing a server application.
• JSON schema format is also supported if you prefer to write tools to target webrpc's code-gen tools
• Type system inspired by Go + Typescript
  • integers, floats, byte, bool, any, null, date/time
  • lists (multi-dimensional arrays supported too)
  • maps (with nesting / complex structures)
  • structs / objects
    • optional fields, default values, and pluggable code-generation for a language target
  • enums

For more information please see theschema readme.

1. Install Go 1.16+
2. $make build
3. $make test
4. $make install

Seewebrpc-gen documentation.

• UseRidlfmt
• Supports same arguments asgofmt
• See:Example

• Peter Kieltyka
• José Carlos Nieto
• Vojtech Vitek
• ..and full list ofcontributors!

• Twirp authors for making twirp. Much of the webrpc-golibrary comes from the twirp project.
• gRPC authors, for coming up with the overall architecture and patternsfor code-generating the bindings between client and server from a common IDL.

MIT