7 ms·

How to ship production-grade Go

158 points by cpeterso 10y ago

tyingq 10y ago
I'd add another, something like "Be Aware of the Ramifications of Partial HTTP/S Implementations". Because it's so easy to expose http/https in golang, I see a fair amount of code that takes the easy path of handling GETS and not doing much else. No support for HEAD, or compression, proper mime types in Content-type, or lacking Cache-Control headers, Etags, 304 responses, etc. Go can do all these, of course, but I see them missing often. I've seen, for example, blogs, that (probably not on purpose) defeat browser caching. Not great for performance, or your egress bill.
- jdc0589 10y ago
  pretty common problem with any of the newer languages or environments that have great native stdlib support for http/s servers. A bare bones http/s server is so easy to spin up with nothing other than the stdlib, people who are used to using full stack frameworks forget about all the stuff it did for them behind the scenes.
- niftich 10y ago
  I realize that much of the Go community is hesitant about the sort of third-party code that intentionally constraints the problem-space by restricting choice and then calls your code at a few well-defined points; preferring to call out to libraries instead (vs. the other way around); but what solutions, if any, are widely utilized to avoid the above situation?
  - tyingq 10y ago
    Guessing most people that care about this would have some sort of "minimum http header/feature" test that runs each build.
  - omginternets 10y ago
    I quite like http://echo.labstack.com http://echo.labstack.com I quite like it because you can access the net/http constructs (ResponseWriter, Request, etc) if you really need them, but in most cases it removes a lot of boilerplate.
- xienze 10y ago
  One thing about Go developers that sort of baffles me is their desire to handle HTTPS. Yes, Go makes it easy to do so, but really you should be sticking your Go app behind Apache, NGiNX, etc. instead of putting it directly on the Internet for reasons you've listed and more.
  - jerf 10y ago
    Putting your Go webserver behind nginx will fix, by my count, only one of those, compression. Maybe 10% of a point for faking up HEAD support, but nginx converting a GET into a HEAD by simply dropping the body isn't very compelling. Putting your webserver behind nginx just to do it isn't very compelling. To get a win you really need to be doing something in nginx beyond merely just proxying. That's not really a Go-specific complaint, that's a complaint about a loooot of implementations of web stuff. Edit: Compression is less important than it sounds, too; for security reasons, you shouldn't compress dynamic content going over HTTPS, so nginx doing the compression only helps for HTTP, and it's only a handful of lines of code to implement it in your Go layer too so it's not a huge win. If nginx did fix a lot of those problems without having to think about it, it would be helpful, but it doesn't.
    - sofaofthedamned 10y ago
      Quite right. Compression over TLS, although useful, is frowned upon for the reasons you state. I'm normally the sort of guy who puts everything behind HAProxy, I may still do that for convenience (certs in the same place etc) but imagine moving to a point where I put the Go programs behind, but in TCP mode.
    - deleted 10y ago
      [deleted]
  - zacmps 10y ago
    Why do you think go would be run behind a reverse proxy for TLS?
    - xienze 10y ago
falcolas 10y ago
So, the same way you ship any code: robust against errors, well tested, well instrumented. Useless, ad ridden article, frankly.
- jasode 10y ago
  >same way you ship any code Well, the article is specifically about Go instead of generalized universal advice so she put concrete syntax examples using the Go language (vs "any code" in any language). There are examples to wrap errors, report panics, and using structured logs. The specificity of real code snippets is useful. >Useless, ad ridden article, frankly. I'm guessing this is the real root of your complaint. In my view, the ads are tucked away to the side, not obnoxious, and are simply related to other O'Reilly offerings. The actual programming advice in the article looks like it has value and I think you're being unfairly harsh.
  - Loic 10y ago
    On mobile (my phone) the ads are within the flow of the article, which at first confused me because each ad is nearly a full screen. On desktop it is way better.
  - falcolas 10y ago
    The advice may have Go examples, but is still very generic advice. It's also not really about shipping Go programs, it's about general hardening of programs. And to mirror a sibling comment, on mobile the ads are interspersed every couple of paragraphs, making it very hard to follow the flow of the article. Unfairly harsh? Clickbait headline, generic advice (with just enough Go examples to "justify" the title), aggressive styling to hide ads in the flow of the rest of the article... I disagree. I'm perhaps not being harsh enough.
    - NiceGuy_Ty 10y ago
      I just scrolled through on mobile (materialistic app) and only saw one ad. Seems to me like you're being hyperbolic.
