pronto
grpc-gateway
pronto | grpc-gateway | |
---|---|---|
4 | 30 | |
6 | 17,391 | |
- | 0.9% | |
0.0 | 9.8 | |
over 3 years ago | 5 days ago | |
Java | Go | |
MIT License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pronto
-
Buf raises $93M to deprecate REST/JSON
5. Message streaming (gRPC streams are amazing)
I can think of a whole host of features that can be built off of protos (I've even built ORMs off of protobuffs for simple things [0]). The value prop is there IMO. HTTP + json APIs are a local minima. The biggest concerns "I want to be able to view the data that is being sent back and forth" is a tooling consideration (curl ... isn't showing you the voltages from the physical layer, it is decoded). Buff is building that tooling.
[0] - https://github.com/CaperAi/pronto
-
Parsing Gigabytes of JSON per Second
I've written translation layers for such systems and it's not too bad. See this project from $job - 1: https://github.com/CaperAi/pronto
It allowed us to have a single model for storage in the DB, for sending between services, and syncing to edge devices.
-
gRPC for Microservices Communication
There's no reason you couldn't use gRPC with json as a serialized message format. For example grpc-gateway [0] provides a very effective way of mapping a gRPC concept to HTTP/JSON. The thing is, after moving to gRPC, I've never really felt a desire to move back to JSON. While it may be correct to say "parsing json is fast enough" it's important to note that there's a "for most use cases" after that. Parsing protos is fast enough for even more use cases. You also get streams which are amazing for APIs where you have to sync some large amounts of data (listing large collections from a DB for example) across two services.
With gRPC you also have a standardized middleware API that is implemented for "all" languages. The concepts cleanly map across multiple languages and types are mostly solved for you.
Adding to that you can easily define some conventions for a proto and make amazing libraries for your team. At a previous job I made this: https://github.com/CaperAi/pronto/
Made it super easy to prototype multiple services as if you mock a service backed by memory we could plop it into a DB with zero effort.
I think this "gRPC vs X" method of thinking isn't appropriate here because protos are more like a Object.prototype in JavaScript. They're a template for what you're sending. If you have the Message you want to send you can serialize that to JSON or read from JSON or XML or another propriety format and automatically get a host of cool features (pretty printing, serialization to text/binary, sending over the network, etc).
[0] - https://github.com/grpc-ecosystem/grpc-gateway
-
We Went All in on Sqlc/Pgx for Postgres and Go
I attempted to make something similar to this except the opposite direction at a previous job. It was called Pronto: https://github.com/CaperAi/pronto/
It allowed us to store and query Protos into MongoDB. It wasn't perfect (lots of issues) but the idea was rather than specifying custom models for all of our DB logic in our Java code we could write a proto and automatically and code could import that proto and read/write it into the database. This made building tooling to debug issues very easy and make it very simple to hide a DB behind a gRPC API.
The tool automated the boring stuff. I wish I could have extended this to have you define a service in a .proto and "compile" that into an ORM DAO-like thing automatically so you never need to worry about manually wiring that stuff ever again.
grpc-gateway
-
I write HTTP services in Go after 13 years (Mat Ryer, 2024)
it lacks flexibility but i really enjoy grpc-gateway for 99% of my work
https://github.com/grpc-ecosystem/grpc-gateway
-
Create Production-Ready SDKs With gRPC Gateway
gRPC Gateway is a protoc plugin that reads gRPC service definitions and generates a reverse proxy server that translates a RESTful JSON API into gRPC.
-
Ask HN: Rapid Development API-Only One Person Stack – Seeking Performant Tech
I don't have any example that's public atm, but the guide in grpc-gateway is pretty clear/can be followed step by step.
https://github.com/grpc-ecosystem/grpc-gateway
To integrate with Fiber, I used the Fiber Adaptor (also pretty straightforward): https://docs.gofiber.io/api/middleware/adaptor
-
Seeking advice on implementing a tinyurl-like service using Go and gRPC.
I wonder if they would be happy with something like this: https://github.com/grpc-ecosystem/grpc-gateway
- How do I provide bot RPC and REST endpoints?
-
Reasons to use gRPC/Protobuf?
Protobuf is used is massively scaled services like firebase. But you'll still see JSON in streamed realtime services like AWS Kinesis. Hopefully google had a return on investment for creating and using this protocol, but it's not hard to prove that it's far from essential. Out of apparent convenience I use grpc-gateway so I can expose both Protobuf and JSON, but honestly I wouldn't do it again
-
gRPC microservices communication in kubernates
GRPC is an alternative to rest, rest and GRPC both use the http protocol. But you won’t be able to use fetch to call a GRPC endpoint, you should look into setting up a GRPC proxy within the application(hopping you have access to the source code) grpc-gateway. If you don’t have access you’ll have to create a new container that proxies the calls
-
Question about gRPC?
(There is an option called google.api.http, that lets you set up a URL that can be used to make HTTP/1 REST requests, which get translated to gRPC calls if you're using grpc-gateway as a proxy in front of your service. That has nothing to do with the requests that are made by gRPC clients and servers themselves.)
-
Issues with proxying gRPC services to web, and a potential prototype
Have you looked at https://github.com/grpc-ecosystem/grpc-gateway ?
-
Understanding gRPC Concepts, Use Cases & Best Practices
protoc-gen-grpc-gateway — plugin for creating a gRPC REST API gateway. It allows gRPC endpoints as REST API endpoints and performs the translation from JSON to proto. Basically, you define a gRPC service with some custom annotations and it makes those gRPC methods accessible via REST using JSON requests.
What are some alternatives?
simd-json - Rust port of simdjson
examples - A repository to host examples and tutorials for Gin.
pike - Generate CRUD gRPC backends from single YAML description.
MassTransit - Distributed Application Framework for .NET
sqlparser-rs - Extensible SQL Lexer and Parser for Rust
Kreya - Kreya is a GUI client for REST and gRPC with innovative features for environments, authorizations and more.
pggen - A database first code generator focused on postgres
OpenAPI-Specification - The OpenAPI Specification Repository
sqlite
grpc-web - gRPC for Web Clients
ccgo
openapi3 - OpenAPI 3.0 data model