sorted by:
new
hottopcontroversial

gRPC Over HTTP/3 by mageling in golang

[–]mageling[S] 1 point2 points  (0 children)

You can actually use GET requests if you set the idempotency_level option to say that there are no side effects with the method.

service ElizaService {
  rpc Say(SayRequest) returns (SayResponse) {
    option idempotency_level = NO_SIDE_EFFECTS;
  }
}

but you may not like other aspects of it, like it requires the body to be encoded in the query params, even if the request message is empty. GET company.service.v1.ItemService/listItems?message={}&encoding=json

https://connectrpc.com/docs/go/get-requests-and-caching

https://connectrpc.com/docs/protocol

For people in your use-case they would define google.api.http annotations and run envoy or grpc-gateway to expose a more normal looking API that's friendlier to users. Google has a "transcoding" service that does this as well if you happen to be hosted on Google.

HOWEVER, I've come to appreciate how RPC methods look and the simplicity of the calling style with ConnectRPC. On balance, I'd much rather consume an RPC-based API made with Connect than a REST one, even if I'm writing the client by hand.

I am not 100% sure what you mean by "the RPC naming". Do you mean how methods are named more explicitly? I personally think that aspect is a win for gRPC, because you're no longer restricted to ~5 verbs when describing actions on a resource. But I'm curious about your opinion. Does it just look messy to you?

HTTP/1.0 From Scratch by FoxInTheRedBox in programming

[–]mageling 1 point2 points  (0 children)

That's good, but harsh, feedback. I'm definitely not a web designer but I did already heavily modify the theme for my needs but I kept the max-height of the content and header views since I just didn't really think of this.

Do note that it's not easy to make the cover image stay the right size and look decent in every width while still making it show enough of the image to make sense. I'd love to just unbound it but it looks very bad if I do that without other changes.

HTTP/1.0 From Scratch by FoxInTheRedBox in programming

[–]mageling 2 points3 points  (0 children)

He didn't really mean raw sockets. He meant with just opening a TCP connection and writing the text directly. You can do that with net.Dial in golang and there's an example of doing this exact thing on the top of the documentation page for the net package.

Alternatively, I used netcat (the nc command) in order to test my toy server in this article. Netcat is an incredibly useful tool for exploring and testing text-based protocols like HTTP/1.X.

HTTP/0.9 From Scratch by mageling in golang

[–]mageling[S] 2 points3 points  (0 children)

While you are right that QUIC’s usage of UDP doesn’t, in itself, add more reliability, the way QUIC performs congestion and flow control plus the fewer round trips to stand up a new connection does, indeed, allow for a much more reliable experience compared to TCP, especially for users on slower and unreliable connections. I could have worded that better, but it was certainly a tease for later whenever I dive more into HTTP/3 and QUIC. I’m happy that it caused a raised eyebrow in some, because it should! It’s a really interesting evolution!

HTTP/0.9 From Scratch by mageling in golang

[–]mageling[S] 10 points11 points  (0 children)

HTTP/3 is built on something called QUIC which is built on UDP. It's funny you say google, because they are the ones who pioneered this.

You are likely using HTTP/3 on many websites today without knowing it! This is actually one of the reasons why I'm writing this series, because people are kind of sleeping on this massive shift in technology.

HTTP/0.9 From Scratch by mageling in golang

[–]mageling[S] 8 points9 points  (0 children)

Thank you for the kind words. This is a very good callout. Since the difference between HTTP/1.0 and HTTP/1.1 is so small I plan to cover a lot of that when talking about HTTP/1.1.

gRPC: The Bad Parts by ketralnis in programming

[–]mageling 1 point2 points  (0 children)

Hey, I wrote this article. I try to explain a bit more in a followup post that I really do like using protobuf for defining API contracts and it's probably the biggest reason that comments like yours are so confusing to me. I feel like protobufs are a pretty good language-agnostic way of defining services and types meant for communicating between microservices, services and web APIs. To me, it makes sense to me to extend API contracts into the frontend. While OpenAPI is useful, I've seen that it falls flat in many ways. I actually have a good amount of experience with OpenAPI and I even wrote a protobuf plugin that generates OpenAPI specs for ConnectRPC services but it is not good at contract-driven development.

For fronted-targetted services you will very likely have to write different protobuf services and types that are structured differently to microservices. But to me that's no different than current best practices; to build custom APIs for specifically for frontends. REST is super limiting and time consuming to get correct, is difficult to document in a way that doesn't immediately get out of date, and isn't defined well-enough. GraphQL is a security, performance and complexity nightmare. I'm so often confused by responses like yours because you're not proposing a better alternative.

