Not sure I agree with most of this, but it's interesting to see another's approach to dealing with complexity.
The article correctly identifies complexity as the biggest problem with writing complex long-lived web applications, but then presents a series of ad-hoc solutions to specific problems (problems caused by the structure they have chosen) as the best answer. It would probably be better titled 'Things I learned writing go' or something similar, rather than attempting to frame different decisions trade/offs as anti-patterns.
To take one example, having one user model is good in that it is easier to maintain and less complex to think about, but the author advocates having a write model and an api model - in some circumstances that might be useful (where there are many private fields which must never leak to the view or require processing before presentation), but most of the time it's overkill and needless complexity.
The article correctly identifies complexity as the biggest problem with writing complex long-lived web applications, but then presents a series of ad-hoc solutions to specific problems (problems caused by the structure they have chosen) as the best answer. It would probably be better titled 'Things I learned writing go' or something similar, rather than attempting to frame different decisions trade/offs as anti-patterns.
To take one example, having one user model is good in that it is easier to maintain and less complex to think about, but the author advocates having a write model and an api model - in some circumstances that might be useful (where there are many private fields which must never leak to the view or require processing before presentation), but most of the time it's overkill and needless complexity.
Super cool, these guys make great articles about making clean web applications in Go