Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

REST Servers in Go: Part 1 – standard library

eli.thegreenplace.net

Post reply on HN
Print view View original

91–100 of 149 posts

Re: REST Servers in Go: Part 1 – standard library

#91

Post by fpopa »

zemo wrote: post #75

usually for stores like this I just do this: type Store interface { GetTask(*Task) error } instead of having "GetTaskByID" and "GetTaskByTag" and whatnot. Then in the caller you just do this: task := store.Task{ID: 5} if err := db.GetTask(&task); err != nil { // wahtever } ^ that gets the task by ID task := store.Task{Tag: "foo"} if err := db.GetTask(&task); err != nil { // wahtever } ^ that gets the task by tag.

This makes sense, did you implement this alongside grpc / protobuf?

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

Re: REST Servers in Go: Part 1 – standard library

#92

Post by ptr »

skjfdoslifjeifj wrote: post #29
ankurpatel wrote: post #23

Looking at such articles makes me feel we are going back in time rather than improving efficiencies for developers to build RESTful server. If you look at Ruby on Rails you can build the server shown here in one min that is scalable and backed with database. 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.

He could build it in Go much faster just by using a couple of additional libraries but he's purposely limiting himself to just the standard library for the purpose of these articles. > 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, bu…

It doesn’t make sense to say Rails etc are “Completely unacceptable” without giving a context. How can it be subjective? Memory is also rather arbitrary, why focus on that and not user friendliness? Or even GPU or cache efficiency? “Breaking changes” might not matter either if what you’re writing is a one-off.

Re: REST Servers in Go: Part 1 – standard library

#93

Post by ptr »

jamra wrote: post #70
jolux wrote: post #24

Earlier quoted context omitted.

DI is a decoupling technique. You might only have two interfaces to begin with, but the rough idea is that writing to interfaces and using IoC allows you to make many changes by adding code without having to change old code.

In Go, you can just use an interface which would make things mockable for testing.

But you still need to send around the object that implements the interface, right? That’s “DI”.

Re: REST Servers in Go: Part 1 – standard library

#94

Post by jamra »

ptr wrote: post #93
jamra wrote: post #70

Earlier quoted context omitted.

In Go, you can just use an interface which would make things mockable for testing.

But you still need to send around the object that implements the interface, right? That’s “DI”.

I don't think you need to do that.

Assuming a web application... You can instantiate the object in your main func and then attach it to the server struct so that it is available in every request. When mocking, you can create a mock server that instantiates mock items that implement the interface. If you need something that is contextual, you attach it to the context. In that case, you can still use mock objects, however, you would have to use a different middleware that handles the mock context objects instead of the normal middleware.

Re: REST Servers in Go: Part 1 – standard library

#95

Post by permille42 »

throwaway894345 wrote: post #78
permille42 wrote: post #67

Earlier quoted context omitted.

The main benefit of constructing objects and tying them together via DI is to allow polymorphic handling of responsibilities. It is more complex than simply "I just make an interface and make everyone agree on that interfere". Everyone agreeing on the interface to use is very unlikely. The underlying data in different implementations will be different. This is something Golang fails terribly at because it doesn't hav…

> The main benefit of constructing objects and tying them together via DI is to allow polymorphic handling of responsibilities. This is already provided by interfaces, as previously discussed. To be clear, dependency injection makes sense; however, dependency injection frameworks don’t make sense to me. > The underlying data in different implementations will be different. This is something Golang fails terribly at be…

Interfaces don't allow polymorphism, because they don't allow you to change the underlying data. The main problem is that you can't ( or at least aren't supposed to ) use any pointers and especially not pointers that point to different data types in different situations.

This sort of behavior is core to polymorphism. It can be done in three ways in Golang ( and probably more too... ):

1. Use serialized messages in channels to do all messages to objects ( disgusting imo... ) It would though at least let one emulate the behavior of message passing / routing languages ( pursuant to original visions of smalltalk etc )

2. Use "unsafe pointers" and just do everything the pay you would in C, deliberately going against the way Golang authors want you to do things.

3. Use reflection and messy if/else in combination with code-generation at compile time. ( this is what a bunch of Golang DI systems do :( )

I don't think you understand polymorphism very well.

I don't give a shit what people are calling DI frameworks these days. I also don't much care for things that simply instantiate a bunch of objects and tie them together. That is only a very elementary variety of metaprogramming.

Essentially, what I am claiming is the Golang is a bad language for metaprogramming, and that in other languages the DI systems they have have become a type of metaprogramming that I think is respectable.

Re: REST Servers in Go: Part 1 – standard library

#96

Post by 0xbkt »

I would probably go with gRPC + grpc-gateway[1] instead. Declaring your services and models in proto files, annotating your services with google.api.http to help grpc-gateway scaffold your HTTP base. Then just implement your services from the interface generated by grpc-go. You can even register your gRPC services to grpc-gateway without actually bringing up a gRPC server. You finally end up having your exact data models injected to your service handlers. Thus, you don't have to repeat yourself preparing the groundwork to call into your services.

This is mostly the way today services in big OSS projects are exposed outside for consumption in a RESTful style. One exception I know of is sourcegraph/sourcegraph.

[1] https://github.com/grpc-ecosystem/grpc-gateway#usage

Re: REST Servers in Go: Part 1 – standard library

#97

Post by friseurtermin »

ankurpatel wrote: post #23

Looking at such articles makes me feel we are going back in time rather than improving efficiencies for developers to build RESTful server. If you look at Ruby on Rails you can build the server shown here in one min that is scalable and backed with database. 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.

That's literally the point of this article:

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

Re: REST Servers in Go: Part 1 – standard library

#99

Post by sagichmal »

permille42 wrote: post #95
throwaway894345 wrote: post #78

Earlier quoted context omitted.

> The main benefit of constructing objects and tying them together via DI is to allow polymorphic handling of responsibilities. This is already provided by interfaces, as previously discussed. To be clear, dependency injection makes sense; however, dependency injection frameworks don’t make sense to me. > The underlying data in different implementations will be different. This is something Golang fails terribly at be…

Interfaces don't allow polymorphism, because they don't allow you to change the underlying data. The main problem is that you can't ( or at least aren't supposed to ) use any pointers and especially not pointers that point to different data types in different situations. This sort of behavior is core to polymorphism. It can be done in three ways in Golang ( and probably more too... ): 1. Use serialized messages in ch…

Interfaces absolutely express a type of polymorphism: any concrete type that satisfies the interface can be used in its place. What makes you think otherwise?

> Essentially, what I am claiming is the Golang is a bad language for metaprogramming

That's definitely true, and an explicit choice. Thank goodness!

Re: REST Servers in Go: Part 1 – standard library

#100

Post by yolo42 »

0xbkt wrote: post #96

I would probably go with gRPC + grpc-gateway[1] instead. Declaring your services and models in proto files, annotating your services with google.api.http to help grpc-gateway scaffold your HTTP base. Then just implement your services from the interface generated by grpc-go. You can even register your gRPC services to grpc-gateway without actually bringing up a gRPC server. You finally end up having your exact data mo…

This is exactly what I started using in my new open source project (not announced yet) and the experience has been amazing. I was wary about it in the beginning but it quickly became clear that this is the easiest and probably the fastest way to get this job done. The community and tooling has come far ahead.
Post reply on HN