DEV Community: Djamaile

Using KEDA and Prometheus to auto-scale your k8s workloads

Djamaile — Sun, 31 Oct 2021 18:30:09 +0000

These days, everyone and their grandma are using Kubernetes and one important
aspect of Kubernetes is scaling your workloads. With KEDA, it is extremely
simple to scale your workloads! Let’s have a look.

repository: https://github.com/djamaile/keda-demo

Introduction

Straight from the website of KEDA:

KEDA is a Kubernetes-based Event Driven
Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes
based on the number of events needing to be processed.

KEDA provides many 'triggers' on which your application can scale on. For
example, Prometheus, PubSub, Postgres and many more. In this blog post we will
focus on Prometheus.

Starting up

First let's spin up a cluster! I am using kind but
you are free to use minikube if you prefer that :).

$ kind create cluster

Create the namespace

$ kubectl create ns keda-demo

Switch to the namespace

$ kubectl config set-context --current --namespace=keda-demo

If the cluster is spun up, we can start deploying our Prometheus. For this, I
have already written a prometheus manifest so you won’t have to do it.

prometheus.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
  - apiGroups: [""]
    resources:
      - services
    verbs: ["get", "list", "watch"]
  - nonResourceURLs: ["/metrics"]
    verbs: ["get"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: keda-demo
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
  - kind: ServiceAccount
    name: keda-demo
    namespace: keda-demo
--------
apiVersion: v1
kind: ConfigMap
metadata:
  name: prom-conf
  labels:
    name: prom-conf
data:
  prometheus.yml: |-
    global:
      scrape_interval: 5s
      evaluation_interval: 5s
    scrape_configs:
      - job_name: 'go-prom-job'
        kubernetes_sd_configs:
        - role: service
        relabel_configs:
        - source_labels: [__meta_kubernetes_service_label_run]
          regex: go-prom-app-service
          action: keep
--------
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus-server
  template:
    metadata:
      labels:
        app: prometheus-server
    spec:
      serviceAccountName: keda-demo
      containers:
        - name: prometheus
          image: prom/prometheus
          args:
            - "--config.file=/etc/prometheus/prometheus.yml"
            - "--storage.tsdb.path=/prometheus/"
          ports:
            - containerPort: 9090
          volumeMounts:
            - name: prometheus-config-volume
              mountPath: /etc/prometheus/
            - name: prometheus-storage-volume
              mountPath: /prometheus/
      volumes:
        - name: prometheus-config-volume
          configMap:
            defaultMode: 420
            name: prom-conf

        - name: prometheus-storage-volume
          emptyDir: {}
--------
apiVersion: v1
kind: Service
metadata:
  name: prometheus-service
spec:
  ports:
    - port: 9090
      protocol: TCP
  selector:
    app: prometheus-server

The Prometheus manifest is really simple. Just a Prometheus workload with a
clusterrole and a clusterrolebinding. Don't forget to apply the manifest:

$ kubectl apply -f prometheus.yaml

Once the pod is up and running, let's see if it also works:

$ kubectl port-forward svc/prometheus-service 9090

Now visit http://localhost:9090 and you should see the user interface of
Prometheus.

Deploying Keda

We can now deploy the KEDA operator. KEDA provides multiple ways to deploy their
operator, but for now we will use the k8s manifest.

$ kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.4.0/keda-2.4.0.yaml

Now there should be two pods in the namespace keda you can check it with the
following command:

$ kubectl get pods -n keda

As you can see there are two pods being spinned up:

on 🤠 kind-kind (keda) Desktop/projects/keda-prometheus ☁️  default
🕙[ 07:35:40 ] ❯ kubectl get pods                                                         335ms
NAME                                      READY   STATUS              RESTARTS   AGE
keda-metrics-apiserver-66b8c68649-2mwf8   0/1     ContainerCreating   0          5s
keda-operator-574c6d4769-q9mlc            0/1     ContainerCreating   0          5s

The metrics-apiserver exposes data to the Horizontal Pod Autoscaler, which gets
consumed by a deployment. The operator pod activates Kubernetes deployments to
scale to and from zero on no events.

Creating the application (Optional)

The application is a simple go application that increments the metric
http_requests when you visit it. This section is optional because you are also
free to use my docker image.

in your folder execute the following:

go mod init github.com/djamaile/keda-demo

Then in your main.go you can put in the following code:

package main

import (
    "fmt"
    "log"
    "net/http"

    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

type Labels map[string]string

var (
    httpRequestsCounter = prometheus.NewCounter(prometheus.CounterOpts{
        Name: "http_requests",
        Help: "number of http requests",
    })
)

func init() {
    // Metrics have to be registered to be exposed:
    prometheus.MustRegister(httpRequestsCounter)
}

func main() {
    http.Handle("/metrics", promhttp.Handler())
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        defer httpRequestsCounter.Inc()
        fmt.Fprintf(w, "Hello, you've requested: %s\n", r.URL.Path)
    })
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Now build the go application with:

$ go mod tidy

Let's then make a simple Dockerfile for it:

FROM golang as build-stage

COPY go.mod /
COPY go.sum /
COPY main.go /
RUN cd / && CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o go-prom-app

FROM alpine
COPY --from=build-stage /go-prom-app /
EXPOSE 8080
CMD ["/go-prom-app"]

Only thing left is to build and push the image:

$ docker build -t <your_username>/keda .
$ docker push <your_username>/keda

Running the application

If you don’t have a Docker account or don’t want to use it, that’s fine. You can
use my docker image! Let’s get our go application running in our cluster, for
that we need some k8s manifests. Not to worry because I already wrote them:

go-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-prom-app
  namespace: keda-demo
spec:
  selector:
    matchLabels:
      app: go-prom-app
  template:
    metadata:
      labels:
        app: go-prom-app
    spec:
      containers:
        - name: go-prom-app
          image: djam97/keda
          imagePullPolicy: Always
          ports:
            - containerPort: 8080
--------
apiVersion: v1
kind: Service
metadata:
  name: go-prom-app-service
  namespace: keda-demo
  labels:
    run: go-prom-app-service
spec:
  ports:
    - port: 8080
      protocol: TCP
  selector:
    app: go-prom-app

You can replace the image name with your own image if you prefer that.
Let's apply the manifest:

$ kubectl apply -f go-deployment.yaml

If the pod is up verify if it is working

$ kubectl port-forward svc/go-prom-app-service 8080

If you visit http://localhost:8080 you should see Hello, you've requested: /.

Scaling the application

Now that we have our go application up we can write a manifest that will scale
our application. Keda offers many triggers that can scale our application, but
of course we will use the Prometheus
trigger.

In a new file called scaled-object.yaml add the following content:

apiVersion: keda.sh/v1alpha1
# Custom CRD provisioned by the Keda operator
kind: ScaledObject
metadata:
  name: prometheus-scaledobject
spec:
  scaleTargetRef:
    # target our deployment
    name: go-prom-app
  # Interval to when to query Prometheus
  pollingInterval: 15
  # The period to wait after the last trigger reported active
  # before scaling the deployment back to 1
  cooldownPeriod: 30
  # min replicas keda will scale to
  # if you have an app that has an dependency on pubsub
  # this would be a good use case to set it to zero
  # why keep your app running if your topic has no messages?
  minReplicaCount: 1
  # max replicas keda will scale to
  maxReplicaCount: 20
  advanced:
    # HPA config
    # Read about it here: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 30
          policies:
            - type: Percent
              value: 50
              periodSeconds: 30
        scaleUp:
          stabilizationWindowSeconds: 0
          policies:
            - type: Percent
              value: 50
              periodSeconds: 10
  triggers:
    - type: prometheus
      metadata:
        # address where keda can reach our prometheus on
        serverAddress: http://prometheus-service.keda-demo.svc.cluster.local:9090
        # metric on what we want to scale
        metricName: http_requests_total
        # if treshold is reached then Keda will scale our deployment
        threshold: "100"
        query: sum(rate(http_requests[1m]))

Read the yaml manifest and it’s comments to understand what is going on. One
important note as well is in
advanced.horizontalPodAutoscalerConfig.scaleUp.policies you can see I have
specified 50%, that means our pod will scale up with 50% of it’s current amount
of pods. 1 -> 2 -> 3 -> 5 -> 8 -> 12 -> 18 -> 20 it will stop at 20 pods because
that is the limit we specified.

Let's apply the manifest:

$ kubectl apply -f scaled-object.yaml

This will provision an HPA in your namespace which you can check with:

$ kubectl get hpa

but because this is a custom CRD you can also query the custom CRD with kubectl:

$ kubectl get scaledobject.keda.sh/prometheus-scaledobject

NAME                      SCALETARGETKIND      SCALETARGETNAME   MIN   MAX   TRIGGERS     AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE
prometheus-scaledobject   apps/v1.Deployment   go-prom-app       1     20    prometheus                    True    False    False      64s

We can see that our prometheus-scaledobject is ready so let’s scale our
application! Remember our application scales on the metric
http_requests_total
and our threshold is only 100 so we should be able reach that threshold. For
this we can use a simple tool called hey.

Run the application

$ kubectl port-forward svc/go-prom-app-service 8080

In another terminal watch the pods

$ kubectl get pods -w -n keda-demo

Put load on the application (Do this continuously, until there are 20 pods)

$ hey -n 10000 -m GET http://localhost:8080

It can take a minute before the application actually starts scaling. After a
while you should have 20 pods up and running! Now let’s also look at the scale
down process. Stop putting load on the application and let’s just watch the
pods. This process should go from 20 -> 10 -> 5 - > 2 -> 1. This is basically
how KEDA goes to work!

If you like KEDA please check out their docs for more examples and what type of
different triggers they provide. Happy auto-scaling!

How to setup husky, eslint and prettier within minutes

Djamaile — Tue, 12 Oct 2021 20:52:29 +0000

repository: https://github.com/djamaile/hep-demo

Starting up

Let’s first generate a simple React project by using create-react-app. Execute the following command:

npx create-react-app hep-demo --template typescript && cd hep-demo

Start the app and see if everything is working properly:

yarn start

If you encounter a issue with "babel-jest": "^26.6.0" add a .env file with SKIP_PREFLIGHT_CHECK=true (echo 'SKIP_PREFLIGHT_CHECK=true' > .env )

Installing packages

Now that our app is working we can start by adding the needed packages.
For this setup we would need prettier, husky, lint-staged, eslint-config-airbnb and spotify/prettier-config.
The last one is optional, you can also create your own prettier config but recently
I have been using spotify's config with pleasant results.

To install the packages, execute the following command:

yarn add @spotify/prettier-config @typescript-eslint/parser husky lint-staged prettier -D

We will use the eslint config of airbnb to do that execute the following command:

npx install-peerdeps --dev eslint-config-airbnb

In the root of your project, create a file called .eslintrc.json and add the following content to it:

{
  "extends": [
    "airbnb"
  ],
  "parser": "@typescript-eslint/parser",
  "env": {
    "browser": true,
    "commonjs": true,
    "es6": true,
    "jest": true,
    "node": true
  },
  "rules": {
    "no-console": "off",
    "import/prefer-default-export": "off",
    "@typescript-eslint/camelcase": ["off"],
    "camelcase": ["off"],
    "react/jsx-props-no-spreading": ["off"],
    "jsx-a11y/no-static-element-interactions": "off",
    "react/prop-types": ["off"],
    "jsx-a11y/href-no-hash": ["off"],
    "jsx-a11y/click-events-have-key-events": ["off"],
    "import/no-unresolved": ["off"],
    "import/extensions": 0,
    "no-use-before-define": "off",
    "react/jsx-uses-react": "off",
    "react/react-in-jsx-scope": "off",
    "react/jsx-filename-extension": [
      "warn",
      {
        "extensions": [".js", ".jsx", ".tsx", ".ts"]
      }
    ],
    "max-len": [
      "warn",
      {
        "code": 100,
        "tabWidth": 2,
        "comments": 80,
        "ignoreComments": false,
        "ignoreTrailingComments": true,
        "ignoreUrls": true,
        "ignoreStrings": true,
        "ignoreTemplateLiterals": true,
        "ignoreRegExpLiterals": true
      }
    ]
  }
}

You, of course, don’t have to use the same rules as mine. Play with it and see what fits you the best!

Configure package json

Once the packages are installed, we can make some changes in our package.json. Let’s first start with some handy scripts:

"scripts": {
    ...
    "prettier:check": "prettier --check .",
    "prettier:write": "prettier --write .",
    "prepare": "husky install"
}

The prettier commands are there to check your code and the prepare script we will use in a bit to set up husky with a pre-commit hook.

But first in your package.json down below you can set prettier to @spotify/prettier-config and under that you can specify the lint-staged section.

"prettier": "@spotify/prettier-config",
"lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,md}": [
      "prettier --write"
    ]
}