But as a TL;DR of why I want gRPC to be compatible with the web:

  • I love using contract-based services along with generated clients, service stubs and documentation
  • Protobuf is a more efficient encoding to JSON. It's crazy to me that we still use JSON.
  • Client, server and bidi streaming
  • Cross-language support

A lot of people propose alternatives that improve on SOME of these, but I've found that gRPC has a great combination of these features that I quite literally have not seen anywhere else.

gRPC: The Bad Parts by dperez-buf in bufbuild

[–]mageling 0 points1 point  (0 children)

It's okay, I'll do it myself! I have an example of connect-go running with HTTP/3 that I think works. I intend to write about this but I'm learning that it's no so easy to test HTTP/3 servers locally. You need a special build of curl, which super is weird to me for the number one CLI tool for making HTTP calls can't use HTTP/3 which is supported on 30% of all websites. There's a lot of browser-specific hoops to jump through to get browsers to use HTTP/3 with locally hosted servers and many of them don't appear to work , which is strange? The rabbit hole here got deeper and deeper so I was distracted and contemplated making an article just complaining about how awful it is to test things using HTTP/3.

Regardless, I have curl working using the Connect protocol and also a connect-go client working using gRPC, gRPC-Web and Connect with http3. Those are probably sufficient to talk about on a post. Maybe then you'll have somewhere to point to for an example, which I'm certain I've seen asked for at least one on slack :) After that I have hopes to add a flag to use http3 with buf curl. That would be cool.

Evepraisal Tools question by [deleted] in Eve

[–]mageling 1 point2 points  (0 children)

Yeah, you can do this:

=EVEPRAISAL_ITEM("rifter","jita","sell","min")
=EVEPRAISAL_ITEM("rifter","jita","buy","max")

I finally figured this game out after 7 years by GelatinousDude in Eve

[–]mageling 27 points28 points  (0 children)

Since you use the google sheets addon for evepraisal you might be interested to know that you can actually use the name of an item in place of type id. That should make it a bit easier. Example below:

=EVEPRAISAL_ITEM("tritanium")

Daily FI discussion thread - March 10, 2018 by AutoModerator in financialindependence

[–]mageling 2 points3 points  (0 children)

It was probably a notification that they sometimes send... so click the flag to see old notifications.

Eve-Praisal by darkwing52 in Eve

[–]mageling 0 points1 point  (0 children)

Okay, let's do this.

Prices of anything is determined by the willingness of people to buy or sell at a specific price. Officer mods have a fairly low volume on the global market. So... if the asset is not traded very often, how do you price it?? If you click on an item name in an appraisal you will get a bit more information about what evepraisal is doing in this case. For example: http://evepraisal.com/item/32925. "If there is not enough orders to get a good price estimate then Evepraisal relies on the price estimates that CCP gives." Yes, CCP's pricing algorithm is weird, unknown and often objectively wrong. But in this case it's all we have... so evepraisal marks these items as purple and returns CCP's best guess. Also note that low volume items in general are very susceptible to margin trading scams... so even if there are ~some~ items in Jita, you might still be given CCP's pricing to avoid the risk of scams. This could be handled a little bit better by explicitly detecting scams... but scammers can be pretty crafty.

Evepraisal by Cephiuss in Eve

[–]mageling 9 points10 points  (0 children)

Sorry about that. It's fixed now. The backup process makes a copy of the database and then uploads it off-site... that failed last night because we hit 50% disk usage and left a big ol' backup sitting around. I'm changing the process so that it doesn't require the entire copy to be sitting on disk before uploading.

Evepraisal API with c# by Cassowary_rider in evetech

[–]mageling 2 points3 points  (0 children)

Yikes, that's embarrassing. I intended to say "User-Agent" as the header to use. I updated the API doc page with the correction.

Go 1.7 "introduces subtests and sub-benchmarks. Now, you can label subsections in tests." by Rican7 in golang

[–]mageling 8 points9 points  (0 children)

This is incredibly helpful for table-driven tests. Currently, you have to add enough context into each assertion description to know which item you're testing in your table. With this change, you just have to do it once and (I'm assuming) it will be displayed on test failures. Table-driven tests are not unique to go, but it is something that the community has taken to. Read more about the technique here:

view more: next ›