tedsuo 10y ago
Oh god, there is some terrible advice in that article. 1. Don’t wrap errors, log. Errors have two purposes - control flow for your application, and information for the developer and operator. If you are already logging the flow of your program, there is no need to wrap an error and create a call stack - you already have the call stack. If you cannot follow the control flow from your logs, you need to improve your logging, because you will also need to debug production problems that do not produce a literal error object. And if you want more causality than you can get out of your logging, consider upgrading from logging to tracing. I contribute to http://opentracing.io http://opentracing.io so naturally that’s the tracing API I would suggest you look at. 2. Do not do anything with panics except recover from them or exit. If you have a panic that you cannot recover from (and in general, that should be all of them), then it means your application is in a unknowable state. While Go is not as unsafe as C, any and all state in your program could be bad, and it is completely unclear what is still working and what is not. Nothing you do at this point is safe. For the love of god, do not hang your application and prevent it from exiting by trying to send a Slack message. Your goal should be to restart your program from a fresh clean state as quickly as possible, not to tie it up on the way out. Let the program exit and have an external monitoring program, whose state is NOT corrupted because its in a separate process, do all of the triage and reporting.
- outworlder 10y ago
  For 2, I stopped reading and went straight for the comments to see if my logic was flawed. The process is "panicking", but it is still reliable enough to post a message to Slack? Even writing a log entry might be too much, depending on what exactly the failure was.
  - dualogy 10y ago
    > The process is "panicking", but it is still reliable enough to post a message to Slack? Even writing a log entry Well.. most likely yes. If I invoke panic, all state is exactly as it was just prior to that statement. And even if not, it's not gonna "launch the missiles" if that slack post or log-write fails now, is it? > Even writing a log entry might be too much "Too much", how? Either it succeeds in which case it'll help you, or it won't which has the same result as not attempting it in the first place: no log entry..
rebase 10y ago
The author is actually a fairly junior developer (graduated in 2013), but I must hand it to them for taking the initiative of getting published by such a large entity (oreilly media) and locking down speaking engagements (GopherCon) so early in their career! They have a bright future even if this article does not contain the most accurate advice.
- AvenueIngres 10y ago
  Meh. I don't want to take it away from the author, it certainly shows they're motivated, but I have a hard time this isn't a textbook example of how publishers/conference organisers are trying hard to get "underrepresented" token demographics in cover. Even if it is to perform trivial talks (a glorified "intro to channels in golang"... really!?) or write platitudes like said article. They're clearly underqualified to distillate advice to anyone, maybe interns/students could benefit from this though.
shusson 10y ago
> Test more than you think you should I think this is a dangerous way of thinking. Writing more tests does not necessarily improve code quality or decrease the risk of defects. A focus on coverage can lead to bloated tests which end up taking more time to maintain than the original code.
mbrumlow 10y ago
Here she talks about it on a pod cast if you want to hear her talk about it a bit. https://dev.to/gotime/42-race-detection-firmware-and-productiongrade-go-with-kavya-joshi https://dev.to/gotime/42-race-detection-firmware-and-product...

158 points by cpeterso 10y ago

I'd add another, something like "Be Aware of the Ramifications of Partial HTTP/S Implementations". Because it's so easy to expose http/https in golang, I see a fair amount of code that takes the easy path of handling GETS and not doing much else. No support for HEAD, or compression, proper mime types in Content-type, or lacking Cache-Control headers, Etags, 304 responses, etc. Go can do all these, of course, but I see them missing often. I've seen, for example, blogs, that (probably not on purpose) defeat browser caching. Not great for performance, or your egress bill.

jdc0589 10y ago
pretty common problem with any of the newer languages or environments that have great native stdlib support for http/s servers. A bare bones http/s server is so easy to spin up with nothing other than the stdlib, people who are used to using full stack frameworks forget about all the stuff it did for them behind the scenes.
niftich 10y ago
I realize that much of the Go community is hesitant about the sort of third-party code that intentionally constraints the problem-space by restricting choice and then calls your code at a few well-defined points; preferring to call out to libraries instead (vs. the other way around); but what solutions, if any, are widely utilized to avoid the above situation?
- tyingq 10y ago
  Guessing most people that care about this would have some sort of "minimum http header/feature" test that runs each build.
- omginternets 10y ago
  I quite like http://echo.labstack.com http://echo.labstack.com I quite like it because you can access the net/http constructs (ResponseWriter, Request, etc) if you really need them, but in most cases it removes a lot of boilerplate.
xienze 10y ago
One thing about Go developers that sort of baffles me is their desire to handle HTTPS. Yes, Go makes it easy to do so, but really you should be sticking your Go app behind Apache, NGiNX, etc. instead of putting it directly on the Internet for reasons you've listed and more.
- jerf 10y ago
  Putting your Go webserver behind nginx will fix, by my count, only one of those, compression. Maybe 10% of a point for faking up HEAD support, but nginx converting a GET into a HEAD by simply dropping the body isn't very compelling. Putting your webserver behind nginx just to do it isn't very compelling. To get a win you really need to be doing something in nginx beyond merely just proxying. That's not really a Go-specific complaint, that's a complaint about a loooot of implementations of web stuff. Edit: Compression is less important than it sounds, too; for security reasons, you shouldn't compress dynamic content going over HTTPS, so nginx doing the compression only helps for HTTP, and it's only a handful of lines of code to implement it in your Go layer too so it's not a huge win. If nginx did fix a lot of those problems without having to think about it, it would be helpful, but it doesn't.
  - sofaofthedamned 10y ago
    Quite right. Compression over TLS, although useful, is frowned upon for the reasons you state. I'm normally the sort of guy who puts everything behind HAProxy, I may still do that for convenience (certs in the same place etc) but imagine moving to a point where I put the Go programs behind, but in TCP mode.
  - deleted 10y ago
    [deleted]
