8 ms·

Sonora: Python implementation of gRPC-Web built on top of WSGI/ASGI

53 points by BiteCode_dev 5y ago

languagehacker 5y ago
Pretty cool! Honestly, I've found the challenges related to standing up Python-based gRPC services to be super complicated and not worth the hit. I'm not sure this solves that in particular, because most of the pain is around things like TLS, HTTP2, proxy and loadbalancer configuration, and other things I'd love to not have to spend hours worrying about just to massage the bytes right. This is a long-winded way of saying that I used to really love protocol buffers and gRPC but at this point am a little soured on them in practice.
- __alexs 5y ago
  Hi, author of Sonora here. gRPC-Web is actually exactly what you want if you want gRPC but none of the TLS, HTTP2 etc pain. It "just works" on HTTP/1.1 like any other server. The Google libraries are definitely a pain to use in Python and even if you've got all the HTTP2 stuff sorted already it doesn't play that nicely with existing code bases.
  - CobrastanJorji 5y ago
    Hey, I haven't tried using gRPC with Python yet but I had been considering it recently and now I'm worried. Could you give me an example of what sort of trouble I should expect? What sort of trouble is it going to give my existing code base?
    - __alexs 5y ago
      The first issue I've seen people struggle with are to do with generating the Python bindings in the right modules. Getting the right combination of arguments to protoc isn't always obvious. The main complexity with an existing code base is that gRPC runs its own ioloop so it controls the server entirely so you can't glue it into an existing Python webapp easily. You can call all your existing Python functions etc just fine though.
      - CobrastanJorji 5y ago
        Interesting, thank you!
  - languagehacker 5y ago
    Nifty. I assume this still means using some combination of Envoy + Nginx to "downgrade" to 1.1 in a traditional web service environment if the client defaults to HTTP/2. Is that right?
    - no_circuit 5y ago
      gRPC is HTTP/2. I'd say its more of a situation that you need to "upgrade" 1.1 clients. See https://www.envoyproxy.io/docs/envoy/v1.17.4/configuration/http/http_filters/grpc_json_transcoder_filter#config-http-filters-grpc-json-transcoder https://www.envoyproxy.io/docs/envoy/v1.17.4/configuration/h.... NGINX isn't necessary unless you need it in addition for some connection handling / performance concerns. Otherwise the gRPC handling I believe is best with just Envoy alone.
    - __alexs 5y ago
      I don't think there is actually a good solution for connecting a regular H2 gRPC client to a gRPC-Web server currently. Envoy's gRPC-Web filter only seems to go the other way. I haven't tested it but the old HTTP/1.1 reverse bridge might work. [0] [0] https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/grpc_http1_reverse_bridge_filter https://www.envoyproxy.io/docs/envoy/latest/configuration/ht...
- xarope 5y ago
  I'm currently working on a python-based gRPC project. I use envoy to handle all the stuff you mentioned. I do like gRPC compared to REST, although I wish there were more native data types for gRPC, e.g. UUID and Decimal/Numeric - I create types for these ala google's string marshalling for decimals, but it means therefore I must do my own data validation.
andy_ppp 5y ago
I used grpc and grpc-web in a couple of jobs and found the following: 1) difficult to debug (various) but the over the wire being a binary protocol means you can't just look in dev tools and figure out what happened with your request. 2) reinvents everything http already has - literally in the source of the GRPC library it renames and groups all the HTTP error codes that can happen into GRPC error codes that are meaningless. 3) Versioning hell - Protobuf or whatever it uses does not seem to make sure the message and the schema match so if you happen to send or receive the wrong message format after a schema change you might just get weird errors - even a rudimentary checksum could have helped here. 4) What problem are you solving that you need GRPC - the only reason I can see to use it is scale (are you Google?) and fashionability. 5) Bad documentation - there are known ways to do everything with rest or graphql but often you are rolling your own way with GRPC and I was never sure if what I was doing was idiomatic. What are the industry standard ways to get around these issues with GRPC? EDIT: sorry to be so negative about GRPC, I personally think it's a missed opportunity is all, in theory it could be amazing. And Sonora looks like an awesome implementation.
- sgeisenh 5y ago
  gRPC is very opinionated. Protobuf allows some things that tend to be design mistakes (e.g. required fields). A lot of this has been corrected with proto3, with subsequent field behavior annotations described here: https://google.aip.dev/203 https://google.aip.dev/203 The whole of aip.dev is a collection of API design principles published by Google that are externally relevant. Many of the proposals pertain specifically to gRPC-style APIs. I've personally found gRPC APIs to be pleasant relative to many HTTP APIs since the use of an IDL can be helpful when interacting with such APIs. I don't have enough GraphQL experience to make any conclusions on that comparison. But the sense that I get is that GraphQL may be more appropriate once you reach a certain scale but is probably overused when a simpler technology would suffice. Disclaimer: I work for Google but the views I express are my own and not necessarily those of my employer.
- malkia 5y ago
  re: compatibility. There are some guides to pervent compatibility issues - https://developers.google.com/protocol-buffers/docs/proto3#updating https://developers.google.com/protocol-buffers/docs/proto3#u...
kumarvvr 5y ago
So, how reliable is gRPC-web? Is it production ready? Can it be a good replacement for AJAX? I have been itching to use gRPC because, I just hate REST and everything JSON.

