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"
Fuck the memes.
Fuck the framework battles.
Fuck the language battles.
Fuck the titles.
Anybody who has been in this field long enough knows that it doesn't matter if your linus fucking torvalds, there is no human who has lived or ever will live that simultaneously understands, knows, and remembers how to implement, in multiple languages, the following:
- jest mocks for complex React components (partial mocks, full mocks, no mocks at all!)
- token cancellation for asynchronous Tasks in C#
- fullstack CRUD, REST, and websocket communication (throw in gRPC for bonus points)
- database query optimization, seeding, and design
- nginx routing, https redirection
- build automation with full test coverage and environment consideration
- docker container versioning, restoration, and cleanup
- internationalization on both the front AND backends
- secret storage, security audits
- package management, maintenence, and deprecation reviews
- integrating with dozens of APIs
- fucking how to center a div
and that's a _comically_ incomplete list; barely scratches the surface of the full range of what a dev can encounter in a given day of writing software
have many of us probably done one or even all of these at different times? surely.
but does that mean we are supposed to draw that up at a moment's notice some cookie-cutter solution like a fucking robot and spit out an answer on a fax sheet?
recruiters, if you read this site (perhaps only the good ones do anyway so its wasted oxygen), just know that whoever you hire its literally the luck of the draw of how well they perform during the interview. sure, perhaps some perform better, but you can never know how good someone is until they literally start working at your org, so... have fun with that.
Oh and I almost forgot, again for you recruiters, on top of that list which you probably won't ever understand for the entirety of your lives, you can also add writing documentation, backup scripts, and orchestrating / administrating fucking JIRA or actually any somewhat technical dashboard like a CMS or website, because once again, the devs are the only truly competent ones - and i don't even mean in a technical sense, i mean in a HUMAN sense of GETTING SHIT DONE IN GENERAL.
There's literally 2 types of people in the world: those who sit around drawing flow charts and talking on the phone all day, and those WHO LITERALLY FUCKING BUILD THE WORLD
why don't i just run the whole fucking company at this point? you guys are "celebrating" that you made literally $5 dollars from a single customer and i'm just sitting here coding 12 hours a day like all is fine and well
i'm so ANGRY its always the same no matter where i go, non-technical people have just no clue, even when you implore them how long things take, they just nod and smile and say "we'll do it the MVP way". sure, fine, you can do that like 2 or 3 times, but not for 6 fucking months until you have a stack of "MVPs" that come toppling down like the garbage they are.
How do expect to keep the "momentum" of your customers and sales (I hope you can hear the hatred of each of these market words as I type them) if the entire system is glued together with ducktape because YOU wanted to expedite the feature by doing it the EASY way instead of the RIGHT way. god, just forget it, nobody is going to listen anyway, its like the 5th time a row in my life
we NEED tests!
we NEED to know our code coverage!
we NEED to design our system to handle large amounts of traffic!
we NEED detailed logging!
we NEED to start building an exception database!
BILBO BAGGINS! I'm not trying to hurt you! I'm trying to help you!
Don't really know what this rant was, I'm just raging and all over the place at the universe. I'm going to bed.20
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
BE GONE CLOWN!!!! MAY YOU BE CAST BACK UNTO THE DEPTHS FROM WHICH YOU HAVE SPRUNG!!!!!
can't wait to be absolutely fuck you rich while the clowns continue to fumble around in the sandbox for the next 5 years 🪣⛏️😂😂😂
all those years, crouched over a laptop, learning React, then TypeScript, then PostgreSQL, then .NET, then React Hooks, then Redux Toolkit, then Golang, then GraphQL, and even RabbitMQ and gRPC mixed in... more and more and more............ IT'S TIME TO SPREAD MY WINGS AND FUCKING FLY BABY!!!!!
why work for clueless clowns when your own technical know-how is literally 1000x (or perhaps infinitely) theirs? Was I an idiot? Yes, I was! Way too nice and I bought into the hype fake idiot brain culture, but now I've finally woken up. Time to ascend to the stars by myself.
Cheers devRant, this 🤡 is finally going to transform into a 👨🚀🚀
You may not hear from me for a while sadly, but I'll be sure you guys get the first shoutout - see you on 🪐3
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 :)13
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
(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.36
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
Currently working on a webassembly Blazor project with IdentityServer4, gRPC, SignalR, and webdev is once again fun2
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
Man I have no idea how my company is running as stable as they do. Every time I peak under the curtain of some piece of machinery I find such bad practices…
Just found out our in house database manager only supports listing all objects in a table, updating objects by first reading each row you need to update and only support “select *” queries.
This is after having to argue with some engineers that using http or grpc when interacting with the new service I’m writing in the none-jvm language is better than writing our own driver for their custom rpc and service discovery system.
But like honestly I’d be mad if these decisions had a visible performance impact on the business, but it somehow doesn’t… this is bizzaro world where all I learned from my 8 years experience as a professional goes out the window…1
Ive been working on pseudo-Java (ie some 3rd company's UNDOCUMENTED programming language) that they parse into Java in their backend
It doesnt even support if-else (only ifs and elses) or a boolean combination of False and OR together lmao
mainly a GRPC middleware-language
Given its lack of features (arrays/collections) or documentation, I just had to implement a flag-array using a 0-1 string
Im throwing exceptions unless combined strings equal Lengths and is only 1s
living like in 80s-90s 💀7
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
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)13
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 spent the whole damn day trying to setup grpc-web, but this protocol is documented so damn poorly!
You manage to set grpc up for one language and it’s all cool, then you stupidly think that you are free to reuse the compiler you used for the nodejs version for your frontend part but nope! Our web module is now deprecated, please use this module instead!
“Ah yes just clone the repo and check out (…) and you can also check this link whic is in no way highlighted in the middle of a wall of text (…)”
*checking the other page*
Ah yes you need to install a package available only on your unix machine (great! Screw the devs in my team who use windows I guess, they’ll be happy to hear this!) and don’t forget to clone this repo to build your own plugin! And by that I ofc mean to compile it on your own!
- compiler error
After digging for an hour you find a requirement in an obscure issue opened and closed cause “ah yes we have a dependency not stated anywhere” *close issue and never add it to the project*
Fine, fine I can survive this bs
- another compiler error, no solution found after 2 hours
Honestly? Why the fuck do I need to compile this stuff? Just give me a damn npm package I can use? Goddamn it’s just transpiling, you don’t need access to my OS! (Aside for fs to save the files, and which btw is accessible via nodejs)
Now, I COULD download the latest realease as a precompiled, but… honestly?
I give up, I’ll do some shitty rest apis cause the customer’s not paying me enough for even THINKING to go trough this shit again when they’ll ask an iOS app. Or having colleagues asking me to help them understand how to do it.
Side note: also add typescript support to the web-code-generation ffs! Why does node have it and web don’t?5
Job offer, searching for somebody with (amongst others):
- React, Angular
- Azure, Kubernetes, Redis
- Mongo, MySQL
Why do they want to fill 3-4 positions with a single person? I'm afraid I'm only 2 of those people they're searching for.7
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
If your platform doesn’t target websites, just server-server or server-mobile; you’re better off with gRPC. Assuming there’s no learning overhead, of course.
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.
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/...1
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.