Let's hop right in!

Based on https://github.com/matomo-org/docker/tree/a9ce756ce0ca0957ed7a8987e562f37e6b5e4a45/.examples/nginx

Initial folder content

Here are the initial files in a folder. Copy and paste the file contents below.

/matomo
|__db.env
|__docker-compose.yml
|__matomo.conf

docker-compose.yml

version: "3"

services:
  db:
    image: mariadb
    command: --max-allowed-packet=64MB
    restart: always
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=
    env_file:
      - ./db.env

  app:
    image:
      # Select your Matomo container from: 
      # https://hub.docker.com/_/matomo
      matomo:4.13.0-fpm-alpine
    restart: always
    links:
      - db
    volumes:
      #- ./config.ini.php:/var/www/html/config/config.ini.php
      #- ./logs:/var/www/html/logs
      - matomo:/var/www/html
    environment:
      - MATOMO_DATABASE_HOST=db
      - PHP_MEMORY_LIMIT=2048M
    env_file:
      - ./db.env

  web:
    image: nginx:alpine
    restart: always
    volumes:
      - matomo:/var/www/html:ro
      # see https://github.com/matomo-org/matomo-nginx
      - ./matomo.conf:/etc/nginx/conf.d/default.conf:ro
    ports:
      - 8111:80

volumes:
  db:
  matomo:

db.env

MARIADB_ROOT_PASSWORD=root
MYSQL_PASSWORD=matomo
MYSQL_DATABASE=matomo
MYSQL_USER=matomo
MATOMO_DATABASE_ADAPTER=mysql
MATOMO_DATABASE_TABLES_PREFIX=matomo_
MATOMO_DATABASE_USERNAME=matomo
MATOMO_DATABASE_PASSWORD=matomo
MATOMO_DATABASE_DBNAME=matomo
MARIADB_AUTO_UPGRADE=1
MARIADB_INITDB_SKIP_TZINFO=1

matomo.conf

upstream php-handler {
    server app:9000;
}

server {
    listen 80;

    add_header Referrer-Policy origin; # make sure outgoing links don't show the URL to the Matomo instance
    root /var/www/html; # replace with path to your matomo instance
    index index.php;
    try_files $uri $uri/ =404;

    ## only allow accessing the following php files
    location ~ ^/(index|matomo|piwik|js/index|plugins/HeatmapSessionRecording/configs).php {
        # regex to split $uri to $fastcgi_script_name and $fastcgi_path
        fastcgi_split_path_info ^(.+\.php)(/.+)$;

        # Check that the PHP script exists before passing it
        try_files $fastcgi_script_name =404;

        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param HTTP_PROXY ""; # prohibit httpoxy: https://httpoxy.org/
        fastcgi_pass php-handler;
    }

    ## deny access to all other .php files
    location ~* ^.+\.php$ {
        deny all;
        return 403;
    }

    ## disable all access to the following directories
    location ~ /(config|tmp|core|lang) {
        deny all;
        return 403; # replace with 404 to not show these directories exist
    }
    location ~ /\.ht {
        deny all;
        return 403;
    }

    location ~ js/container_.*_preview\.js$ {
        expires off;
        add_header Cache-Control 'private, no-cache, no-store';
    }

    location ~ \.(gif|ico|jpg|png|svg|js|css|htm|html|mp3|mp4|wav|ogg|avi|ttf|eot|woff|woff2|json)$ {
        allow all;
        ## Cache images,CSS,JS and webfonts for an hour
        ## Increasing the duration may improve the load-time, but may cause old files to show after an Matomo upgrade
        expires 1h;
        add_header Pragma public;
        add_header Cache-Control "public";
    }

    location ~ /(libs|vendor|plugins|misc/user) {
        deny all;
        return 403;
    }

    ## properly display textfiles in root directory
    location ~/(.*\.md|LEGALNOTICE|LICENSE) {
        default_type text/plain;
    }
}

# vim: filetype=nginx