53 points by BiteCode_dev 5y ago

Pretty cool! Honestly, I've found the challenges related to standing up Python-based gRPC services to be super complicated and not worth the hit. I'm not sure this solves that in particular, because most of the pain is around things like TLS, HTTP2, proxy and loadbalancer configuration, and other things I'd love to not have to spend hours worrying about just to massage the bytes right. This is a long-winded way of saying that I used to really love protocol buffers and gRPC but at this point am a little soured on them in practice.

__alexs 5y ago
Hi, author of Sonora here. gRPC-Web is actually exactly what you want if you want gRPC but none of the TLS, HTTP2 etc pain. It "just works" on HTTP/1.1 like any other server. The Google libraries are definitely a pain to use in Python and even if you've got all the HTTP2 stuff sorted already it doesn't play that nicely with existing code bases.
- CobrastanJorji 5y ago
  Hey, I haven't tried using gRPC with Python yet but I had been considering it recently and now I'm worried. Could you give me an example of what sort of trouble I should expect? What sort of trouble is it going to give my existing code base?
  - __alexs 5y ago
    The first issue I've seen people struggle with are to do with generating the Python bindings in the right modules. Getting the right combination of arguments to protoc isn't always obvious. The main complexity with an existing code base is that gRPC runs its own ioloop so it controls the server entirely so you can't glue it into an existing Python webapp easily. You can call all your existing Python functions etc just fine though.
    - CobrastanJorji 5y ago
      Interesting, thank you!
- languagehacker 5y ago
  Nifty. I assume this still means using some combination of Envoy + Nginx to "downgrade" to 1.1 in a traditional web service environment if the client defaults to HTTP/2. Is that right?
  - no_circuit 5y ago
    gRPC is HTTP/2. I'd say its more of a situation that you need to "upgrade" 1.1 clients. See https://www.envoyproxy.io/docs/envoy/v1.17.4/configuration/http/http_filters/grpc_json_transcoder_filter#config-http-filters-grpc-json-transcoder https://www.envoyproxy.io/docs/envoy/v1.17.4/configuration/h.... NGINX isn't necessary unless you need it in addition for some connection handling / performance concerns. Otherwise the gRPC handling I believe is best with just Envoy alone.
  - __alexs 5y ago
    I don't think there is actually a good solution for connecting a regular H2 gRPC client to a gRPC-Web server currently. Envoy's gRPC-Web filter only seems to go the other way. I haven't tested it but the old HTTP/1.1 reverse bridge might work. [0] [0] https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/grpc_http1_reverse_bridge_filter https://www.envoyproxy.io/docs/envoy/latest/configuration/ht...
xarope 5y ago
I'm currently working on a python-based gRPC project. I use envoy to handle all the stuff you mentioned. I do like gRPC compared to REST, although I wish there were more native data types for gRPC, e.g. UUID and Decimal/Numeric - I create types for these ala google's string marshalling for decimals, but it means therefore I must do my own data validation.

andy_ppp 5y ago

I used grpc and grpc-web in a couple of jobs and found the following: 1) difficult to debug (various) but the over the wire being a binary protocol means you can't just look in dev tools and figure out what happened with your request. 2) reinvents everything http already has - literally in the source of the GRPC library it renames and groups all the HTTP error codes that can happen into GRPC error codes that are meaningless. 3) Versioning hell - Protobuf or whatever it uses does not seem to make sure the message and the schema match so if you happen to send or receive the wrong message format after a schema change you might just get weird errors - even a rudimentary checksum could have helped here. 4) What problem are you solving that you need GRPC - the only reason I can see to use it is scale (are you Google?) and fashionability. 5) Bad documentation - there are known ways to do everything with rest or graphql but often you are rolling your own way with GRPC and I was never sure if what I was doing was idiomatic. What are the industry standard ways to get around these issues with GRPC? EDIT: sorry to be so negative about GRPC, I personally think it's a missed opportunity is all, in theory it could be amazing. And Sonora looks like an awesome implementation.

sgeisenh 5y ago
gRPC is very opinionated. Protobuf allows some things that tend to be design mistakes (e.g. required fields). A lot of this has been corrected with proto3, with subsequent field behavior annotations described here: https://google.aip.dev/203 https://google.aip.dev/203 The whole of aip.dev is a collection of API design principles published by Google that are externally relevant. Many of the proposals pertain specifically to gRPC-style APIs. I've personally found gRPC APIs to be pleasant relative to many HTTP APIs since the use of an IDL can be helpful when interacting with such APIs. I don't have enough GraphQL experience to make any conclusions on that comparison. But the sense that I get is that GraphQL may be more appropriate once you reach a certain scale but is probably overused when a simpler technology would suffice. Disclaimer: I work for Google but the views I express are my own and not necessarily those of my employer.
malkia 5y ago
re: compatibility. There are some guides to pervent compatibility issues - https://developers.google.com/protocol-buffers/docs/proto3#updating https://developers.google.com/protocol-buffers/docs/proto3#u...

kumarvvr 5y ago

So, how reliable is gRPC-web? Is it production ready? Can it be a good replacement for AJAX? I have been itching to use gRPC because, I just hate REST and everything JSON.