Blog Posts

I’ve seen a lot of complicated code in my life. Pretty often, the reason for that complexity was application logic coupled with database logic. Keeping the logic of your application together with your database logic makes your application much more complex, harder to test, and harder to maintain. There is already a proven and simple pattern that solves these issues. This pattern allows you to separate your application logic from database logic.

When I started working in Go, the community did not look favorably on techniques like DDD (Domain-Driven Design) and Clean Architecture. I heard multiple times: “Don’t do Java in Golang!”, “I’ve seen that in Java, please don’t!”. At the time, I already had almost 10 years of experience in PHP and Python. I’d seen too many bad things there. I remember all those “Eight-thousanders” (methods with 8k+ lines of code 😉) and applications that nobody wanted to maintain.

If you’re here for the first time, this post is part of our Business Applications in Go series. Previously, we introduced Wild Workouts, our example application built with modern tools but containing some subtle anti-patterns. We added them on purpose to show common pitfalls and how to avoid them. In this post, we begin refactoring Wild Workouts. Previous articles will give you more context, but reading them isn’t necessary to understand this one.

Welcome to the third and last article covering how to build “Too Modern Go application”. But don’t worry. This doesn’t mean we’re done showing you how to build applications that are easy to develop, maintain, and fun to work with in the long term. It’s actually just the beginning of a bigger series! We intentionally built the current version of the application to make it hard to maintain and develop in the future.

Welcome to the third article in the series on building business-oriented applications in Go! In this series, we show you how to build applications that are easy to develop, maintain, and fun to work with in the long term. In this article, I describe how to build robust internal communication between your services using gRPC. I also cover the extra configuration required to set up authentication and TLS for Cloud Run.

In the previous post, Robert introduced Wild Workouts, our example serverless application. Every week or two, we release new articles about this project, focusing on creating business-oriented applications in Go. In this post, I continue where Robert left off and describe the infrastructure setup. We picked Google Cloud Platform (GCP) as the provider of all infrastructure parts of the project. We use Cloud Run for running Go services, Firestore as the database, Cloud Build as CI/CD, and Firebase for web hosting and authentication.

Welcome to the first article from the series covering how to build business-oriented applications in Go! In this series, we want to show you how to build applications that are easy to develop, maintain, and fun to work with in the long term. This series doesn’t focus too heavily on infrastructure and implementation details. But we need some foundation to build on later.

If you compare MySQL or PostgreSQL with Kafka or RabbitMQ, at first, it seems they are entirely different software. And usually, that’s true, as you would use them for quite different tasks. What they have in common is processing streams of data, and they specialize in specific ways of doing it. While Kafka and RabbitMQ are popular examples of Pub/Subs (also known as message queues or stream processing platforms), I’d like to share some patterns for using SQL databases as Pub/Subs as well.

54 days of work, 12,909 lines of code, 47 Monsters and 42 KFC Twisters later finally it is Watermill v0.3.0! To keep it short, let’s go through the changes. One important thing: at the end of this post there is a 3 question survey. Please take a moment to fill it out, it will help us make Watermill even better.

This time I’d like to touch on a few more advanced topics related to GitLab CI. The common theme here is implementing custom features within your pipeline. Again, most of the tips are specific to GitLab, but some could be easily applied in other CI systems as well. Running integration tests Checking your code with unit tests is usually easy to plug into any CI system.