3 ms·

Depending on how micro your microservice is and if it really is high volume (not sure what high volume means to you) then I would recommend just stick with the

Depending on how micro your microservice is and if it really is high volume (not sure what high volume means to you) then I would recommend just stick with the standard library to start and grabbing other libs as you need. I wrote a simple internal microservice handling ~400k req/s at peak with no framework and it works great. I can see the appeal of the framework in getting something up and running really fast with one command, but that amount of time in the beginning that it saves is insignificant compared to the long term lifecycle of the project.

psiclops 10y ago
Buffalo just combines a few common web-related packages, such as gorilla mux, together
sjellis 10y ago
I think that it depends on the size and number of your projects. The fact that Go has the equivalent of Sinatra/Flask/Express in the standard library is really cool, but that isn't always what you need. At work we have several dozen applications in service for multiple customers, and almost every single one needs more than that: authn, authz, I8n, DB schema management, a REPL for support work (debugging and data amends), standardized layouts and components from easy switching between projects etc. etc. If we were a larger org with even more applications we would probably benefit from microservices, but actually, Rails-style monoliths are exactly the right fit for us. If we didn't have a framework we'd have to pick a set of components and maintain the glue code to stitch them together, then re-use across products: IOW, we'd end up making a framework if there wasn't one already. At my last job, that actually happened.
cowl 10y ago
We know that standard library is enough But there is always need for a framework if you do the same thing over and over again. The consensus in the GO community seems to be that you create from scratch every-time the same handlers, utilities etc. And practically we have ended up with everyone having their own in-house framework. There is nothing wrong with not wanting to create the same helpers every time or not wanting to have your personal framework. Saying that the standard library is all you need is like saying that you don't need the standard library either, Go's Keywords are all you need.
- volker48 10y ago
  Saying that the standard library is all you need is like saying that you don't need the standard library either, Go's Keywords are all you need. Not really sure what you mean by that. I didn't say the standard lib is all you need I said start with the standard lib and add other libs when and as you need rather than starting with everything in the beginning. In my experience you end up fighting the framework in the long run, but if you like them use them.
deleted 10y ago
[deleted]

psiclops 10y ago

Buffalo just combines a few common web-related packages, such as gorilla mux, together

sjellis 10y ago

I think that it depends on the size and number of your projects. The fact that Go has the equivalent of Sinatra/Flask/Express in the standard library is really cool, but that isn't always what you need. At work we have several dozen applications in service for multiple customers, and almost every single one needs more than that: authn, authz, I8n, DB schema management, a REPL for support work (debugging and data amends), standardized layouts and components from easy switching between projects etc. etc. If we were a larger org with even more applications we would probably benefit from microservices, but actually, Rails-style monoliths are exactly the right fit for us. If we didn't have a framework we'd have to pick a set of components and maintain the glue code to stitch them together, then re-use across products: IOW, we'd end up making a framework if there wasn't one already. At my last job, that actually happened.

cowl 10y ago

We know that standard library is enough But there is always need for a framework if you do the same thing over and over again. The consensus in the GO community seems to be that you create from scratch every-time the same handlers, utilities etc. And practically we have ended up with everyone having their own in-house framework. There is nothing wrong with not wanting to create the same helpers every time or not wanting to have your personal framework. Saying that the standard library is all you need is like saying that you don't need the standard library either, Go's Keywords are all you need.

volker48 10y ago
Saying that the standard library is all you need is like saying that you don't need the standard library either, Go's Keywords are all you need. Not really sure what you mean by that. I didn't say the standard lib is all you need I said start with the standard lib and add other libs when and as you need rather than starting with everything in the beginning. In my experience you end up fighting the framework in the long run, but if you like them use them.

deleted 10y ago

[deleted]