Prepare the database

Ok, we are ready to start the Docker containers. Use --detach switch to run the containers in the background.

# Run the command:
docker-compose up --detach

After running the above command visit http://localhost:8111 and you should see the following Matomo install wizard.

Go through the installation process step by step. After that, depending on your needs, you may want to add some configuration for automated tests or basic development setup.

Mount the config file

The next command will mount the config file created during installation to your host computer for editing.

# Run the command:
docker cp matomo_app_1:/var/www/html/config/config.ini.php .

Now your folder should look like this:

/matomo
|__config.ini.php <-- This is added.
|__db.env
|__docker-compose.yml
|__matomo.conf

Edit the config.ini.php file.

...
[General]
salt = "f5c8452a6d1491ac3b3ac475bb18e8d0" <-- This may differ.
trusted_hosts[] = "localhost:8111" <-- Add the port.
...

Edit the docker-compose.yml file.

...
  app:
    ...
    volumes:
      # Uncomment the below line like this.
      - ./config.ini.php:/var/www/html/config/config.ini.php
      #- ./logs:/var/www/html/logs
      - matomo:/var/www/html
    ...

Export the database volume

Next, we export the database volume by running the command below.

# Run the command:
docker run --rm --volume matomo_db:/dbdata --volume $(pwd):/backup ubuntu tar cvzf /backup/initial-db.gz /dbdata

Now your folder should look like this.

/matomo
|__config.ini.php
|__db.env
|__docker-compose.yml
|__initial-db.gz <-- This is added.
|__matomo.conf

Take it down...

Now we remove the containers and volumes to clean up. Run the below command.

# Run the command.
docker-compose down -v

Now the containers and volumes are gone. Everything you need is ready as files in the folder. You can commit the files to your version control and it's easy to share the same setup with others

...and up again

Let's try to start the containers with the initial database from the files.

# Import the database:
docker run --rm --volume matomo_db:/dbdata --volume $(pwd):/backup ubuntu tar xvzf /backup/initial-db.gz -C /dbdata --strip 1
# Start Matomo:
docker-compose up --detach

Now you should have the Matomo running. Go and check the URL http://localhost:8111.

Extra tip for Node.js users

If you are using Node.js, it might be handy to put something like this in your package.json file.

...
 "scripts": {
    "matomo:start": "cd matomo; docker-compose up --detach",
    "matomo:stop": "cd matomo; docker-compose down",
    "matomo:reset": "cd matomo; npm run matomo:stop; docker run --rm --volume matomo_db:/dbdata --volume $(pwd):/backup ubuntu tar xvzf /backup/initial-db.gz -C /dbdata --strip 1; npm run matomo:start",
    "matomo:destroy": "cd matomo; docker-compose down -v"
  },
...

Now you can simply run:

npm run matomo:start
# OR
npm run matomo:stop
# OR
npm run matomo:reset
# OR
npm run matomo:destroy

Afterwords

Thanks for reading! You are welcome to drop a comment if you found this useful or if you have some ideas to share with the community.

Strapi is using Koa. An easy way to add validation for custom API endpoints is by using Koa compatible validation library. I've had a good experience with node-input-validator. It has a very nice validation syntax and good flexibility for defining new validation rules.

This tutorial is tested with

Prerequisites

1. Install Strapi with Typescript option.

2. $ npm i node-input-validator --save

Steps

1. Create a custom API endpoint

$ npx strapi generate
? Strapi Generators api - Generate a basic API
? API name check-number
? Is this API for a plugin? No
✔  ++ /api/check-number/routes/check-number.ts
✔  ++ /api/check-number/controllers/check-number.ts
✔  ++ /api/check-number/services/check-number.ts

2. Create a route middleware

$ npx strapi generate      
? Strapi Generators middleware - Generate a middleware for an API
? Middleware name validate
? Where do you want to add this middleware? Add middleware to an existing API
? Which API is this for? check-number
✔  ++ /api/check-number/middlewares/validate.ts

