Go Micro – A Go microservices development framework(go-micro.dev) |
Go Micro – A Go microservices development framework(go-micro.dev) |
I believe most cloud providers don't support multicast, meaning mDNS would not work there. It's also quite slow and/or very chatty in large networks.
Looks there is support for other service discovery mechanisms via plugins, though.
For wiw multicast/mDNS works fine on top of ZeroTier.
Although, if the underlying network doesn't, I assume you get a lot of overhead (ie: it probably wouldn't be very beneficial to try and share a video stream via multicast on top of ZeroTier on top of a network without multicast support).
Would it work with Flannel/Calico, etc? Inefficient, but probably okay since it would be just service resolution.
Edit: Looks like no for Calico, Yes for recent Flannel, but Weave Works is probably a better choice, designed to support it from the start.
> PubSub is built in as a first class citizen for asynchronous communication and event driven architectures.
Would be interested to see how this is implemented and what it’s consistency and reliability dynamics are.
I might agree, but it's not the only core pattern.
What if one needs (distributed) transactions? The fact that pub/sub is advertised as a prominent feature makes me think that asynchronous models are preferred, at least in design and philosophy of the framework.
"the Go _community_ is very anti-framework and pro-library"
There is nothing about the language, which is general purpose, that makes it anti-anything really.
(I know that the absence of generics is temporary)
Also, lots of dependency injection patterns everywhere, which is actually a great way when dealing with larger projects.
Can you elaborate on this? I'm not super-familiar with Go but I haven't yet seen anything that suggests it's a poor language choice for frameworks.
This also makes me curious about your definitions of "framework" and "library". Frameworks are just curated collection of libraries that work well in harmony, plus conventions for handling common patterns. No?
Frameworks are often architecture-first and functionality-second, which is vice-versa for libraries. Instead of learning to “do X” you are now learning to “do X using Y”, and that Y often prevents you from knowing and using the full potential of X.
Also, when I say that Go is idiomatically anti-framework, I mean that most idiomatic Go code I've seen, in the stdlib and in the code of the prolific gophers, tends to shun the structure of frameworks. It's in the “Zeitgeist”, if you will. In fact, in my experience most frameworks are written by people who come to Go from other languages and try to take their habits with them. A good example of that is the Martini HTTP framework, the author of which later acknowledged that he was trying to “write Go as if it were another language” and started creating stdlib-compatible middlewares instead.
[1] https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/
It's not that you can't do it, it's just that the entire ecosystem and excellent stdlib encourages you to develop your own code, and makes it very easy to refactor, catching most non-logical bugs at compile time if there are any.
In Go all your code is explicit about what its doing. I dont know of any guru annotation witchcraft in Go outside of people doing preprocessing which is avoided by the language by design.
You can open any source in Go and usually just figure out whats what and where it comes from.
But I think people are more concerned about bigger and more complicated frameworks.
Haven't heard that before but I really like it!
Same thing happened to JavaScript, and now the language is ruined, sadly. It's now a crappier, but more widely deployed Ruby.
It's not so much writing the code, that's the easy part, but reading and tweaking it later and not go hmm..
There something to smaller, simpler and btw, nobody is saying golang is currently a good fit for all kinds of projects, but the core ideas are easy for new developers and interesting for experienced ones.
Composing smaller components into a bigger system would be a great fit, and it could also be used for a monolith, though golang really shines most where code is segmented into clever little independent features. This may require some extra design and systems thinking.
1. server side templating of html pages
2. database access/migration
3. asset packing/versioning
5. css compliation/ asset pipeline
6. authetication/authorization support
I assume you are implying these are not quick in golang ? I think it proves my point that assemble everything yourself is a silly ideology when applied generically to all things.