gRPC feels to me like a violation/break in expectations of how the layers of abstraction are supposed to work -- gRPC works over HTTP/2, and it's weird that it translates a lower level (HTTP/1) at a higher level (gRPC) to re-encode it into something at the lower level. An appropriately robust protocol would simply support both lower levels of abstraction if it wanted to (and they were widespread in daily use), right?

The only places I feel like I see this kind of layer violations are in lower level networking and it generally just makes everything worse and more complicated there. Of course, I know that gRPC + gateway is actually not a huge deal in practice -- you've got reverse proxies like envoy that will do it for you automatically[0], but it just... doesn't sit great. The benefits of gRPC are not to be sneezed at (better performance, strict typing at the protocol level, schema enforcement, bidirectional streaming, etc), but it feels like it could have accomplished a lot of those goals without throwing out HTTP/1.1 completely (and then that machinery could have been reused to support HTTP/3).

[0]: https://www.envoyproxy.io/docs/envoy/latest/configuration/ht...

You only get a certain number of complexity tokens and IMO it's not worth spending any here.

I believe it supports, http, websocket and grpc.

[1]https://github.com/goadesign/goa

I've had this a few times, most recently with "how do I add this data file to my binary". At least that one made it to master now, and will be in 1.16!

Another gripe is the lack of a proper parallel safe map (no, map[interface{}]interface{} like sync.Map is just not acceptable) which would be a godsend and should honestly just be the normal map implementation. Maybe eventually with generics... (This is more of a language gripe than a stdlib gripe, though, and I'm sure that once generics come out we'll see a sync.Map that doesn't use interface {})

> I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic.

If you don't care that's fine, but there are lots of us that do. This is subjective, but I find the memory use and overall performance of Rails/Django/Spring Boot applications to be completely unacceptable and there are far too many breaking changes.

There is a language that has faster-than-go speed and better abstractions, but HN seems to be somewhat decided on whether they think it's awesome or terrible, and there was recently an blog post on front-page about how it was bad for APIs (which I heavily disagree with but I am biased so I opted not to comment on).

Go definitely does have some other web frameworks that make work like this simpler, but on the other hand, people sometimes shy away from those because the stdlib is more universal.

It's not about whether you expect Google-like traffic, but about whether you expect a Google-like ratio of traffic/compute to capacity. My day job doesn't deal with "Google-like" traffic (maybe one Google product's worth of traffic), but we also only have about 10 servers to ingest what we do get. My current side project I expect to deal with even fewer orders of magnitude but I also want to be able to run it on a single server to keep costs and operational overhead low.

> There are strong opinions both for and against using frameworks. My goal in these posts is to examine the issue objectively from several angles.

   store.Lock()
   store.WriteKey("foo", "bar")
   x := store.ReadKey("foo")
   store.Unlock()
   // x is always "bar"

   store.Lock()
   store.WriteKey("foo", "bar")
   store.Unlock()

   store.Lock()
   x := store.ReadKey("foo")
   store.Unlock()
   // x could be whatever another goroutine set "foo" to, not the "bar" that you just wrote.

   var x string
   err := db.DoTx(func(tx *Tx) {
     tx.Write("foo", "bar")
     x = tx.Read("foo")
   })
   if err != nil { ... }
   // what x is depends on the details of your database; maybe you're running at "read uncommitted", maybe you're running at "serializable".

The act of writing these kind of systems is IMHO, somehow, liberating.

Compiled code is also significantly faster in many cases.

2. execution speed - Django's ORM comes to mind

3. concurrency

That being said there are alot of great features with python web frameworks that come out of the box. You need to a lightweight project like gin/echo or something to get these features. Naked net/http is sorta like the 'erector set' of web frameworks.

I'm curios about the way you handled zero values, field masks could be a solution, but I think it would get bloaty.

I don't disagree that it's more practical, initially, as you've described it. However, I think it's important to point out the tradeoff rather than presenting it as purely more efficient. I've seen this approach result in poor separation of concerns and bloated use cases (`DoTheActualThing`) which become tedious to refactor, albeit in other languages.

One predictable side effect of the above, if you're working with junior engineers, is that they are likely going to write tests for the application logic with a dependency on the request / response as inputs, and asserting on status codes etc. I shudder to think how many lines of code I've read dedicated to mocking req/res that were never needed in the first place.

Just want to address (1) quickly. As you've mentioned at the end of the parenthesized note, the reason I did not use `defer` here is to avoid the lock staying across the rest of the handler. I wanted to confine it to the datastore interaction.

Thinking more about this now and having read the comments, I'm considering to just hide the lock in TaskStore and avoid all these explicit locks/unlocks in handlers; it seems like it will avoid some confusion for folks reading the example (as well as quite a few lines of code!), and my goal here is really the HTTP server logic. I prefer to deflect any attention from TaskStore in this series of posts.

    type HTTPError interface {
        GetHTTPCode() int
    }
    func ServeHTTP(w http.ResponseWriter, req \*http.Request) {
        result, err := DoTheActualThing()
        if err != nil {
            statusCode := http.StatusInternalServerError
            if httpError, ok := err.(HTTPError); ok {
                statusCode = httpError.GetHTTPCode()
            }
            http.Error(w, ..., statusCode)
            return
        }
        w.Header().Set("content-type", "application/json")
        w.WriteHeader(http.StatusOK)
        w.Write(result)
    }

Interesting, thanks. But isn't panicking the end of your program anyway? Could you provide another example where no using defer causes problems?

If you have independent, different elements in that API, you break them out into separate "servers" but still register the endpoints on the same HTTP handler.

I know that people don't like external libraries too much, but I'd like to plug my own here. You declare your API in OpenAPI 3.0 (aka, Swagger) and it generates your server and models for you, so all you need to do is write the business logic. (https://github.com/deepmap/oapi-codegen)