3. Implement validation middleware

// File: /api/check-number/middlewares/validate.ts.
import niv from "node-input-validator";

export default (config) => {
  return niv.koa();
};

4. Implement a route

// File: /api/check-number/routes/check-number.ts
export default {
  routes: [
    {
     method: 'POST',
     path: '/is-it-big',
     handler: 'check-number.checkBig',
     config: {
       policies: [],
       middlewares: ["api::check-number.validate"],
     },
    },
  ],
};

5. Implement a controller

// File: /api/check-number/controllers/check-number.ts
export default {
  checkBig: async (ctx, next) => {
    try {
      await ctx.validate({
        number: "required|integer|min:0",
      });

      const checkNumberService = strapi.service(
        "api::check-number.check-number"
      );

      ctx.body = checkNumberService.confirmBigNumber(
        Number(ctx.request.body.number)
      );
    } catch (err) {
      ctx.body = err;
    }
  },
};

6. Implement a service

// File: /api/check-number/services/check-number.ts
export default {
  confirmBigNumber: (number: number): string => {
    if (number >= 1000000) {
      return `${number} is big! Yay! 👍`;
    }
    if (number < 1000000) {
      return `${number} is too small! Boo! 👎`;
    }
  },
};

7. Allow access to the API endpoint

Log in to the Strapi admin interface and allow the checkBig endpoint. See the screenshot below for reference.

8. Test the API endpoint

Ensure that Strapi is running on http://localhost:1337. Then try these curl commands.

$ curl -X POST -F 'number=word' localhost:1337/api/is-it-big
{"message":"Unprocessable Entity","body":{"message":"The given data is invalid.","errors":{"number":{"message":"The number must be an integer.","rule":"integer"}}}}

$ curl -X POST -F 'number=-1' localhost:1337/api/is-it-big
{"message":"Unprocessable Entity","body":{"message":"The given data is invalid.","errors":{"number":{"message":"The number must be at least 0.","rule":"min"}}}}

$ curl -X POST -F 'number=10000' localhost:1337/api/is-it-big 
10000 is small! 👎

$ curl -X POST -F 'number=11234152' localhost:1337/api/is-it-big 
11234152 is big! Yay! 👍

How about GET params?

Here we go.

// File: /api/check-number/routes/check-number.ts
export default {
  routes: [
    ...
    {
      method: "GET",
      path: "/credit-card/:input",
      handler: "check-number.checkCreditCard",
      config: {
        policies: [],
        middlewares: ["api::check-number.validate"],
      },
    },
  ],
};

// File: /api/check-number/controllers/check-number.ts
export default {
  ...
  checkCreditCard: async (ctx, next) => {
    try {
      await ctx.validate(
        { input: "required|creditCard" },
        ctx.params
      );

      ctx.body =
        "Are you crazy!? You just sent a credit card number inside a GET parameter.";
    } catch (err) {
      ctx.body = err;
    }
  },
};

Postfix

Let me know if you found this useful!

Please, comment also if you have any critical notes or some ideas on how to do validation even better! It's always valuable to share ideas and insights so we can all be better developers together. Thanks!

Compared to other buzzwords like DevOps, it’s hard to find any decent definition for Full-Stack Developer, even in professional discourse. It’s time to put an end to this! After reading the article you will have a deeper understanding of how the title "full-stack developer" has been used and how it is used today. I’ll also give my recommendations on how to turn down the buzz as much as possible.

Originally published Oct 12, 2018, on Hackernoon.com

Background story

I have occasionally used the term "full-stack developer" to describe myself. I first started to use it when I was asked if I was more of a back-end or front-end guy. I couldn’t make the distinction. After hearing about the full-stack title I started to use it. For me, it just meant doing both back- and front-end without specializing in either.

I didn’t give it too much thought until later when I noticed some controversy around the title. Full-stack prefixes started to feel dirty. It was cool to say the F-word while marketing myself, but with some fellow developers, it caused awkward silence and even some requests to wash my mouth. I was confused and decided to explore the true meaning of the title.

