11–20 of 149 posts
err = json.NewEncoder(w).Encode(&task)
-CORS support. Deploy this to a non-local domain and try to reach it from a web browser and it will fail. I like https://github.com/rs/cors. I had rolled my own but then moved to that library.
- input validation. I like go-playground/validator.
The other big issue is the locking by hand around the task store. In reality usually there would be a database to handle concurrent read/writes. I use SQLite in production. I know this is just a demo and you want to use just stdlib, but serializing all data access is sort of unacceptable as a solution in a concurrent language like Go. When I'm not handling concurrency with SQLite I like to implement The actor pattern, having a persistent goroutine listen and respond to "taskstore" requests via channels.
Good introduction. A few thoughts: 1) Be careful with locks in the form "x.Lock(); x.DoSomething(); x.Unlock()". If DoSomething panics, you will still be holding the lock, and that's pretty much the end of your program. ("x.Lock(); defer x.Unlock(); x.DoSomething()" avoids this problem, but obviously in the non-panic case, the lock is released at a different time than in this implementation. Additional tweaking is re…
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.
Also, one thing I'm still waiting for is a decent non-complex di that works using go generate. I'm aware of google's wire (?) But I've looked at it multiple times and I still struggle to understand it.
Is there a reason to prevent concurrent reads? Seems rather .. Silly considering the db should handle all that stuff. Also, one thing I'm still waiting for is a decent non-complex di that works using go generate. I'm aware of google's wire (?) But I've looked at it multiple times and I still struggle to understand it.
Is there a reason to prevent concurrent reads? Seems rather .. Silly considering the db should handle all that stuff. Also, one thing I'm still waiting for is a decent non-complex di that works using go generate. I'm aware of google's wire (?) But I've looked at it multiple times and I still struggle to understand it.
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?
Is there a reason to prevent concurrent reads? Seems rather .. Silly considering the db should handle all that stuff. Also, one thing I'm still waiting for is a decent non-complex di that works using go generate. I'm aware of google's wire (?) But I've looked at it multiple times and I still struggle to understand it.
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?
Mocking objects for testing purposes and swapping them for the real objects is also something commonly done that is helpful.
There is no "real" DI for Golang as far as I've seen. The only DI I've seen that effectively do the sort of thing I am describing are for Java.
Nice demo. A few things you could add to make this more realistic to something that gets shipped: -CORS support. Deploy this to a non-local domain and try to reach it from a web browser and it will fail. I like https://github.com/rs/cors . I had rolled my own but then moved to that library. - input validation. I like go-playground/validator. The other big issue is the locking by hand around the task store. In reality…
Earlier 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?
The purpose of DI is to allow the use of a DSL to instantiate and connect objects, with configuration for those objects embedded into the DSL so that the setup and the way things work can be changed quickly without altering code. Mocking objects for testing purposes and swapping them for the real objects is also something commonly done that is helpful. There is no "real" DI for Golang as far as I've seen. The only DI…
Can someone chime in? There must be an obvious advantage that I might be missing.