Context​

I do software for 10 years. At the beginning I did pure web: django, backbone, jquery, gulp, react, you know.

Since then the rest of my career I did mostly Go backends: some data processing from elastic to postgres, from kafka to mongo, kubernetes integrations, terraform providers, javascript sandboxes and just simple RESTful APIs. I have a few friends from web, mobile dev and I tried developing a desktop app, so to me it feels easy to imagine what to expect developing a declarative UI.

Devlog #1: github apps, docker builder, cdk8s​

Today I want to share with you my next steps of creating PaaS from scratch. On this page I will cover how I implement a basic deployment flow.

Build a container inside a rootless conatiner​

A PaaS has a very dev friendly use case: when a user just conneects a repository we must build the image from a Dockerfile in the repo. We assume at the beginning a team doesn't have a CI pipeline and wants to share a quick demo to the customers. There are many ways to do it. Let's look at all of them and at the design we chosed for Treenq

A few years ago we had 2 editors for Go: jetbrains plugin to IntelijIdea and YOUR_NAME_IT with a go plugin. First brought tons of closed source components that eventually became Goland and bunch of open source components used by another editor Go plugin:

It worked for a while, but it has a lot of issues.

1. Number one, you install a plugin, it installs a tenish of the others, every version half of the tools are broken and that's very lame dance happened every release.
2. The integration complexity, every editor did its own integration set, some used only part of them, some integrated them one by one.
3. Performance, it's not obvious today, but every tool worked once per editor request, it means every click "Go to definition" it has index the code base, find the implementatons or the object locations navigate you.

The things I've collected to write my best Dockerfile. Appreciate any comments mentioning I could do it better and more optimal.

On this page, I want to cover the caveats I encountered while shaping my approach to unit testing in the context of observability.

It's important to clarify that I’m not referring to testing logs or metrics delivery. Instead, I want to focus on testing modules that perform business logic but also include observability calls, like loggers or meters.

Note: This page won’t teach you how to design an API from scratch, but it will give you insights into how I recently designed one while developing my PaaS.

Devlog #0: logging, linter, Zitadel, codegen, e2e tests​

Today I want to share with your my first steps of creating new project. For a long time I've wanted created something cool, really meaninful, and after all I step into my idea: Platform as a service.

This article has been created to remind us of one simple thing: HTTP is a stream.

As a practical outcome we can learn how to reduce memory requirements for our services in a typical task: cache warming.

Blog is a  system to spread ideas across the internet. Shout out about a thing "Look, I have an opinion on that if you care".