wampy VS gRPC

Compare wampy vs gRPC and see what are their differences.


Websocket RPC and Pub/Sub for Python applications and microservices (by noisyboiler)


The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#) (by grpc)
Our great sponsors
  • Scout APM - Less time debugging, more time building
  • OPS - Build and Run Open Source Unikernels
  • SonarQube - Static code analysis for 29 languages.
wampy gRPC
0 70
117 33,141
- 1.9%
3.4 9.9
8 months ago 3 days ago
Python C++
Mozilla Public License 2.0 Apache License 2.0
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
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.


Posts with mentions or reviews of wampy. We have used some of these posts to build our list of alternatives and similar projects.

We haven't tracked posts mentioning wampy yet.
Tracking mentions began in Dec 2020.


Posts with mentions or reviews of gRPC. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-01-18.
  • Serialization
    2 projects | dev.to | 18 Jan 2022
    Binary formats are often faster to parse and result in smaller payloads. For instance, we could build a gRPC API that uses Protobufs as its serialization format. You can see from our example above that the Protobuf version of {hello: "world"} is only 7 bytes, less than half the size of the JSON version. This means our API would be sending out much less data, which can be really helpful for APIs with gigantic payloads. But we lose the human-readability and debuggability: you can't just inspect the response in your browser.
  • REST API: The Fun Way
    4 projects | dev.to | 17 Jan 2022
    Besides, Encore app is not compiled to one app, but to microservices that can interact between themselves in a much more efficient manner than just HTTP calls (gRPC).
  • DNS URI Scheme RFC
    1 project | reddit.com/r/networking | 16 Dec 2021
    It's supported by gRPC: https://github.com/grpc/grpc/blob/master/doc/naming.md
  • Yet another post on Rust error handling
    1 project | reddit.com/r/rust | 12 Dec 2021
    Along these lines, it's worth looking at grpc::StatusCode. This is Google's "canonical error space": 16 variants that are encouraged to be used for essentially any error returned by a library or service. (If you need finer-grained stuff than that, you can attach an error payload.) A few big advantages of sticking with one set of variants include:
  • Real time Dashboard
    6 projects | reddit.com/r/Frontend | 11 Dec 2021
    Given your timeframe, I'd probably avoid GraphQL entirely - there is quite a learning curve, and the benefit for what you are doing will be minimal (GraphQL is amazing, just not for your use case). You could go with grpc, or trpc - though this one is still in early beta.
  • 2021-12-10 benchmark results ยท LesnyRumcajs/grpc_bench Wiki
    2 projects | reddit.com/r/cpp | 10 Dec 2021
    What are we comparing here? Are these implementations of gRPC? What's the workload? Is it testing network I/O, IPC, or just in-memory operations?
  • What is the best way to have two programs talk to one another?
    1 project | reddit.com/r/learnprogramming | 10 Dec 2021
  • Buf raises $93M to deprecate REST/JSON
    6 projects | news.ycombinator.com | 8 Dec 2021
    `proto_library` for building the `.bin` file from protos works great. Generating stubs/messages for "all" languages does not. Each language does not want to implement gRPC rules, the gRPC team does not want to implement rules for each language. Sort of a deadlock situation. For example:

    - C++: https://github.com/grpc/grpc/blob/master/bazel/cc_grpc_libra...

    - Python: https://github.com/grpc/grpc/blob/master/bazel/python_rules....

    - ObjC: https://github.com/grpc/grpc/blob/master/bazel/objc_grpc_lib...

    - Java: https://github.com/grpc/grpc-java/blob/master/java_grpc_libr...

    - Go (different semantics than all of the other): https://github.com/bazelbuild/rules_go/blob/master/proto/def...

    But there's also no real cohesion within the community. The biggest effort to date has been in https://github.com/stackb/rules_proto which integrates with gazelle.

    tl;dr: Low alignment results in diverging implementations that are complicated to understand for newcomers. Buff's approach is much more appealing as it's a "this is the one way to do the right thing" and having it just work by detecting `proto_library` and doing all of the linting/registry stuff automagically in CI would be fantastic.

  • What are the pros and cons of graphql as compared to grpc?
    1 project | reddit.com/r/graphql | 1 Dec 2021
    Our company is trying to choose between graphql and grpc. One of our senior engineer is saying to use grpc as it is framework agnostic and easy to implement micro services architecture in different language. Graphql is more widely used in js community as compared to others. We are gonna use the backend service for mobile and web. From frontend perspective I see more love to graphql than grpc. Some of the grpc sample on grpc.io are difficult to get you head around for android, iOS swift has completely different repo maintained on GitHub and same for web as well.
  • Alpine Linux 3.15 Released
    5 projects | news.ycombinator.com | 24 Nov 2021
    I did know this, but it wasn't 100% reliable, see https://github.com/grpc/grpc/issues/18150

    Regarding the "runs just fine", this is not guaranteed. I certainly do check if it is working, and if it is, and it is a small service or just a containerized tool, then I'll use it. Like using GDAL to perform some reprojections and renderings where a throwaway container is called from a shell script, if it works once, I'll keep using it, but I won't use it to run a Python server which also makes use of Matplotlib and other big dependencies.

What are some alternatives?

When comparing wampy and gRPC you can also consider the following projects:

ZeroMQ - ZeroMQ core engine in C++, implements ZMTP/3.1

Apache Thrift - Apache Thrift

Cap'n Proto - Cap'n Proto serialization/RPC system - core tools and C++ library

rpclib - rpclib is a modern C++ msgpack-RPC server and client library

nanomsg - nanomsg library

zeroRPC - zerorpc for python

RPyC - RPyC (Remote Python Call) - A transparent and symmetric RPC library for python

bloomrpc - GUI Client for GRPC Services

eCAL - eCAL - enhanced Communication Abstraction Layer. A fast publish-subscribe cross-plattform middleware using Shared Memory and UDP.

Nameko - Python framework for building microservices

asio-grpc - Asynchronous gRPC with Asio/unified executors