Is there a spec-first framework for go that also follows a middleware paradigm?
Yes. Please take a look at grpc-gateway. You write your specs as proto files and then get handlers and middlewares to implement the endpoints.
REST Servers in Go: Part 1 – standard library
101–110 of 149 posts
Re: REST Servers in Go: Part 1 – standard library
#102I’ve written a full stack web app with payment integration multi tenancy etc. in plain go. I learned a lot on that journey and what I learned made me value full stack frameworks like rails again. If you want to build something competitive you will need to write lots of things in plain go that you wouldn’t need to bother with when using rails or something similar with sane conventions.
+1 on that. I recently had to write a small web app that has to do some data processing and interact with database on request. We chose go for this because it was faster than php for this one particular data intensive task. I liked working with go, but frameworks like rails, laravel or django have a huge advantage in terms of developer productivity when compared to go.
Re: REST Servers in Go: Part 1 – standard library
#103Earlier quoted context omitted.
What you're pointing to is the need for better abstractions and Go is not the language for that (it will be more-so when generics arrive). 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 bi…
Are you talking about Haskell? That’s a hard sell.
Rust I think, there was a blog post on how it is problematic as a web dev platform as opposed to lower level tasks (where it shines).
Re: REST Servers in Go: Part 1 – standard library
#104Earlier quoted context omitted.
I've never understood the value proposition of a DI framework. Why would I want one when I can initialize my objects in main()? Is XML or JSON or whatever really that much more pleasant than wiring together Go objects?
I'm with you on this. Dependency injection seems to me to replicate some of the features of interfaces while introducing complexity because the injection is indirect -- instead of having code that initializes a different object, it all happens dynamically during runtime using reflection. An antipattern as far as I'm concerned. It seems to achieve little or no gain at a very high cost.
It doesn't have to happen at runtime. For instance in Java you have annotation processors which generate the boilerplate for you (in DI space I'm only aware of Dagger 2 that does it). It's a bit inconvenient but you can easily audit what's going on. That being said I somehow doubt a similar tool is used with go.
Re: REST Servers in Go: Part 1 – standard library
#105Earlier quoted context omitted.
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!
There is no "either-or" data type in Golang. That's why.
It can only be accomplished by inefficient functional hackery.
In C, you just make a struct, have a type present in the struct, and then cast the struct pointer to extended object types to gain additional functionality.
In this way you can easily accomplish all sorts of fun things like inheritance. Message passing type designs can easily be accomplished also in C.
In Golang? Well... no. You are essentially forbidden from doing any simple casting or extension. You are essentially stuck with hardcoding the crap out of everything or making your own vcall like system build out of Golang types... which you can't really use in the way you want unless you use reflection.
What I can't understand is why anything thinks that Golang does support polymorphism. They admit it themselves. They are working on it. Only the new alpha test versions have a solution for it. The current released version is not polymorphism no matter how much you want to fucking label it that way.
You can't just go "hey it supports a little bit of what everyone knows as polymorphism". That's like saying alcohol is like orange juice because they are both bitter in some cases.
Re: REST Servers in Go: Part 1 – standard library
#106usually 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.
The downside to this approach is that you're unable to know what fields you can use in your query without reading the GetTask function, and changes to the GetTask function can silently break all callers, since it's now a runtime error.
Re: REST Servers in Go: Part 1 – standard library
#107I'm an API developer working with Python and Django. I did dabble with Golang for quite some time, but I just can't seem to justify the effort (in terms of lines of codes and static typing) of writing a ReST API with Go when I can build a similar one with Django and co (DRF, Swagger, etc). Can someone chime in? There must be an obvious advantage that I might be missing.
Every time I use DRF, I end up making some huge and horrible abstraction that I hate after its creation, like Dr. Frankenstein. So far, this has not happened to me with Go. I don’t know if the problem is just me or what, but I find Go easier to just define a data type, grab some JSON from the request, send some other JSON back without making myself crazy.
Interesting. Can you give an example of a "huge and horrible" abstraction that stems from your usage of DRF?
I remember having the same sentiment a few months back, but investing a considerable amount of time planning the structure of serializers and sticking to DRF's patterns did reduce the amount of "fighting" that I need to do to make my API work as expected.
Re: REST Servers in Go: Part 1 – standard library
#108I 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…
Have you looked into goa design[1]? You define your services with a contract via their DSL and it generates all code for you as well; has some nice validation options out of the box.
- similar to grpc gateway you just need to conform to the generated code’s service interface.
I believe it supports, http, websocket and grpc.
Re: REST Servers in Go: Part 1 – standard library
#109Earlier quoted context omitted.
I suspect you will see a lot more of rails (and rails like frameworks) being used just because they are so simple to use and beginners can use it without understanding too deeply. Having more people who can understand/build/fix will always win out, and rails is what most coding bootcamp teach. So there’s just going to be too many folks who will choose rails over more suitable languages. I’m not super convinced that’s…
Putting aside that your post kinda reads as if it were written ten years ago (most bootcamps do not teach Rails and it's vanishingly unlikely it'll reach the position it was ten years ago: cf JavaScript), I take some issue with > beginners can use it without understanding too deeply...So there’s just going to be too many folks who will choose rails over more suitable languages. It's not about "beginners" or "more sui…
A lot of bootcamps in Europe are still teaching RoR. (I doubt "most", but I also doubt "most" for any single language once you include JS for front-end/"full stack", Java for "back end", and Python for ML/DS focus.)
Bootcamps sell themselves based on employment placement, not cool technology or deep knowledge. In this regard RoR, Java, and even PHP are going to be bootcamp milch cows for years to come.
Re: REST Servers in Go: Part 1 – standard library
#110Earlier quoted context omitted.
> Many say, "Pass the database connection in the params." ... How can you write tests for logic without having to instantiate a DB? You define and use an interface to model the DB, and use that as the mock point. Basic stuff.
I aware of making an interface for that. I advocate that. What I see people on r/golang saying, and even in HN, is to just pass the DB connection either explicitly or in the context. I hate this. It makes things bound to DBs.
A "DB connection" in Go is already several layers of abstraction. You could have real production connected to your postgres, integration tests connected to a sqlite file, and unit / functional tests via sqlmock.
Everything is still 'bound to DBs' but that's because your program needs a source of data. Faking a second data source other than the DB via a higher-level shared interface is just inviting integration failures.