- zacmps 10y ago
  Why do you think go would be run behind a reverse proxy for TLS?
  - xienze 10y ago

falcolas 10y ago

So, the same way you ship any code: robust against errors, well tested, well instrumented. Useless, ad ridden article, frankly.

jasode 10y ago
>same way you ship any code Well, the article is specifically about Go instead of generalized universal advice so she put concrete syntax examples using the Go language (vs "any code" in any language). There are examples to wrap errors, report panics, and using structured logs. The specificity of real code snippets is useful. >Useless, ad ridden article, frankly. I'm guessing this is the real root of your complaint. In my view, the ads are tucked away to the side, not obnoxious, and are simply related to other O'Reilly offerings. The actual programming advice in the article looks like it has value and I think you're being unfairly harsh.
- Loic 10y ago
  On mobile (my phone) the ads are within the flow of the article, which at first confused me because each ad is nearly a full screen. On desktop it is way better.
- falcolas 10y ago
  The advice may have Go examples, but is still very generic advice. It's also not really about shipping Go programs, it's about general hardening of programs. And to mirror a sibling comment, on mobile the ads are interspersed every couple of paragraphs, making it very hard to follow the flow of the article. Unfairly harsh? Clickbait headline, generic advice (with just enough Go examples to "justify" the title), aggressive styling to hide ads in the flow of the rest of the article... I disagree. I'm perhaps not being harsh enough.
  - NiceGuy_Ty 10y ago
    I just scrolled through on mobile (materialistic app) and only saw one ad. Seems to me like you're being hyperbolic.

tedsuo 10y ago

Oh god, there is some terrible advice in that article. 1. Don’t wrap errors, log. Errors have two purposes - control flow for your application, and information for the developer and operator. If you are already logging the flow of your program, there is no need to wrap an error and create a call stack - you already have the call stack. If you cannot follow the control flow from your logs, you need to improve your logging, because you will also need to debug production problems that do not produce a literal error object. And if you want more causality than you can get out of your logging, consider upgrading from logging to tracing. I contribute to http://opentracing.io http://opentracing.io so naturally that’s the tracing API I would suggest you look at. 2. Do not do anything with panics except recover from them or exit. If you have a panic that you cannot recover from (and in general, that should be all of them), then it means your application is in a unknowable state. While Go is not as unsafe as C, any and all state in your program could be bad, and it is completely unclear what is still working and what is not. Nothing you do at this point is safe. For the love of god, do not hang your application and prevent it from exiting by trying to send a Slack message. Your goal should be to restart your program from a fresh clean state as quickly as possible, not to tie it up on the way out. Let the program exit and have an external monitoring program, whose state is NOT corrupted because its in a separate process, do all of the triage and reporting.

outworlder 10y ago
For 2, I stopped reading and went straight for the comments to see if my logic was flawed. The process is "panicking", but it is still reliable enough to post a message to Slack? Even writing a log entry might be too much, depending on what exactly the failure was.
- dualogy 10y ago
  > The process is "panicking", but it is still reliable enough to post a message to Slack? Even writing a log entry Well.. most likely yes. If I invoke panic, all state is exactly as it was just prior to that statement. And even if not, it's not gonna "launch the missiles" if that slack post or log-write fails now, is it? > Even writing a log entry might be too much "Too much", how? Either it succeeds in which case it'll help you, or it won't which has the same result as not attempting it in the first place: no log entry..

rebase 10y ago

The author is actually a fairly junior developer (graduated in 2013), but I must hand it to them for taking the initiative of getting published by such a large entity (oreilly media) and locking down speaking engagements (GopherCon) so early in their career! They have a bright future even if this article does not contain the most accurate advice.

AvenueIngres 10y ago
Meh. I don't want to take it away from the author, it certainly shows they're motivated, but I have a hard time this isn't a textbook example of how publishers/conference organisers are trying hard to get "underrepresented" token demographics in cover. Even if it is to perform trivial talks (a glorified "intro to channels in golang"... really!?) or write platitudes like said article. They're clearly underqualified to distillate advice to anyone, maybe interns/students could benefit from this though.

shusson 10y ago

> Test more than you think you should I think this is a dangerous way of thinking. Writing more tests does not necessarily improve code quality or decrease the risk of defects. A focus on coverage can lead to bloated tests which end up taking more time to maintain than the original code.

mbrumlow 10y ago

Here she talks about it on a pod cast if you want to hear her talk about it a bit. https://dev.to/gotime/42-race-detection-firmware-and-productiongrade-go-with-kavya-joshi https://dev.to/gotime/42-race-detection-firmware-and-product...