Nowadays successful applications often consist of containers and container management system to: 1) ease scaling 2) reduce down time 3) add self healing capabilities. Let’s take a high level overview of most commonly used tools and build something cool too.
My plan is to create open tcp port scanning tool. Use GO and worker pool to make it very fast. Expose it via REST resource, containerise, deploy and scale using kubernetes.
For this example I’ll use my favourite project structure. You can find more about it here. Let’s review the REST server:
I created an instance of cfg package…
Ever wondered how streams are working in Node.js? I had. So far I know that using streams will most certainly reduce memory usage on the server when processing large files. Instead of reading whole file into memory we stream it in chunks to whoever requested it and apply transformations to that stream if needed. That’s huge benefit as it allows to avoid vertical scaling. Processing files is common task but not as common as interacting with databases and that’s going to be my focus here. I’ll build simple API with 2 endpoints. Both will be returning pretty large amount of…
What I’d like to point out in this post is pretty common issue I had to deal with over and over again and share some patterns that have worked well on small to large sized projects for me. Some time ago I came across a route handler that was 2k lines of code long. Some changes had to be made but each time I tried to understand the control flow, 2–3 mouse scrolls down I was feeling lost. Below is just a hint (not an actual project code):
It might not look so scary from the example above, but…
During past couple of years I have worked on few projects written in GO. I noticed that the biggest challenge developers are facing is lack of constraints or standards when it comes to project layout. I’d like to share some findings and patterns that have worked best for me and my team. For better understanding I’ll go through steps of creating a simple REST API.
I’ll start with something that I hope one day will become a standard. You can read more about it here. Let’s name it boilerplate:
mkdir -p \
Good cake is the one you can easily slice into parts with no crumbs falling apart. That’s all this project is about: 3 simple parts, no nasty additives. In part 1 and part 2 I’ve explained the basics of setting up golang project using docker, creating configurable server, interacting with DB, adding routes and handlers.
What happens when multiple handlers have to reuse same logic?
What is the most elegant way of solving this issue?
This is where the middleware comes into play and will be my main focus here.
The idea of a middleware in context of route handlers…
In a previous post I was explaining the basics of setting up GO application for REST API. Now I’ll go into details by first creating configurable server, adding http router (mux) and some DB interaction. Let’s get (the indoors party) started!
The application is now running in docker, can respond to code changes and reload for instant feedback. For handling http requests I will add another dependency, http router (mux). You can read more about it here.
This is a lightweight, high performance HTTP request router that is easy to use and has everything most api’s will need.
Software engineer focusing on simplicity and reliability. GO and functional programming enthusiast