Bryan Ray

I see a lot of the benefit of Go. It’s “simple.” The stdlib is great. However, nothing ever seems to scratch the surface more than “look … I can start a web server using the stdlib and serve a single endpoint. It’s great!” Finding a good article or book that describes how to organize your (web) application seems extremely rare.

Any developer who has built something of substantial size (small to medium), knows that there are some things that you typically don’t want to do when building software. I’m trying to find out if these are “bad” habits that I’ve learned? Or perhaps I need to think differently in Go?

Google Chrome is a very popular web browser used by many web developers today. With a very quick release cycle and a powerful set of developer features turned the browser into a must have tool. Most developers are more than likely familiar with many of Chrome’s features like live-editing CSS, using the basic DevTools and the basics of the debugger. However, in this post, we’ll be going over some great tips and tricks that may help improve your workflow even more.

We’ll be taking a look at the microservice architecture. We’ll look at some of the problems microservices can cause. And also some of the bigger architectural issues that can occur in the future. We’ll also take a brief stroll through Domain Driven Design (DDD) and some possible anti-patterns that can come from microservices. So let’s get started … How big should a microservice be? Microservices are typically described in terms of the single responsibility principle as they should just do one thing really well.

Go has been a good experience. It is generally a very nice language, once you get used to it. I’d recommend that anyone curious about Golang to give it a try; in particular, you should really commit to persisting through the first 2 weeks, where you will most likely find some of Golang’s ideologies challenging at first (like “why is every line an if statement?”) package main import "fmt" func main() { fmt.