My journey began by searching for a widely accepted definition of the term by reading blogs. I read many of them and ended up even more confused.

I found long lists of different skill sets a full-stack developer must have. On the other hand, I found very loose definitions, some of which could give almost any web developer a full-stack status. Others were thinking a full-stack developer is someone more experienced than a senior developer while others were talking about junior to mid-level full-stack developers.

Some people said that it’s not even possible to be a full-stack developer, but employers didn’t seem to listen. I glanced through job listings and found a LOT of open positions for full-stack developers.

If employers were hiring full-stack developers, they had to know what they were doing, right? I started digging into the job offers for an answer, but there were too many different requirement levels lumped under the same term. I couldn’t get a clear picture of what the common factors were.

At this point, I felt I had to go deeper. When and why did all this begin? My journey took a turn, into history. ← Lower your voice for the last words to get in the mood.

Research

While doing the research, I realized how vital archive.org is for preserving historical documents. Consider donating!

I tracked the history of full-stack terminology back to the following blog post by Randy Schmidt, written in 2008.

Full Stack Web Developers
Forge38.com, June 03, 2008, Randy Schmidt - web.archive.org

It’s a mythical story about three heroes, called full stack developers, who could do “design, markup, styling, behavior, and programming” and could single-handedly spin up glorious websites and applications. Amazingly these people and applications really did exist. So seemingly it wasn’t impossible to be an actual full-stack developer, at least by the original definition.

So, what happened? Why are some people so upset about using the term? I started to understand this, as I went forward. A later influential piece from 2010 is a post from Carlos Bueno who was working at Facebook at the time.

The Full Stack, Part I
engineering.fb.com, December 02, 2010, Carlos Bueno

He refers to Schmidt’s post and offers this definition.

A “full-stack programmer” is a generalist, someone who can create a non-trivial application by themselves.

He continues.

People who develop broad skills also tend to develop a good mental model of how different layers of a system behave. This turns out to be especially valuable for performance & optimization work. No one can know everything about everything, but you should be able to visualize what happens up and down the stack as an application does its thing.

After this, he gives an example of a performance problem where in-depth knowledge of a technology stack, down to the hardware level, helps to solve the problem better. The post is apparently about large and complex applications not built by one individual. It seems that Bueno’s post has already derailed the discussion from the original definition.

Later posts on the subject use the term in the context of large teams, complex stacks, and millions of users. The original meaning was lost. We see this in the next post by Laurence Gellert from 2012.

What is a Full Stack developer?
laurencegellert.com, August 01, 2012, Laurence Gellert

To me, a Full Stack Developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology.

Good developers who are familiar with the entire stack know how to make life easier for those around them.

Here’s another influential piece from 2014 written by Mike Loukides.

Full-stack developers
radar.oreilly.com, April 04, 2014, Mike Loukides

Sometimes, the mythical “full-stack developer” sounds like: “we got rid of the silos, and now we want one person to replace them all.” That’s nonsense. What’s really needed isn’t someone who can replace all the specializations that the silos represented, but someone who can work across those specializations, someone who can work productively with people on other parts of the team. Full-stack development is about exposing yourself to a broad range of ideas.

In the above post, the idea of full-stack developers as “silo breakers” is amplified. Instead of building something by themselves, full-stack developers are the ones solving the specialization problems of large teams and existing products.

And now we land in the year 2017. A recent guide for becoming a full-stack developer tells us that the title has become the most popular developer occupation today! It also offers a following short definition.

A Guide to Becoming a Full-Stack Developer in 2017
Medium.com, April 01, 2017, Daniel Borowski, Coderbyte

A Full-Stack Web Developer is someone who is able to work on both the front-end and back-end portions of an application.

