Node-Alpine images with Git

This will be short and sweet.

I was building out an image for a swagger diff api (link)
and quickly realised that the size of the Node-Jessie image is > 600mb. Which is just too bloody much for my 12 lines of expressjs.


This image is based on the popular Alpine Linux project, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.
This variant is highly recommended when final image size being as small as possible is desired. The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn’t have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.


To minimize image size, it’s uncommon for additional related tools (such as git or bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar).

https://hub.docker.com/_/node/

The problem with the alpine image is that it does not contain GIT (as you can see from the above quote), which is a requirement for NPM to work properly.

So, the fast and easy way is to just add git to the dockerfile.

You simply add RUN apk --no-cache add git to your Dockerfile and you are good to go.

Doing this I ended up at an image size of 109mb down from 650mb, not bad.
Anyway, my Dockerfile went from

To


Note the change from
node:8.15-jessie to node:8.15-alpine as well.

If you want to know more about packaging simple node services inside a docker container, I highly recommend this article

Throttling actions in .Net Core 2.1 using AttributeFilter

I have previously written about Throttling in the pre-core times, and this is sort of the update to that post – with a bit of fixes and tweaks.

Lets get to it;

A few changes:

In my last post I did things a bit differently, for instance; I used to throw a custom exception type and handle that as a response, I have learned that this is an anti-pattern and is strongly discouraged (at least by David Fowler).
Anyway now we return a class, which is basically just my old ApiException type, just without the inherited bits of Exception. – this is both cheaper and cleaner.
Also since we are using .NET Core, we are using IMemoryCache instead of HttpRuntime.Cache – which is also nice.

services.AddMemoryCache();

On to the attribute:

There isn’t a lot to it to be honest.

  1. Check for existence of cache entry
  2. If none, create one and set allowExecute = true
  3. If allowExecute != true, return throttle response and short-circuit the pipeline.

Do note that this throttle uses IP as it’s target, but could easily be username or similar.

Usage:

[IPThrottling("GetItems", 300)]
[HttpGet]
public ActionResult<IEnumerable<string>> Get()
{
    return new string[] { "value1", "value2" };
}

The above throttles for 300 seconds for the GetItems key, so you can group together functionality as well, if you really need to.

Ill talk about the custom response in a different blogpost

Versioning WebApi and documenting version with Swagger

Versioning in WebApi

Note: This post draws alot of points from https://www.troyhunt.com/your-api-versioning-is-wrong-which-is/ – but is more about implementation and documentation through swagger.
So please go read Troy’s post and then come back :).
There are a couple of ways of versioning a restful api
among them are:
1. Url versioning e.g. GET http://example.com/api/v1/cars
2. Request-Header e.g. GET http://example.com/api/cars — Header: api-version: 1
There are pros and cons in both regards, Troy gets around them quite nicely.
Time to code!

Url Versioning

Easy – simply use either the RoutePrefix- or RouteAttribute

Read more about the Routing-Attribute here

Request-Header

Drawing from Troy’s post
We create a new attribute which uses a custom routing constraint

** Usage **

Effectively matching routes based on the “api-version” header.

Swagger

When using swashbuckle (swagger implementation for .Net).
It knows about the default Route- and RoutePrefixAttribute, so Url Versioning is taken care of, out of the box.
But Header versioning is not.
Fortunately, it’s quite easy to implement an OperationFilter that adds the header as a parameter to the endpoints in question.
This implementation uses a list of versions and the endpoints relativepaths to know when to add the parameter and when not to.


How would you implement the OperationFilter?