Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "grpc"
The wife is asleep. The two year old wrecking ball of a boy is asleep. Wanted to finish a library to run kafka/grpc for nodejs microservices with plug and play functionality.
Make some tea. Figured the caffeine will keep me up. Maybe work late night. It'll be fun.
Then diarrhea hits. Now, staying up late because apparently I ate something I shouldn't have. Don't you hate it when that happens?12
Got my Minecraft server running inside Docker to properly stream logs through Go to this shitty web interface. Fucking hell I didn't think this would be so fucking complicated!
Edit: Forgot the image :)14
(long post is long)
This one is for the .net folks. After evaluating the technology top to bottom and even reimplementing several examples I commonly use for smoke testing new technology, I'm just going to call it:
Blazor is the next Silverlight.
It's just beyond the pale in terms of being architecturally flawed, and yet they're rushing it out as hard as possible to coincide with the .Net 5 rebranding silo extravaganza. We are officially entering round 3 of "sacrifice .Net on the altar of enterprise comfort." Get excited.
Since we've arrived here, I can only assume the Asp.net Ajax fiasco is far enough in the past that a new generation of devs doesn't recall its inherent catastrophic weaknesses. The architecture was this:
1. Create a component as a "WebUserControl"
2. Any time a bound DOM operation occurs from user interaction, send a payload back to the server
3. The server runs the code to process the event; it spits back more HTML
Some client-side js then dutifully updates the UI by unceremoniously stuffing the markup into an element's innerHTML property like so much sausage.
If you understand that, you've adequately understood how Blazor works. There's some optimization like signalR WebSockets for update streaming (the first and only time most blazor devs will ever use WebSockets, I even see developers claiming that they're "using SignalR, Idserver4, gRPC, etc." because the template seeds it for them. The hubris.), but that's the gist. The astute viewer will have noticed a few things here, including the disconnect between repaints, inability to blend update operations and transitions, and the potential for absolutely obliterative, connection-volatile, abusive transactional logic flying back and forth to the server. It's the bring out your dead approach to seeing how much of your IT budget is dedicated to paying for bandwidth and CPU time.
Blazor goes a step further in the server-side render scenario and sends every DOM event it binds to the server for processing. These include millisecond-scale events like scroll, which, at least according to GitHub issues, devs are quickly realizing requires debouncing, though they aren't quite sure how to accomplish that. Since this immediately becomes an issue with tickets saying things like, "scroll event crater server, Ugg need help! You said Blazorclub good. Ugg believe, Ugg wants reparations!" the team chooses a great answer to many problems for the wrong reasons:
For those who aren't familiar, gRPC has a substantial amount of compression primarily courtesy of a rather excellent binary format developed by Google. Who needs the Quickie Mart, or indeed a sound markup delivery and view strategy when you can compress the shit out of the payload and ignore the problem. (Shhh, I hear you back there, no spoilers. What will happen when even that compression ceases to cut it, indeed). One might look at all this inductive-reasoning-as-development and ask themselves, "butwai?!" The reason is that the server-side story is just a way to buy time to flesh out the even more fundamentally broken browser-side story. To explain that, we need a little perspective.
The relationship between Microsoft and it's enterprise customers is your typical mutually abusive co-dependent relationship. Microsoft goes through phases of tacit disinterest, where it virtually ignores them. And rightly so, the enterprise customers tend to be weaksauce, mono-platform, mono-language types who come to work, collect a paycheck, and go home. They want to suckle on the teat of the vendor that enables them to get a plug and play experience for delivering their internal systems.
And that's fine. But it's also dull; it's the spouse that lets themselves go, it's the girlfriend in the distracted boyfriend meme. Those aren't the people who keep your platform relevant and competitive. For Microsoft, that crowd has always been the exploratory end of the developer community: alt.net, and more recently, the dotnet core community (StackOverflow 2020's most loved platform, for the haters). Alt.net seeded every competitive advantage the dotnet ecosystem has, and dotnet core capitalized on. Like DI? You're welcome. Are you enjoying MVC? Your gratitude is understood. Cool serializers, gRPC/protobuff, 1st class APIs, metadata-driven clients, code generation, micro ORMs, etc., etc., et al. Dear enterpriseur, you are fucking welcome.
Anyways, b2blazor. So, the front end (Blazor WebAssembly) story begins with the average enterprise FOMO. When enterprises get FOMO, they start to Karen/Kevin super hard, slinging around money, privilege, premiere support tickets, etc. until Microsoft, the distracted boyfriend, eventually turns back and says, "sorry babe, wut was that?" You know, shit like managers unironically looking at cloud reps and demanding to know if "you can handle our load!" Meanwhile, any actual engineer hides under the table facepalming and trying not to die from embarrassment.38
Has been a long time since I'm appreciating working with GRPC.
Amazingly fast and full-featured protocol! No complaints at all.
Although I felt something was missing...
Back in the days of HTTP, we were all given very simple tools for making requests to verify behaviours and data of any of our HTTP endpoints, tools like curl, postman, wget and so on...
This toolset gives us definitely a nice and quick way to explore our HTTP services, debug them when necessary and be efficient.
This is probably what I miss the most from HTTP.
When you want to debug a remote endpoint with GRPC, you need to actually write a client by hand (in any of the supported language) then run it.
There are alternatives in the open source world, but those wants you to either configure the server to support Reflection or add a proxy in front of your services to be able to query them in a simpler way.
This is not how things work in 2018 almost 2019.
We want simple, quick and efficient tools that make our life easier and having problems more under control.
I'm a developer my self and I feel this on my skin every day. I don't want to change my server or add an infrastructure component for the simple reason of being able to query it in a simpler way!
However, This exact problem has been solved many times from HTTP or other protocols, so we should do something about our beloved GRPC.
Fine! I've told to my self. Let's fix this.
A few weeks later...
I'm glad to announce the first Release of BloomRPC - The first GRPC Client GUI that is nice and simple,
It allows to query and explore your GRPC services with just a couple of clicks without any additional modification to what you have running right now! Just install the client and start making requests.
It has been built with the Electron technology so its a desktop app and it supports the 3 major platforms, Mac, Linux, Windows.
Check out the repository on GitHub: https://github.com/uw-labs/bloomrpc
This is the first step towards the goal of having a simple and efficient way of querying GRPC services!
Keep in mind that It is in its first release, so improvements will follow along with future releases.
Your feedback and contributions are very welcome.
If you have the same frustration with GRPC I hope BloomRPC will make you a bit happier!3
We'd just finished a refactor of the gRPC strategy. Upgraded all the containers and services to .Net core 3, pushed a number of perf changes to the base layer and a custom adaptive thread scheduler with a heuristic analyzer to adjust between various strategies.
Went from 1.7M requests/s on 4 cores and 8gb ram to almost 8M requests/s on the same, ended up having to split everything out distributed 2 core instances because we were bottlenecking against 10gb/e bandwidth in AWS.2
Is it just me or the so-called Cloud (or more accurately not our servers) allowed terribly inefficient technologies to exist as backends? Just google "clear grpc benchmark reddit" - I think there should be another column "price per hour in AWS for given resource usage". (sorry, can't post links yet)14
ProfaneDB is a database to store Protobuf objects, working on top of gRPC for cross compatibility.
May evolve anywhere towards a "Serverless" kind of solution; a GraphQL to Protobuf interface; may use SQL as backend...2
A few weeks back we ported our PHP Rest API into a couple of Go micro-services.
Incredibly _satisfying_ job.
Requests went from 20+ seconds to ~100-300ms.
There was still one bottle-neck, though, because we had to use most of the old cluster-fork of a database (because no way I'll be able to fix all that in a week).
And ooh, next we're thinking of switching to gRPC. Man, we have the best jobs.5
Currently working on a webassembly Blazor project with IdentityServer4, gRPC, SignalR, and webdev is once again fun2
Don’t you sometimes feel revolutionary and want to use some technology that is completely impractical for the project?
I’m using grpc on my angular app...
gRPC is very messy and unstable, dependencies doesn't compile (workaround is possible), gRPC don't supports libressl (there exist some PR to add libressl support, so I applied them), finally gRPC doesn't compile.
Have fun using gRPC in C or C++1
I guess these days I work with Golang, gRPC, and Kubernetes. I guess that's a dev stack. Or turning into one at the very least. The only thing that annoys me about this stack, is how different deployments for kubernetes are different for CSPs. The fact that setting up a kubernetes/Golang dev environment is take a lot of time and effort. And gRPC can be a pain in the ass to work with as well. Since it's fairly new in large scale enterprise use, finding best practices can be pretty hard, and everything is "feet in the fire" and "trial by error" when dealing with gRPC.
And Golang channels can get very hairy and complicated really really fast. As well as the context package in Golang. And Golang drama with package managers. I wish they would just settle on GoDeps or vgo and call it a day.
And for the love of God, ADD FUCKING GENERICS! Go code can be needlessly long and wordy. The alternative "struct function members" can be pretty clunky at times.
Anyone ever use gRPC with Objective-C and can help me out?
Following this tutorial:
Been dealing with this for a few days and can't figure it out 😫1
I'm having troubles with gRPC inside Docker, cannot figure out why some references are undefined in the *_pb.go files
pkg/proto/notify/notify_grpc.pb.go:14:11: undefined: grpc.SupportPackageIsVersion7
pkg/proto/notify/notify_grpc.pb.go:71:30: undefined: grpc.ServiceRegistrar
More details: https://stackoverflow.com/q/...2
At last, I'm doing some unknown stuff. We are using Terraform, to create our load balancers and them, kops to deploy our stateless services inside K8 clusters and Jaeger to trace requests end to end (and being able to test/debug our services).
Next step will be using gRPC for our RPC API.
Is Microsoft' new Fluid Framework is an alternative of gRPC/SignalR or what? Or they have no connection at all!? I'm kinda lost here.