4 ms·

Interesting. I'll have to look at this in more depth when I'm off the phone. It does seem a bit over to top. I've been toying with a similar idea that would fo

Interesting. I'll have to look at this in more depth when I'm off the phone. It does seem a bit over to top. I've been toying with a similar idea that would focus only on static libraries and would handle binaries as an optimization. Just being able to specify "fetch zlib, protocol buffers and libjpeg" and build them for me would simplify many of my C projects. The only coherent way I could think of to manage architectural differences was to force a single build tool that understood the important compiler flags and version incompatibilities. Building from source solves a lot of problems but somehow even today it still takes forever to compile certain projects (looking at you, grpc).

craigtiller 11y ago
Where are the most painful points in getting going with GRPC? (Looking to make this better)
- rjpower9000 11y ago
  Sorry, just seeing this now. I can't speak for other languages, but for C++, it's mainly the huge build time just to get started using the project. This is obviously an issue for any C++ project, but with GRPC, having to build all of OpenSSL is particularly annoying. (Especially if you're not using secured channels!). I also couldn't figure out how to build just the C++ static libraries easily. Instead I end up building everything and then deleting the shared libraries. That's easier to do than trying to figure out how to convince the linker that I prefer to link statically. Once that's out of the way it's pretty reasonable. It took a while to figure out that `--cpp_out` doesn't actually generate stubs, though I'm sure it's documented. So it's not really worse than any other package; it's just _big_, and that makes it a little more annoying. Having any kind of reasonable package manager for C would simplify things dramatically. Not having to express my dependency on GRPC as a git submodule+some clunky Makefile rules would be nice.
- mahtuag 11y ago
  Hi Craig, I tried using gRPC with Go before having to abandon the project for reasons outside my control. Looking forward to using it once again and this time take it to production. The only trouble I had was with the documentation which was scarce. Anyway, here are some comments on how to improve things with gRPC: 1. A dedicated mini-site for each supported language. This http://www.grpc.io/docs/guides/auth.html http://www.grpc.io/docs/guides/auth.html is really confusing to read due to the cocktail of languages. All examples need to be in all languages and the user should be able to choose which language to view documentation for. 2. http://www.grpc.io/docs/guides/error.html http://www.grpc.io/docs/guides/error.html needs to be populated. Right now I use a custom error code enum w/ 0 as SUCCESS so that my downstream consumers (app developers) get a descriptive identifier. I don't even know if there is anything else I should be aware of that gRPC offers to work with errors. 3. A how-to on setting (on a client) and accessing (on a server) custom HTTP headers in gRPC. This is needed for reading the Authorization header during authentication for example. Another example is setting the From header (email of user) and using this to enable persistent sessions. I appreciate the docs covering these two specific examples as they are rather common. 4. A simple guide on how to manually make an application speak the gRPC protocol - both as a client and as a server. Helpful for those who want to integrate other languages w/ gRPC enabled languages. Endgame is they can speak the wire protocol and understand the conventions just enough to quickly write a working client/server for their app. Great if this example uses JavaScript (most people have to learn it anyway due to the browser). 5. RPCs with multiple messages as arguments in input and/or output. All examples have SomeServiceRequest and SomeServiceResponse messages for SomeService RPC giving the impression that all RPCs are single argument in the .proto file. This isn't stated explicitly anywhere creating an ambiguity. 6. Move to Discourse from Google Groups. Much easier to use and would let us organize the discussions better. Also use this to power comments on the gRPC website for each page. I can see this step alone helping the community aspect of gRPC immensely. 7. Create a visual gRPC explorer. Ideally this should be a simple HTML/CSS/JavaScript static page running on browsers that support HTTP/2 and making it would be a good way to start supporting gRPC on the browser (refer Point 5 above).
Nullabillity 11y ago
What's your opinion on Nix?

craigtiller 11y ago

Where are the most painful points in getting going with GRPC? (Looking to make this better)

rjpower9000 11y ago
Sorry, just seeing this now. I can't speak for other languages, but for C++, it's mainly the huge build time just to get started using the project. This is obviously an issue for any C++ project, but with GRPC, having to build all of OpenSSL is particularly annoying. (Especially if you're not using secured channels!). I also couldn't figure out how to build just the C++ static libraries easily. Instead I end up building everything and then deleting the shared libraries. That's easier to do than trying to figure out how to convince the linker that I prefer to link statically. Once that's out of the way it's pretty reasonable. It took a while to figure out that `--cpp_out` doesn't actually generate stubs, though I'm sure it's documented. So it's not really worse than any other package; it's just _big_, and that makes it a little more annoying. Having any kind of reasonable package manager for C would simplify things dramatically. Not having to express my dependency on GRPC as a git submodule+some clunky Makefile rules would be nice.
mahtuag 11y ago
Hi Craig, I tried using gRPC with Go before having to abandon the project for reasons outside my control. Looking forward to using it once again and this time take it to production. The only trouble I had was with the documentation which was scarce. Anyway, here are some comments on how to improve things with gRPC: 1. A dedicated mini-site for each supported language. This http://www.grpc.io/docs/guides/auth.html http://www.grpc.io/docs/guides/auth.html is really confusing to read due to the cocktail of languages. All examples need to be in all languages and the user should be able to choose which language to view documentation for. 2. http://www.grpc.io/docs/guides/error.html http://www.grpc.io/docs/guides/error.html needs to be populated. Right now I use a custom error code enum w/ 0 as SUCCESS so that my downstream consumers (app developers) get a descriptive identifier. I don't even know if there is anything else I should be aware of that gRPC offers to work with errors. 3. A how-to on setting (on a client) and accessing (on a server) custom HTTP headers in gRPC. This is needed for reading the Authorization header during authentication for example. Another example is setting the From header (email of user) and using this to enable persistent sessions. I appreciate the docs covering these two specific examples as they are rather common. 4. A simple guide on how to manually make an application speak the gRPC protocol - both as a client and as a server. Helpful for those who want to integrate other languages w/ gRPC enabled languages. Endgame is they can speak the wire protocol and understand the conventions just enough to quickly write a working client/server for their app. Great if this example uses JavaScript (most people have to learn it anyway due to the browser). 5. RPCs with multiple messages as arguments in input and/or output. All examples have SomeServiceRequest and SomeServiceResponse messages for SomeService RPC giving the impression that all RPCs are single argument in the .proto file. This isn't stated explicitly anywhere creating an ambiguity. 6. Move to Discourse from Google Groups. Much easier to use and would let us organize the discussions better. Also use this to power comments on the gRPC website for each page. I can see this step alone helping the community aspect of gRPC immensely. 7. Create a visual gRPC explorer. Ideally this should be a simple HTML/CSS/JavaScript static page running on browsers that support HTTP/2 and making it would be a good way to start supporting gRPC on the browser (refer Point 5 above).

Nullabillity 11y ago

What's your opinion on Nix?