This definition seems quite relaxed and easy to fulfil. It reminds me of my original usage of the term. But if you read forward, Borowski doesn’t give too much slack for poor full-stack dev candidates. There’s a lot to learn, as stressed by almost all recent writing on the subject. It’s not just knowing some PHP, MySQL, and HTML as it used to be.

A lot more could probably be said, and the discussion has more points, but I believe this chapter summarizes the history of the term nicely.

Analysis

For some people, Borowski’s short definition seems to work as a minimum requirement to start the full-stack buzz. A full-stack developer is just someone “not specialized”. Others would like to add team skills, and interest to learn new technologies, to the mix, but it still sounds quite fluffy.

On the other end of the spectrum, employers and bloggers are chasing for magical full-stack unicorns who know everything from web usability and React to server security and AWS with ten years of Docker experience in corporate team environments. Don’t forget the CSS!

If you compare the above to the original definition, you can notice a significant difference. The original definition is based on what some people are able to do, namely build functioning websites and applications. Later attempts to define the term revolve around knowing technologies or having team skills, can-do-attitude, or a genuine interest towards the whole stack. It seems difficult to find an agreement on that basis.

When I tried to formulate a definition based on what a full-stack developer does, it became clear that two separate concepts can be teased out.

Full-stack developer (I) builds and maintains whole websites, applications or services without assistance.

Full-stack developer (II) implements features and solves problems across a technology stack as part of a team.

The first is the original definition by Schmidt. The second is spelt out in the articles that followed. You just have to read between the lines.

Full-stack developer…
…should be able to visualize what happens up and down the stack…  - Bueno
…knows how to make life easier for those around them.  - Gellert
…is someone who can work across those specializations, someone who can work productively with people on other parts of the team. -  Loukides

Discussion

The repeating question in the discussions has been when can someone claim to be a full-stack developer. “Am I really a full-stack developer?”, “What does a real full-stack developer have to know in the upcoming year?”, “Is it even possible to be a full-stack developer?”. If we adopt the way of defining the term I showed above, all these questions get a simple answer. If you are doing the job of a full-stack developer, you are one. It’s a separate issue of how skilled or qualified you are, or what is your current stack. Your work is not primarily about what skills you have, but what responsibilities you have.

Because we have two different meanings for the same term, it would be helpful to use different job titles for each definition like Full-Stack Builder for definition (I) and Cross-Stack Developer for definition (II). If you do a web search, you can see these terms already do exist, and that their usage corresponds with the above definitions nicely.

Definition (II), Cross-Stack Developer, could be an excellent replacement for Full-Stack Developer in enterprise and startup contexts. As a stack gets bigger and more complex, one person can’t handle it “fully”, so using the word “cross” should be more fitting.

If we step outside the world of large development teams, there is a huge amount of smaller businesses, organizations and nimble startups that will benefit from one person doing it all. In this context, it’s not so much about technology, but who gets the business problem solved as efficiently as possible. Definition (I) and term like Full-Stack Builder, could be used in these situations.

Recommendations

To be conceptually clear, and faithful to the original meaning, we should use Full-Stack Developer in the sense of the definition (I), Full-Stack Builder. Unfortunately, we can’t fix the situation anymore. The new meaning, (II) Cross-Stack Developer, is too widely spread. So if you are, or you’re looking for, an old-school full-stacker, for legacy reasons, you could use the title Full-Stack Builder instead.

In the context of larger teams, we could drop Full-Stack Developer in favour of Cross-Stack Developer as it usually describes the job better.

This way we could at least raise the question of what exactly we are talking about and tune down the buzz a little bit.

When using the title full-stack developer, it could be helpful to clarify what we mean by it. The current usage is more on the side of the cross-stack developer, so without any additional clarification, I think that meaning should be assumed.

Endnote

Thanks for following my journey! Maybe you don’t agree with everything I wrote, but I’m sure we can agree on one thing: Nobody listened to Mike.

I sincerely hope that “full stack” doesn’t appear in job titles anywhere.
-- Mike Loukides, 2014

I welcome any discussion, so please comment!