Three Dots Labs

In the previous post, Robert introduced Wild Workouts, our example serverless application. Every week or two, we will release new articles related to 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. The idea of this series is to not focus too much on infrastructure and implementation details. But we need to have some base on which we can build 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. CQRS component One of the most important parts of the v0.

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. It usually is as simple as running one command built in your language’s toolset.

This post is a quick how-to for starting a new project in Go. It features: Hot code reloading Running multiple Docker containers with Docker Compose Using Go Modules for managing dependencies It’s best to show the above working together with an example project. We’re going to set up two separate services communicating with messages over NATS. The first one will receive messages on an HTTP endpoint and then publish them to a NATS topic.

Let me start by thanking all contributors for feedback on Watermill - it drives us to add new features. Thanks! It’s been almost a month since the initial release of Watermill. However, it’s just the beginning and we are still working hard to ship new features. What is new in Watermill 0.2? Documentation - watermill.io Godoc is great. However, it’s functionality is sometimes too limited to express more complicated documentation.

In the previous post I showed how to keep all the scripts used in the CI in one repository. Let’s see what more advanced scripts you could put in there. This time I’d like to show how to add automatic versioning to your pipeline. You will also see how to push commits to your repository within the CI jobs. But first, let’s start with some background. Picking your flow One of the things I love about GitLab is its flexibility for setting up your own CI workflow.

Watermill is a Go library for working efficiently with message streams. It is intended as a library for building event-driven applications, enabling event sourcing, CQRS, RPC over messages, sagas. Why? Lack of standard messaging library There are many third party and standard library tools which help to implement standardized RPC or HTTP communication in Golang. There are also multiple third party HTTP routers and frameworks. But when you want to build a message-driven application, there are no libraries which are infrastructure-agnostic and not opinionated.

With this post, I’d like to start a series of CI-related tips, targeted mostly at GitLab, since that’s my go-to tool for things CI/CD-related. I’m sure most of them could be easily applied to other CI systems, though. While GitLab does a great job at many things (repository hosting and related stuff, like MRs, pipelines, issue boards, etc.), it sometimes lacks more specialized features in some areas. With heavy usage of pipelines in my projects, I often had to look for workarounds and smart tricks.