lint-staged will execute those commands on files that are ready to be committed. Basically, it will run its specified linter on all staged git files. But before that is possible, we need to make sure that husky triggers lint-staged.

In the root of your project run:

yarn prepare

Which will create the .husky folder in your project and after we can install a pre-commit hook:

npx husky add .husky/pre-commit "yarn lint-staged"

This will create a pre-commit hook in the .husky folder. If we inspect the contents of the file you can see that it will run yarn lint-staged.

Ignore files

Before we can test if it works, we should also create .ignore files for prettier and eslint. We don't want to end up scanning the node_modules folder! Create the files:

touch .eslintignore
touch .prettierignore

In both of the files you can add the same folders to ignore:

**/node_modules/**
**/build/**
**/dist/**
**/.git/**
**/public/**

Testing

Now we can actually test if our setup works! First, we’ll need to set up a git for our project:

git init
git add .
git commit -m "first commit"

After you try to commit, you can see husky in action. It will execute yarn lint-staged which in turns calls prettier and eslint for our git staged files.

To see if it works on new stuff, let’s create a file called Button.tsx in the src directory. Once you have done that, add the following code to it:

import React from 'react';

interface Props {
  size: string;
}

export const Button: React.FC<Props> = ({size}) => {
  size = 'big'; return <button>{size}</button>;
};

So, this piece of code is wrong but let eslint tell us why. Add the file and try to commit it:

git add .
git commit -m "feat: add button component"

If eslint is working well you should receive this error:

 error  Assignment to function parameter 'size'      no-param-reassign

 error  Missing an explicit type attribute for button  react/button-has-type

Seems like we have some errors, so let’s fix them before committing our button. Overwrite Button.tsx with the fixed code:

import React from 'react';

interface Props {
  size: string;
}

export const Button: React.FC<Props> = ({ size }) => {
  const rightSize = size ? 'big' : 'small'; return <button type="button">{rightSize}</button>;
};

The code now looks good, but the styling might look a bit off. But that is okay. We are going to let prettier handle that. Let’s try again to add and commit our Button component.

git add .
git commit -m "feat: add button component"

Now we should be greeted by green light and that our component is commited! In addition, if we look at the button component we can see that prettier has rewritten our component, to make it look nicer!

import React from 'react';

interface Props {
  size: string;
}

export const Button: React.FC<Props> = ({ size }) => {
  const rightSize = size ? 'big' : 'small';
  return <button type="button">{rightSize}</button>;
};

How I structure my React /TS applications (2021)

Djamaile — Fri, 06 Aug 2021 01:19:42 +0000

(code is hosted at: https://github.com/djamaile/react-boilerplate-2021)

(last years post: https://dev.to/djamaile/how-i-structure-my-react-ts-applications-160g)

Last year, I created a post on how I structure my ReactJS projects. Now that it is summer vacation again, I shook the structure up a bit. But honestly there are few changes, because in the end React changed little (which is a good thing). So, in this post I will highlight what I changed/added.

Lets first start with a picture of the whole folder structure!

Now lets discuss the changes :)

📖 Api

In the API folder, I only now have a generic request function and what I added was react-query. If you are not familiar with react-query, it is a library for fetching server state. React-query comes with a lot of power like caching, data synchronisation, etc.

In this project, I have kept react-query pretty simple by only adding a defaultQueryFn, what looks like this:



import axios, { Method, AxiosResponse } from "axios";

const api = axios.create({
  // baseURL: process.env.REACT_APP_HOST_BACKEND,
  baseURL: "https://rickandmortyapi.com/api",
});

const request = <T>(
  method: Method,
  url: string,
  params: any
): Promise<AxiosResponse<T>> => {
  return api.request<T>({
    method,
    url,
    params,
  });
};

// Define a default query function that will receive the query key
export const defaultQueryFn = async ({ queryKey }: any): Promise<unknown> => {
  const data = await request(queryKey[0], queryKey[1], queryKey[2]);
  return data;
};

As you can see, the defaultQueryFn is calling the request function. Now we can add this to our QueryClient and in our Home view we can call the useQuery functionality like this:



import React from "react";
import "../../styles/home.css";
import { useQuery } from "react-query";
import { Header } from "../../components";

const Home: React.FC = () => {
  const { data, error, isFetching } = useQuery(["GET", "/character", {}]);

  if (isFetching) return <p>Is loading...</p>;

  if (error) return <p>${error}</p>;

  console.log(data);

  return (
    <div className="App">
      <Header />
    </div>
  );
};

export default Home

I am still experimenting with react-query and see how I can use it better. But this is how I have been using it for now.

🧪 Tests/Cypress

Yes, the infamous test folder. I actually ended up deleting it! I still have tests but I put them directly into the views/[view] folder.

I have to admit that I am not using Jest as much anymore. I have switched over to using Cypress. Cypress is a tool for end-to-end tests and I have been liking it so far. So, in cypress/integration/404_page.ts you can see I have a spec test that tests if the user can go back to the home page if the user has reached to 404 page.



describe('404 page', function() {
    it('should give the option to return to home', function() {
        cy.visit("/does-not-exists");
        cy.contains('Return to Home');
        cy.get('a')
          .click()
       cy.contains('Learn React', {timeout: 10000}) 
    });
});

🐳 Docker

I have added also Dockerfiles to my default repo. I have two separate two Dockerfiles, one for development and one for production.



FROM node:15-alpine AS builder

WORKDIR /app

COPY . .

RUN yarn install 

RUN yarn build

FROM nginx:stable-alpine

WORKDIR /usr/share/nginx/html

RUN rm -rf *

COPY --from=builder /app/build .

ENTRYPOINT ["nginx", "-g", "daemon off;"

To build a image use:



$ docker build -t djam97/react-boilerplate-2021:prod -f docker/Dockerfile.prod .

☸️ Kubernetes

I use Kubernetes daily so that's why I added also some k8s manifests. They are pretty bare bone, but they get the job done and are easily extensible.



apiVersion: apps/v1
kind: Deployment
metadata:
  name: react-boiler-plate
  labels:
    app: react-boiler-plate
spec:
  replicas: 1
  selector:
    matchLabels:
      app: react-boiler-plate
  template:
    metadata:
      labels:
        app: react-boiler-plate
    spec:
      containers:
        - name: react-boiler-plate
          image: djam97/react-boilerplate-2021:prod
          imagePullPolicy: Never
          ports:
            - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: react-boiler-plate-service
spec:
  selector:
    app: react-boiler-plate
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000

To apply the manifests use:



$ kubectl apply -f k8s/

😺 Github workflow

I have also added a Github action that deploys your React app to Github pages. This is great for initial testing or for when your site is not going to have live on it's own server.



name: Deploy site

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    continue-on-error: true
    strategy:
      matrix:
        node-version: [14.x]
    steps:
      - uses: actions/checkout@v2
      - name: Setup Node
        uses: actions/setup-node@v1
        with:
          node-version: "14.x"
      - name: Get yarn cache
        id: yarn-cache
        run: echo "::set-output name=dir::$(yarn cache dir)"
      - name: Cache dependencies
        uses: actions/cache@v1
        with:
          path: ${{ steps.yarn-cache.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-
      - name: Yarn installation
        run: yarn install && CI='' yarn build
      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.ACCESS_TOKEN }}
          publish_dir: ./buil

If you also want to use it, there are some steps you need to take. First, you need to create a personal access token in GitHub and add it as a secret to your repo as ACCESS_TOKEN. Last, change the homepage in package.json





"homepage": "https://djamaile.github.io/react-boilerplate-2021",

"homepage": "https://<your username>.github.io/react-boilerplate-2021",

🗄️ Extra files

Besides the usual prettier, eslint, husky setup. I have also added @commitlint/config-conventional to make sure every commit complies with being a conventional commit. If you don't know what that is, you can read up on it here: https://www.conventionalcommits.org/en/v1.0.0/#summary

Small React(ion): From Kanji to Hiragana!

Djamaile — Sat, 25 Jul 2020 19:32:49 +0000

I am starting a series talking about my small React applications. To begin, we start with this small application I wrote about 7 months ago. If you just want to see the code, here you go: https://github.com/djamaile/kanji-to-hiragana/

Background

A couple of months ago I was studying Japanese. I was about to graduate (I just did!) and I wanted to celebrate that with a trip to Japan. Unfortunately, that trip got canceled. But we still have this cool program!

I first started with learning hiragana and hiragana is the Japanese alphabet. After that, I started learning katakana which is also an alphabet but it is only used to describe western words/names. Then I started learning kanji. Kanji are characters to describe nouns, adjectives, adverbs, and verbs. In short, kanji are characters for words we could also describe in hiragana.

Example: Hello world (English) -> Hello せかい (Hiragana) -> Hello 世界 (Kanji)

Note: There are probably way better resources to explain this so, I suggest hitting up Google if you are more interested in this.

So, I was studying Japanese with Anki. Anki is a software program where we can use flashcards. Sometimes I would get cards with kanji on them and I would have no idea how to pronounce the word. The back of the flashcard would only tell the English translation and not show the full word in hiragana.

Furthermore, knowing the hiragana in the kanji could not only help with pronunciation but also help me better remembering the kanji. So, I wanted to translate the words with kanji in them to hiragana. Well for that I needed an API of some sort. Surprisingly I found one from https://labs.goo.ne.jp/. I can't exactly remember how I found but it did have the required API!

Application

So, I started writing my React application with this simple idea: I want to input kanji and get only hiragana back.

First, I checked if the given input was Japanese and this can be done with simple regex. If the input was not Japanese then an error would show up and alarm the user.

Second, the actual translation from kanji to hiragana. When I was building this I very much into hooks. So, I made a custom hook for the translation. In the hook, we would use the function above to check if the input is Japanese. After the check, I take the input and send a request to the API and store the result.

Lastly, I put two text boxes on the homepage and imported the hook. The application was done and it worked! I do have the mention that they are probably caveats, because of how complicated kanji is. But for the time I used it, it worked well!

Future

Well, I stopped using it, because I eventually found better Anki decks. But if someone has an idea or wants to contribute please let me know!

How I structure my React /TS applications

Djamaile — Wed, 15 Jul 2020 23:39:38 +0000

(I have updated my react structure, you can read it here: https://dev.to/djamaile/how-i-structure-my-react-ts-applications-2021-145j)

It is currently summer vacation for me and I will be working on side projects. For my summer projects, I will use ReactJS for every front-end I create. I created a boilerplate repository that I can re-use for every side project. So, the goal of this post is to display my structure, but I am interested in your project structure and how you would do it differently.

If you just want to see the code, here you go: https://github.com/djamaile/react-boilerplate-2020

Here is the picture of the structure:

Let's dive into the folders!

📖 Api

In the API folder, I keep my API routes and API calls. Also, I create a generic request function with Axios. Which can be reused for API-requests.

🖼️ Assets

In the assets folders, I have three subfolders. Firstly, the CSS folder where I keep all my in-js-CSS files. Secondly, the images folder and I think this folder speaks for itself. Lastly, the theme folder and the theme folder is for Material-UI.

For every React project, I use Material-UI. With Material-UI we can also create a custom theme and that is what we do in the theme folder.

🧱 Components

Furthermore, we have the famous components folder. Re-usable functions will be put in the components folder and it can be used by functional components in the views folder.

☂️ Hooks

The hooks folder is cool but mostly unused. I rarely make custom hooks, but I still keep the folder there in case I have some genius idea that needs to be a hook.

🗺️ Routes

In the routes folder, I keep my routes! I think the only 'weird' thing I do in my routes folder is using suspense. I am using suspense to split the code of the views. Also, we use the theme provider of Material-UI so we can use the theme we created in the theme folder.

🧪 Tests

Tests folder is there, but the question is if I even test...

⌨️ Types

So, as you know I am using Typescript. Therefore I have a folder called types where I can put in my Typescript types and interfaces. Props types are the only exemption. They get declared above the components themself.

🔨 Utils

I always create a lot of functions within a component. As a result, the component can become quite bloated. When I feel that is happening I will move the functions within the utils folder. Also, if a function is used by some other component then it is also going to the utils folder.

🗄️ Extra files

As you can see I still have some files at the root level. The important files are the configuration files for Eslint and Prettier. These two extend the Airbnb rules. Moreover, I have my own rules within them and for anyone with experience with Eslint and Prettier, it can be quite annoying to set them up. So, having these files already configured for every project I do is a lifesaver.

Well, that is my structure. You might be wondering but where are the folders for your state management? Well, I didn't create those folders because I use different state managers all the time. It just depends on what I want to use at that moment. How does your structure compare to mine?