DEV Community: Shubham Singh

wardn: catch the regression your thresholds call normal (signoz native)

Shubham Singh — Sat, 25 Jul 2026 22:28:07 +0000

Most teams find out a new release made things worse in one of two ways: a customer complains, or someone happens to be looking at a dashboard at the right moment. Alerts do not close this gap. They fire on fixed thresholds, "p99 over 2 seconds", "error rate over 5%", which is a good way to catch a fire and a bad way to catch a regression. A number can sit comfortably inside your thresholds and still be worse than it was an hour ago. The old version served checkout at 60ms; the new one serves it at 140ms; nothing is "down" by the alert book; customers already feel it; on-call does not.

We built wardn for this exact case: the quiet regression that every static threshold alert calls normal. It watches your deploys and answers one question after each one, automatically and honestly: is this version worse than the version that was live before it?

wardn reads its data from SigNoz. It does not run a collector or store time series. It adds the two things SigNoz does not have on its own, a trustworthy "a deploy happened" moment and a version-to-version comparison anchored to that moment, and then uses the metrics, logs, and traces you already send to SigNoz to explain what changed.

What wardn does

It detects the deploy itself, whatever your pipeline is. Everything starts with one call, POST /api/v1/deployments, carrying the app, version, environment, and source. The marker API is deliberately CI-agnostic. Direct CI (a kubectl/helm rollout) sends it with a curl at the end of the pipeline, once a health check passes. GitOps sends it from ArgoCD's Notifications controller when the app syncs to Healthy. wardn never guesses the deploy time from an image tag or scrapes Git. The system that knows the rollout succeeded tells it, and wardn infers the previous version from history so the caller never has to.

It compares the version to the one before it, across five metrics. When a marker lands, wardn waits for a fair window of traffic, then pulls latency, error rate, throughput, CPU, and memory from SigNoz for the window right before the deploy and the window right after. It compares them version to version and decides, per metric, whether the new version regressed. This is the part alerts miss: the comparison is relative to the last version, not to a fixed line.

It builds the dashboards that surface those regressions. There is a per-version dashboard for each of the five metrics out of the box, and you can build custom ones on top of anything SigNoz scrapes, picked from a live list of the service's metrics. Every chart is version-labeled, so a jump between two releases is a step on the line, not a smudge you have to date by memory.

It lets you alert on the regression, not on a number. Because wardn holds the before and after for each deploy, an alert can be written against the change itself. "Tell me if p99 latency from one version to the next goes up by 5ms or more" is a rule you can set, and it will catch a 60ms to 70ms creep that no static threshold would.

For any regression, you can ask AI why. A worse number tells you something changed, not what. When wardn flags a regression, it feeds the error logs and the slow or failed traces from that same window to an LLM and asks for the likely root cause, with the log lines and span names that support it quoted back. In our demo, a regressed checkout build produced payment gateway timeout, db connection pool exhausted, and inventory-service returned 503 in the logs, and the model pointed at a saturated downstream dependency rather than restating that latency went up. You can compare any two versions this way, get a plain-language summary of what moved across every metric, and then drill into the cause. Providers are pluggable: Anthropic (Claude), OpenAI, or Gemini.

It keeps the history in its own Postgres. wardn stores each deploy, its before/after snapshots, and the captured logs and traces in Postgres. That means comparisons and history are not bounded by SigNoz's own retention: a deploy from a month ago is still there to reason over, even after the raw telemetry has rolled off. It also means the model reads evidence as it was in the window, not a live query that might return nothing later.

It never touches your cluster. wardn works entirely through the marker API and outbound webhooks. It holds no kube credentials, runs no agent in your workloads, and does not care whether you deploy with Helm, ArgoCD, Flux, or a shell script. Whatever you already do to ship, wardn fits beside it.

SigNoz Native

SigNoz is the source of truth for every number, log line, and span wardn reasons over.

Metrics: PromQL over `/api/v5/query_range`

wardn's SigNoz client posts a PromQL composite query and reads back a time series:

body := v5Request{
    SchemaVersion: "v1",
    Start:         start.UTC().UnixMilli(),
    End:           end.UTC().UnixMilli(),
    RequestType:   "time_series",
    CompositeQuery: compositeQuery{
        Queries: []v5Query{{
            Type: "promql",
            Spec: promqSpec{Name: "A", Query: promql, Step: stepSec},
        }},
    },
}

For each marker it runs this twice, once for [T-window, T] and once for [T+settle, T+settle+window], and diffs the two. Because SigNoz already does the aggregation, wardn stores sparse snapshots instead of raw series, and Postgres is enough.

One bug here taught us something about PromQL we would not have guessed. We shipped a healthy v1.0.6 and wardn read its latency as 151ms when the running pod was serving 68ms. Grouping the query by version showed both the new v1.0.6 and the old, already-dead v1.0.5 returning points at the same recent timestamps. SigNoz was carrying the dead version's last sample forward for about five minutes, and our after-window was averaging the live version together with the ghost of the previous one.

The fix was to query one exact version. That required version to be a filterable label, and a resource attribute (service.version) is not filterable in SigNoz PromQL. A datapoint attribute is, which is the same mechanism that makes service_name work, so our services attach version to every datapoint:

"attributes": []any{
    kv("service_name", service),
    kv("version", version), // datapoint attribute, so it is PromQL-filterable
},

Now the query is scoped, wardn_demo_latency_ms{service_name="checkout", version="v1.0.6"}, and the ghost is gone. This lines up cleanly because wardn's marker carries the same version string the service emits, so the before-window filters to the previous version and the after-window to the new one.

Logs and traces: the raw builder query

To explain a regression, wardn pulls the error logs and slow or failed traces for the deploy's window. Same endpoint, requestType: "raw", signal logs or traces, filtered to the high-signal lines (severity_text IN ('ERROR','FATAL','CRITICAL') for logs, has_error = true for traces).

Our first logs query returned 400 and failed completely, not partially:

"message":"Found 1 errors while parsing the search expression.
           key `deployment.environment` not found"

We had a deployment.environment = 'production' clause in the filter, and our logs did not carry that attribute. SigNoz does not skip an unknown key in a search expression; it rejects the whole query. That single clause had been quietly starving the AI of evidence. Scoping the filter to service.name, which the signal does carry, fixed it, and a regressed deploy then captured 40 error logs and 40 traces per window.

Discovery: `/api/v2/metrics`

Custom dashboards need to know what a service emits. wardn calls GET /api/v2/metrics?start=<ms>&end=<ms>&limit=500, which returns each metric's name, type, and unit, and turns that into the dropdown you pick from when building a dashboard. (It is a GET with query params; a POST returns the SPA, which cost us a minute of confusion.)

Set it up against your SigNoz

Point wardn at your SigNoz query URL and a minted key:

backend:
  signozUrl: "http://signoz.signoz.svc.cluster.local:8080"
  signozApiKey: "<key from the service-account mint flow>"

Send a marker after each rollout succeeds. For direct CI, one curl:

curl -fsS -X POST https://wardn.yourco.com/api/v1/deployments \
  -H "Authorization: Bearer $WARDN_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"app":"checkout","version":"v1.4.2","environment":"production","source":"ci"}'

For GitOps, let ArgoCD send it when the app is Healthy:

service.webhook.wardn: |
  url: https://wardn.yourco.com/api/v1/deployments
  headers:
    - name: Authorization
      value: Bearer $wardn-api-key
trigger.on-deployed: |
  - when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'
    oncePer: app.status.sync.revision
    send: [app-deployed-wardn]

The oncePer: app.status.sync.revision keeps a flapping health status from firing several markers for one deploy. Set version to your real release identifier, and if it matches the service.version your app emits, the per-version filtering works with no extra config. From the second deploy onward, the before/after graphs appear, regressions get flagged, and Ask AI can explain any of them.

Ending notes

So I hope we were able to explain the whole point of wardn: its to answer the one question a static threshold structurally can't answer - not "is this number bad," but "is this version worse than the last one." No collector, no stored time series, no new telemetry pipeline. Just a marker after each deploy and a comparison anchored to it.

Try it
GitHub: github.com/happymooguild/wardn
Docs: checkout-wardn.vercel.app

We are always open for feedback :)

How I spotted a slow release in SigNoz using one OTel attribute

Shubham Singh — Sun, 19 Jul 2026 11:47:43 +0000

Every deploy is a small bet. You push a new version, the rollout goes green, and then you move on. If that version is 40% slower than the one before it, the usual way to find out is a customer complaining or someone happening to look at multiple dashboards at the right moment.

I spent an afternoon on a question I'd never actually sat down and answered: can I put version N and version N-1 of the same service side by side and see which one is slower?

Turns out yes, and it needs one OpenTelemetry resource attribute plus one Query Builder feature with Signoz. No custom tooling, no extra pipeline. This article is the exact setup, running locally on kind, including the bits that cost me time.

Running SigNoz on a kind cluster

My investigation was on my company's dev cluster, but since I can't share that environment, we will recreate the needed env on a local Kind cluster instead. Everything shown below was run on a fresh Kind cluster with nothing else installed.

Before moving ahead - our kind cluster should have enough resources to run Signoz. On native Linux there is no slider, because there is no VM. kind nodes are Docker containers running straight on the host kernel, and they get whatever's free. Confirm this:

kubectl describe node signoz-demo-control-plane | grep -A5 "Allocatable"
# cpu:     12
# memory:  32544504Ki

if you are on Mac/Windows and it doesnt show a minimum of 8GB RAM allocated - then you can bump the memory slider in Docker Desktop.

kubectl get storageclass

kind ships standard via the local-path provisioner, so that's what goes in the values file:

# values.yaml
global:
  storageClass: standard

clickhouse:
  installCustomStorageClass: true

helm repo add signoz https://charts.signoz.io
helm repo update

helm install signoz signoz/signoz \
  --namespace signoz --create-namespace \
  --wait \
  --timeout 1h \
  -f values.yaml

Then port-forward and confirm:

kubectl port-forward -n signoz svc/signoz 8080:8080
curl http://localhost:8080/api/v1/health

The first page is a signup screen. On a self-hosted instance that just creates a local admin account in your own database, so any email works.

Simulating two deploys without deploying anything

I didn't want to build and ship a real service twice just to test a comparison. telemetrygen, from the OpenTelemetry Collector contrib repo, generates synthetic OTLP traces with whatever resource attributes you hand it.

go install github.com/open-telemetry/opentelemetry-collector-contrib/cmd/telemetrygen@latest

Port-forward the collector's OTLP port and send a batch:

kubectl port-forward -n signoz svc/signoz-otel-collector 4317:4317

telemetrygen traces --otlp-insecure \
  --otlp-endpoint localhost:4317 \
  --service my-test-app \
  --otlp-attributes 'service.version="v1.0.0"' \
  --traces 30

my-test-app showed up in the Services list within seconds, with telemetrygen's two default span names (lets-go and okey-dokey-0) and populated latency, rate and Apdex charts.

The most useful thing I learned all afternoon: if you send a second batch with a different service.version and nothing else changed, both versions read identically. Mine were both exactly 123 µs across p50, p90 and p99. Default telemetrygen spans are microsecond-scale and uniform, so you end up plotting the generator's own overhead rather than anything resembling a workload.

Two flags fix that. --span-duration sets how long each span claims to take, which is the latency number you're going to plot. --rate spreads generation across real time so the result is a curve rather than a dot.

# the "healthy" version
telemetrygen traces --otlp-insecure \
  --otlp-endpoint localhost:4317 \
  --service my-test-app \
  --otlp-attributes 'service.version="v1.0.0"' \
  --traces 60 --rate 1 --span-duration 100ms

# the version that regressed
telemetrygen traces --otlp-insecure \
  --otlp-endpoint localhost:4317 \
  --service my-test-app \
  --otlp-attributes 'service.version="v2.0.0"' \
  --traces 60 --rate 1 --span-duration 250ms

Now there's a real regression to go find: 100ms against 250ms.

Grouping by `service.version`

Here's the whole idea. service.version is a standard OpenTelemetry resource attribute, and SigNoz can group any trace aggregation by it. Set it per build in your pipeline, and every version of your service becomes its own line on a chart.

Dashboards -> New Panel -> Time Series, data source Traces:

Filter: service.name = 'my-test-app'
Aggregation: p99 on duration_nano
Group By: service.version
Legend format: service.version = {{service.version}}

The legend format field is the one I'd have skipped and regretted. Without it, grouped series get generic labels and you can't tell which curve is which. {{attribute_name}} placeholders pull the actual value into the legend, so your lines are labelled v1.0.0 and v2.0.0 directly.

Stage & Run Query, and there they are — two labelled curves, one settling around 100ms and one around 250ms.

One formatting step worth doing straight away: the y-axis reads raw nanoseconds by default, so a 250ms p99 renders as 250000000 and the chart is hard to read at a glance. Panel Settings -> Formatting & Units -> set the unit for the y-axis, and it renders as ms.

The time axis stops mattering here, which is the part I find genuinely useful. It doesn't matter that v1 ran an hour ago and v2 ran five minutes ago. They're grouped by version, so you're comparing versions, not time windows.

A few extensions of the same pattern, once you're on a real service instead of a synthetic one:

Group error rate by version too. Same query shape, count() aggregation with a status_code filter, grouped by service.version. A release can hold latency perfectly steady while quietly doubling its 5xx rate, and the latency panel will never show you that.
Group by service.version alongside k8s.pod.name during a rolling update, when only some pods are running the new version. That tells you whether you're looking at a code regression or a half-finished rollout.
Save the panel as a view. The Trace Explorer's bottom bar has Save this view, so the version comparison becomes one click instead of a query you rebuild each time you're suspicious.

Alerting on it

Once the query exists, turning it into an alert is quick. Alerts -> New Alert -> Trace-based Alert, then the same filter and p99(duration_nano) aggregation, with a threshold sitting above your known-good baseline. You can keep service.version in the Group By, so each version is evaluated as its own series rather than blended into one number.

For my test data a threshold of 150ms sits neatly between the two versions, so v1.0.0 stays quiet and v2.0.0 crosses it.

What I'd tell myself before starting

service.version is the highest-leverage attribute in this whole setup, and it's the one most people leave unset or hardcoded to something meaningless. Wire it to your git SHA or release tag in the build. Everything above depends on it and it costs one line in a Dockerfile or collector config.

Second: when synthetic data shows no difference between two things you know are different, suspect your generator before you suspect the tool. --span-duration was the difference between a flat, useless chart and a real one.

What's next

Grouping by version gives you an honest answer to "did this release make things worse", and it works today with nothing more than an attribute and one panel.

The piece I want next is the automation around it: something that notices a new version went live, runs this comparison on its own, and tells me the answer without me having to suspect anything first. That's what I'm building next week, and I'll write it up the same way.

If that's interesting, I post this kind of thing regularly:

GitHub: 1Shubham7
X: @1shubham7_
YouTube: @1shubham_7
LinkedIn: 1shubham7

Docs I leaned on: SigNoz Query Builder · telemetrygen README · OpenTelemetry resource semantic conventions

Beginners guide to Kubernetes Statefulsets

Shubham Singh — Sat, 30 Nov 2024 08:41:25 +0000

StatefulSets are API objects in Kubernetes that are used to manage stateful applications. There are two types of applications in Kubernetes, Stateful applications and stateless applications. There are two ways to deploy these applications:

Deployment (for stateless applications)
StatefulSets (for stateful applications)

What are Stateful Applications?

Those applications that maintain some form of persistent state or data are called stateful applications. The key characteristic that differentiates them from stateless applications is that these applications don't rely on storing data locally and they don't treat each request as independent. They manage data between interactions. Sometimes stateless applications connect to the stateful application to forward the requests to a database.

What are Stateless Applications?

Those applications that do not maintain any form of persistent state or data locally are called stateless applications. In stateless applications, each request or interaction is treated independently. These applications are designed to be highly scalable, easy to manage, and fault-tolerant because, unlike Stateful applications, they don't have to track past interactions or requests.

Stateless applications are deployed using deployment component. Deployment is an abstraction of pods and allows you to replicate the application, meaning it allows you to run to 1, 5, 10 or n identical pods of the same stateless application.

What are StatefulSets?

In simplest terms StatefulSets are Kubernetes component that is used specifically for stateful applications. These are workload API object used to manage stateful applications. They manage the deployment and scaling of a set of Pods (Creating more replicas or deleting them), and StatefulSets are also responsible for the ordering and uniqueness of these Pods. StatefulSet was released in the Kubernetes 1.9 release.

StatefulSets will represent the set of pods with different (unique), persistent identities, and elastic hostnames (stable). It makes you assure about the ordering of scaling and deployments. Before understanding StatefulSets, you must understand Kubernetes Deployment.

Here is an example of a StatefulSet named web:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

When to Use StatefulSets

StatefulSets in Kubernetes are ideal for deploying stateful applications that require stable, unique network identifiers, persistent storage, and ordered, graceful deployment and scaling. They are suitable for applications like databases, key-value stores, and messaging queues that require consistent identity and storage.

Example of Stateful and Stateless Applications

Consider a node.js application connected to a MongoDB database. When a request comes to the node.js application it handles the request independently and does not depend on previous data to do that. It handles the request based on the payload in the request itself. This node.js application is an example of Stateless application. Now the request will either update some data in the database or query some data from the database. When node.js forwards that request to MongoDB, MongoDB updates the data based on the previous state of the data or query the data from its storage. For each request it needs to handle data and it depends upon the most up-to-date data or state to be available while node.js is just a pass-through for data updates or queries and it just processes code. Hence the node.js application should be a stateless application while the MongoDB application must be a stateful application.

Sometimes stateless applications connect to the stateful application to forward the requests to a database. This is a good example of a stateless application forwarding request to a stateful application.

How to Create a StatefulSet in Kubernetes

Here is a step by step tutorial on how to use StatefulSets and some basic operations on StatefulSets.

Create a Nginx StatefulSet Application

Step 1. Create a StatefulSet file. you can do that by entering the following command:

touch example-statefulset.yaml

Step 2. Open this file in a code-editor and write the following code into it:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: gfg-example-statefulset
  annotations:
    description: "This is an example statefulset"
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "gfg-example-service"
  replicas: 3 # remember this, we will have 3 identical pods running
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
      volumes:
      - name: www
        persistentVolumeClaim:
          claimName: myclaim

Step 3. Now we have to create a service file and a PersistentVolumeClaim file.

touch example-service.yaml
touch example-persistentVolumeChain.yaml

Create a Service for the StatefulSet Application

Step 4. Enter the following code into the service file:

apiVersion: v1
kind: Service
metadata:
  name: gfg-example-service
  annotations:
    description: "this is an example service"
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx

Create a PersistentVolumeClaim for Application

Step 5. Enter the following code into the PersistentVolumeClaim file:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 8Gi # This means we are requesting for 8 GB of storage

Now lets apply these changes.

Step 6. Enter the following command in your terminal to create the gfg-example-statefulset:

kubectl create -f example-statefulset.yaml

This will create our gfg-example-statefulset, you will get a similar result:

now if we search our StatefulSets in our terminal by the command

kubectl get statefulsets

we will find our gfg-example-statefulset in the list.

Step 7. Enter the following command in your terminal to create the gfg-example-service.

kubectl apply -f example-service.yaml

this will create a service with the name "gfg-example-service"

Step 8. Let's check our pods and services, for getting the list of pods enter the following command in your terminal:

kubectl get pods

You will get the list of the three gfg- pods that we create though defining three replicas in the example-stateful-set.yaml file. You will get a similar output:

for checking the list of services, enter the following command in your terminal:

kubectl get services

This will give you similar output:

Some Operations On StatefulSets

Adding a StatefulSet: To add a StatefulSet to your Kubernetes cluster, use the command kubectl create -f [StatefulSet file name], replacing [StatefulSet file name] with the name of your StatefulSet manifest file.

kubectl create -f StatefulSet_file_name

Deleting a StatefulSet: To delete a StatefulSet in Kubernetes, you can use the kubectl delete statefulset [name] command, where [name] is the name of the StatefulSet you want to delete.

kubectl delete statefulset [name]

Editing a StatefulSet: The command kubectl edit statefulset [name] allows you to modify the configuration of a StatefulSet directly from the command line by opening an editor.

kubectl edit statefulset [name]

Scaling of Replicas: The kubectl scale command scales the number of replicas in a StatefulSet named [StatefulSet name] to the specified [Number of replicas].

kubectl scale statefulset [StatefulSet name] --replicas=[Number of replicas]

Step 9. Now let's scale up our pods and check if it works! for scaling up the pods to 6 pods, enter the following command:

kubectl scale statefulset gfg-example-statefulset --replicas=6

This will create 3 more pods and number of pods are now 6, to get list of pods enter the following command:

kubectl get pods

You will get a similar output:

Step 10. Now let's scale down pods to 3, for that enter the same command, just change the number of replicas back to 3:

kubectl scale statefulset gfg-example-statefulset --replicas=3

now if we check the list of pods by

kubectl get pods

you will see only 3 pods running:

In this way we can create StatefulSets, scale them up and then scale them down as well. Make sure to delete the StatefulSet and the service before closing the terminal.To know more commands of of kubectl refer to Kubectl Command Cheat Sheet.

How Stateful Applications Work?

In stateful applications like MySQL, multiple pods cannot simultaneously read and write data to avoid data inconsistency.
One pod is designated as the master pod, responsible for writing and changing data, while others are designated as slave pods, only allowed to read data.
Each pod has its own replica of the data storage, ensuring data isolation and independence.
Synchronization mechanisms are employed to ensure that all pods have the same data state, with slave pods updating their data storage when the master pod changes data.
Continuous synchronization is necessary to maintain data consistency among all pods in the stateful applications.

Example:
Let's say we have one master and two slave pods of MySQL. Now what happens when a new pod replica joins the existing setup? because now that new pod also needs to create its own storage and take care of synchronizing it what happens is that it first clones the data from the previous pod and then it starts continuous synchronization to listen for any updates by master pod. since each pod has its own data storage (persistent volume) that is backed up by its own physical storage which includes the synchronized data and the state of the pod. Each pod has its own state which has information about whether it's a master pod or a slave pod and other individual characteristics. All of this gets stored in the pods own storage. Therefore when a pod dies and gets replaced the persistent pod. Identifiers make sure that the storage volume gets reattached to the replacement pod. In this way even if the cluster crashes, it is made sure that data is not lost.

Conclusion

In this article we discussed about how to use Kubernetes StatefulSets. StatefulSets are Kubenetes components used to deploy stateful applications. Stateful applications are those applications that maintain some form of persistent state or data. A good example would be any application with a database. We discussed about how to deploy an stateful application using StatefulSets. After that we discussed how Stateful applications work? At the end we discussed the difference between StatefulSet and deployment which basically moves around the point that deployment are used to deploy stateless application and StatefulSets are used to deploy statefull applications. We will end this article by addressing some FAQs.

Kubernetes StatefulSets - FAQs

How do I increase volume size in Kubernetes?

To increase volume size in Kubernetes, you need to modify the PersistentVolumeClaim (PVC) specification by changing the storage size. Then, Kubernetes automatically provisions additional storage to meet the new size requirement, provided the underlying storage class supports dynamic provisioning.

When to use hostPath in Kubernetes?

The hostPath volume type in Kubernetes is suitable for scenarios where you need to access files or directories on the node's filesystem directly within a pod. It's commonly used for accessing node-specific resources or for sharing data between containers on the same node.

What is the difference between PVC StatefulSet and deployment?

PersistentVolumeClaims (PVCs) in StatefulSets are used to provide stable, persistent storage for individual pods, ensuring data persistence and identity across pod restarts. In contrast, deployments typically utilize ephemeral volumes, suitable for stateless applications where data persistence is not a requirement.

Can We Deploy A Stateless Application Using StatefulSets?

While technically possible, it's not recommended to deploy stateless applications using StatefulSets. StatefulSets are specifically designed for stateful applications requiring stable, unique identifiers and persistent storage. Deploying stateless applications with StatefulSets can introduce unnecessary complexity and resource overhead.

Is stateless better than stateful?

It depends on the specific requirements of the application. Stateless applications are simpler to manage and scale horizontally, while stateful applications maintain data integrity and are better suited for certain workloads like databases or messaging systems.

How to Use Codecov: Track Test Coverage with GitHub Actions in Your CI Pipeline (Step-by-Step Guide)

Shubham Singh — Tue, 26 Nov 2024 09:47:04 +0000

Welcome back to the channel! 🚀 In this video, we’ll dive deep into Codecov, a powerful tool for visualizing test coverage in your projects. You’ll learn:

What Codecov is and why it’s essential for modern software development.
How to integrate Codecov into your CI pipeline using GitHub Actions.
How to use the Codecov dashboard to monitor test coverage for your codebase and track it over time.

By the end of this tutorial, you’ll have a clear understanding of how to leverage Codecov to make data-driven decisions about your tests and improve your project’s quality.

What is Codecov?
Codecov is an industry-leading tool designed to help developers understand their test coverage. By integrating Codecov into your CI pipeline, you can monitor how much of your codebase is covered by tests, track changes over time, and ensure your code quality stays top-notch.

Here is the coverage.yaml file I created in the tutorial:

name: Test and upload coverage

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: 'stable'
      - name: download dependencies
        run: go mod download
      - name: test and get coverage
        run: go test -race -coverprofile=coverage.txt -covermode=atomic ./...

      - name: upload coverage
        uses: codecov/codecov-action@v4
        with:
          token: ${{ secrets.CODECOV_TOKEN }}

🔗 Links and Resources Mentioned:

Codecov Official Website: https://about.codecov.io/
My GitHub Repository: https://github.com/1Shubham7/codecov-...

✨ If you found this video helpful, make sure to:
👍 Like this video
💬 Share your thoughts in the comments below
📢 Share this with your fellow developers
🔔 Subscribe to the channel for more tutorials like this!

📱 Follow us on Social Media:

Twitter: /1shubham7

LinkedIn: /1shubham7

GitHub: /1shubham7

🎥 Thank you for watching! See you in the next one!

Step-by-Step Guide to Implementing JWT Authentication in Go (Golang)

Shubham Singh — Sun, 17 Nov 2024 00:50:24 +0000

When creating a website's backend, one very important term we get to hear is JWT authentication. JWT authentication is one of the most popular ways of securing APIs. JWT stands for JSON Web Token and it is an open standard that defines a way for transmitting information between parties as a JSON object and that too securely. In this article, we will discuss JWT authentication and most importantly we will create an entire project for Fast and Efficient JWT authentication using Gin-Gonic, this will be a step-by-step project tutorial that will help you create a very fast and industry-level authentication API for your website or application's backend.

Table of Content:

What is JWT authentication?
Project Structure
Prerequisites
Step by Step Tutorial
Final Results
Output
Conclusion

What is JWT authentication?

JWT stands for JSON Web Token and it is an open standard that defines a way for transmitting information between parties as a JSON object and that too securely.

Let's try to understand that by the help of an example. Consider a situation when we show up at a hotel and we walk up to the front desk and the receptionist says "hey, what can I do for you?". I would say "Hi, my name is Shubham, I'm here for a conference, the sponsors are paying for my hotel". The receptionist says "okay great! well I'm going to need to see a couple things". Usually they'll need to see my identification so to prove who I am and once that they have verified that I am the right person, they will issue me a key. And authentication works in a very similar way to this example.

With JWT authentication, we are making a request out to a server saying "Hey! here's my username and password or sign-in token is this" and the website says "okay, let me check." If my username and password is correct then that would give me a token. Now on subsequent requests of the server I don't have to any longer include my username and password. I would just carry my token and check into the hotel (website), access to the Gym (data), I would have access to the pool(information) and only to my hotel room (account), I don't have access to any other hotel rooms (other user's account). This token is only authorized during the duration of my state so from check-in time to the checkout time. After that it is of no use. Now the hotel will also allow people without any verification to at least see the hotel, to roam in the public area around the hotel until you are coming inside the hotel, Similarly being an anonomous user you can interact with the website's home page, landing page, etc.

Here's an example of a JWT :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ 
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Project Structure

Here is the structure of the project. Make sure to create a similar folder structure in your workspace as well. In this structure we have 6 folders:

controllers
database
helpers
middleware
models
routes

and create the respective files inside these folders.

Prerequisites

Go - Version 1.18+
Mongo DB
Step by Step Tutorial

Step 1. Let's start the project by creating a module, the name of my module is "jwt" and my username is "1shubham7", therefore I will initial my module by entering:

go mod init github.com/1shubham7/jwt

This will create a go.mod file.

Step 2. Create a main.go file and let's create a web server in main.go. For that, add the following code in the file:

package main
import(
    "github.com/gin-gonic/gin"
    "os"
    routes "github.com/1shubham7/jwt/routes"
    "github.com/joho/godotenv"
    "log"
)
func main() {
    err := godotenv.Load(".env")
    if err != nil {
        log.Fatal("Error locading the .env file")
    }
    port := os.Getenv("PORT")
    if port == "" {
        port = "1111"
    }
    router := gin.New()
    router.Use(gin.Logger())
    routes.AuthRoutes(router)
    routes.UserRoutes(router)
    // creating two APIs
    router.GET("/api-1", func(c *gin.Context){
        c.JSON(200, gin.H{"success":"Access granted for api-1"})
    })
    router.GET("api-2", func(c *gin.Context){
        c.JSON(200, gin.H{"success":"Access granted for api-2"})
    })
    router.Run(":" + port)
}

'os' package to retrieve environment variables.
we are using gin-gonic package to create a web server.
Later we will create a routes package.
AuthRoutes(), UserRoutes() are functions inside a file from routes package, we will create it later on.

Step 3. Download the gin-gonic package:

go get github.com/gin-gonic/gin

Step 4. Create a models folder and inside it create a userModel.go file. Enter the following code inside the userModel.go:

package models
import (
    "go.mongodb.org/mongo-driver/bson/primitive"
    "time"
)
type User struct {
    ID            primitive.ObjectID `bson:"id"`
    First_name    *string            `json:"first_name" validate:"required, min=2, max=100"`
    Last_name     *string            `json:"last_name" validate:"required, min=2, max=100"`
    Password      *string            `json:"password" validate:"required, min=6"`
    Email         *string            `json:"email" validate:"email, required"` //validate email means it should have an @
    Phone         *string            `json:"phone" validate:"required"`
    Token         *string            `json:"token"`
    User_type     *string            `json:"user_type" validate:"required, eq=ADMIN|eq=USER"`
    Refresh_token *string            `json:"refresh_token"`
    Created_at    time.Time          `json:"created_at"`
    Updated_at    time.Time          `json:"updated_at"`
    User_id       string             `json:"user_id"`
}

We have created a struct called User and have added necessary fields to the struct.

json:"first_name" validate:"required, min=2, max=100" this are called field tags, these are used during decoding and encoding of go code to JSON and JSON to go.
Here validate:"required, min=2, max=100" this is used for validate that the particular field must have minimum 2 characters and maximum 100 characters.

Step 5. Create a database folder and inside it create a databaseConnection.go file, enter the following code inside it:

package database
import (
    "fmt"
    "log"
    "os"
    "time"
    "context"
    "github.com/joho/godotenv"
    "go.mongodb.org/mongo-driver/mongo"
    "go/mongodb.org/mongo-driver/mongo/options"
)
func DBinstance() *mongo.Client{
    err := godotenv.Load(".env")
    if err != nil {
        log.Fatal("Error locading the .env file")
    }
    MongoDb := os.Getenv("THE_MONGODB_URL")
    client, err := mongo.NewClient(options.Client().ApplyURI(MongoDb))
    if err != nil {
        log.Fatal(err)
    }
    ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
    defer cancel()
    err = client.Connect(ctx)
    if err!=nil{
        log.Fatal(err)
    }
    fmt.Println("Connected to MongoDB!!")
    return client
}
var Client *mongo.Client = DBinstance()
func OpenCollection(client *mongo.Client, collectionName string) *mongo.Collection {
    var collection *mongo.Collection = client.Database("cluster0").Collection(collectionName)
    return collection
}

also make sure to download the 'mongo' package:

go get go.mongodb.org/mongo-driver/mongo

Here we are connecting your mongo database with the application.

we are using 'godotenv' for loading environment variables that we will set in the .env file in main directory.
The DBinstance Function, we take the value of "THE_MONGODB_URL" from the .env file (we will create that in the coming steps) and create a new mongoDB client using the value.
'context' is used to have a timeout of 10 seconds.
OpenCollection Function() takes client and collectionName as input and creates a collection for it.

Step 6. For the routes, we will create two different files, authRouter and userRouter. authRouter includes '/signup' and '/login' . These will public to everyone so that they can authorize themselves. userRouter will not be public to everyone. It will include '/users' and '/users/:user_id'.

Create a folder called routes and add two files into it:

userRouter.go
authRouter.go

enter the following code into userRouter.go:

package routes
import (
    "github.com/gin-gonic/gin"
    controllers "github.com/1shubham7/jwt/controllers"
    middleware "github.com/1shubham7/jwt/middleware"
)
// user should not be able to use userRoute without the token
func UserRoutes (incomingRoutes *gin.Engine) {
    incomingRoutes.Use(middleware.Authenticate())
    // user routes are public routes but these must be authenticated, that
    // is why we have Authenticate() before these
    incomingRoutes.GET("/users", controllers.GetUsers())
    incomingRoutes.GET("users/:user_id", controllers.GetUserById())
}

Step 7. enter the following code into the authRouter.go:

package routes
import (
    "github.com/gin-gonic/gin"
    controllers "github.com/1shubham7/jwt/controllers"
)
// this is when the user has not signed up. userRouter is when the user has logged in
// and has the token.
func AuthRoutes(incomingRoutes *gin.Engine) {
    incomingRoutes.POST("users/signup", controllers.SignUp())
    incomingRoutes.POST("user/login", controllers.Login())
}

Step 8. create a folder called controllers and add a file called 'userController.go' to it. enter the following code inside it.

package controllers
import (
    "context"
    "fmt"
    "log"
    "net/http"
    "strconv"
    "time"
    database "github.com/1shubham7/jwt/database"
    helper "github.com/1shubham7/jwt/helpers"
    models "github.com/1shubham7/jwt/models"
    "github.com/gin-gonic/gin"
    "github.com/go-playground/validator/v10"
    "golang.org/x/crypto/bcrypt"
)
var userCollection *mongo.Collection = database.OpenCollection(database.Client, "user")
func Hashpassword()
func VerifyPassword()
func SignUp()
func Login()
func GetUsers()
func GetUserById()

The packages used are straight forward. database, helper and models are our own packages.
'fmt' package is used for string formatting.
'time' package is used for time representation
'net/http' package is used for dealing with requests
'strconv' package is used to convert string to int and vice versa.
Then we have just created the outline function, we will complete those functions in the coming steps.
Step 9. To keep environment variables in a separate file, we will create a .env file inside the main folder (root folder) and add the following code into it:

PORT=1111
THE_MONGODB_URL=mongodb://localhost:27017/go-auth

These two variables have already been used in our previous code.

Step 10. Let's create the GetUserById() function first. Enter the following code in GetUserById() function:

func GetUserById() gin.HandlerFunc{
    return func(c *gin.Context){
        userId := c.Param("user_id") // we are taking the user_id given by the user in json
        // with the help of gin.context we can access the json data send by postman or curl or user

        if err := helper.MatchUserTypeToUserId(c, userId); err != nil{
            //checking if the user in admin or not.
            // we will create that func in helper package.
                c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
                return 
            }
        var ctx, cancel = context.WithTimeout(context.Background(), 100*time.Second)
        var user models.User

        err := userCollection.FindOne(ctx, bson.M{"user_id": userId}).Decode(&user)
        defer cancel()
        if err != nil {
            c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
            return
        }
        // if everything goes ok, pass the data of the user (UserModel.go)
        c.JSON(http.StatusOK, user)
    }
}

Step 11. Let's create a folder called helpers and add a file called authHelper.go into it. Enter the following code into the authHelper.go :

package helpers
import (
    "errors"
    "github.com/gin-gonic/gin"
)
func CheckUserType(c *gin.Context, userOrAdmin string) (err error) {
    userType := c.GetString("user_type")
    err = nil
    if userType != userOrAdmin {
        err = errors.New("Not authorized to access the resource")
        return err
    }
    return err
}
func MatchUserTypeToUserId(c *gin.Context, userId string) (err error) {
    //  This is the match user function
    userType := c.GetString("user_type")
    uid := c.GetString("uid")
    err = nil
    // this means that user is USER not ADMIN and uid is not of the user. Because user can only access his id,
    // admin can access anyone's id
    if userId == "USER" && uid != userId {
        err = errors.New("You are not authorized to access this user")
    }
    err = CheckUserType(c, userType)
    return err
}

The MatchUserTypeToUserId() function just matches if the user is a Admin or just a user.
We are using CheckUserType() function inside MatchUserTypeToUserId(), this is just checking if everything is fine (if the user_type we get from user is same as the userType variable.

Step 12. We can now work on the SignUp() function of userController.go:

func SignUp()gin.HandlerFunc{
    return func(c *gin.Context){
        var ctx, cancel = context.WithTimeout(context.Background(), 100*time.Second)
        var user models.User
        if err := c.BindJSON(&user); err!=nil{
            c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
            return
        }
        validationErr := validate.Struct(user)
        // this is used to validate, but what? see the User struct, and see those validate struct fields
        if validationErr != nil {
            c.JSON(http.StatusBadRequest, gin.H{"error": validationErr.Error()})
            return
        }
        // we are using count to help us validate. if you find documents with the user email already
        // then count would be more than 0, and we can then handle that err
        count, err := userCollection.CountDocuments(ctx, bson.M{"email":user.Email})
        defer cancel()
        if err != nil {
            log.Panic(err)
            c.JSON(http.StatusInternalServerError, gin.H{"error":"error occured while checking for the email"})
        }
        password := HashPassword(*user.Password)
        user.Password = &password
        count, err = userCollection.CountDocuments(ctx, bson.M{"phone":user.Phone})
        defer cancel()
        if err != nil {
            log.Panic(err)
            c.JSON(http.StatusInternalServerError, gin.H{"error":"error occured while checking for the phone number"})
        }
        if count > 0 {
            c.JSON(http.StatusInternalServerError, gin.H{"error":"this email or phone number already exists"})
        }
        // by "c.BindJSON(&user)" user already have the information from the website user
        user.Created_at, _  = time.Parse(time.RFC3339, time.Now().Format(time.RFC3339))
        user.Updated_at, _  = time.Parse(time.RFC3339, time.Now().Format(time.RFC3339))
        user.ID = primitive.NewObjectID()
        user.User_id = user.ID.Hex()
        token, refreshToken, _ := helper.GenerateAllTokens(*user.Email, *user.First_name, *user.Last_name, *user.User_type, *&user.User_id)

        // giving value that we generated to user
        user.Token = &token
        user.Refresh_token = &refreshToken
        // now let's insert it to the database
        resultInsertionNumber, insertErr :=  userCollection.InsertOne(ctx, user)
        if insertErr != nil {
            msg := fmt.Sprintf("User item was not created")
            c.JSON(http.StatusInternalServerError, gin.H{"error": msg})
            return
        }
        defer cancel()
        c.JSON(http.StatusOK, resultInsertionNumber)
    }
}

We created a variable user of type User.
validationErr is used to validate the struct tags, we already discussed this.
We are also using count variable to validate. As in if we find documents with the user email already then the count would be more than 0, and we can then handle that error (err)
Then we are using 'time.Parse(time.RFC3339, time.Now().Format(time.RFC3339))' to set the time for Created_at, Updated_at struct fields. When the user tries to sign up, the function SignUp() will run and that particular time will be stored in Created_at, Updated_at struct fields.
Then we are creating tokens using GenerateAllTokens() function that we will create in tokenHelper.go file in the same package in the next step.
We also have a HashPassword() function that is doing nothing but hashing the user.password and replacing the user.password with the hashed password. We will also create that thing later.
And then we are just inserting the data and the tokens etc. to the userCollection
If everything goes right, we will give StatusOK back.

Step 13. create a file in helpers folder called 'tokenHelper.go' and enter the following code inside it.

package helpers
import (
    "context"
    "fmt"
    "log"
    "os"
    "time"
    "github.com/1shubham7/jwt/database"
    jwt "github.com/dgrijalva/jwt-go" // golang driver for jwt
    "go.mongodb.org/mongo-driver/bson"
    "go.mongodb.org/mongo-driver/bson/primitive"
    "go.mongodb.org/mongo-driver/mongo"
    "go.mongodb.org/mongo-driver/mongo/options"
)
type SignedDetails struct {
    Email string
    First_name string
    Last_name string
    Uid string
    User_type string
    jwt.StandardClaims
}
var userCollection *mongo.Collection = database.OpenCollection(database.Client, "user")
// btw we sould have our secret key in .env for production 
var SECRET_KEY string = os.Getenv("SECRET_KEY")
func GenerateAllTokens(email string, firstName string, lastName string, userType string, uid string) (signedToken string, signedRefreshToken string, err error){
    claims := &SignedDetails{
        Email : email,
        First_name: firstName,
        Last_name: lastName,
        Uid : uid,
        User_type: userType,
        StandardClaims: jwt.StandardClaims{
            // setting the expiry time
            ExpiresAt: time.Now().Local().Add(time.Hour *time.Duration(120)).Unix(),
        },
    }
        // refreshClaims is used to get a new token if th eprevious once is expired.

        refreshClaims := &SignedDetails{
            StandardClaims: jwt.StandardClaims{
                ExpiresAt: time.Now().Local().Add(time.Hour *time.Duration(172)).Unix(),
        },
    }
    token ,err := jwt.NewWithClaims(jwt.SigningMethodHS256, claims).SignedString([]byte(SECRET_KEY))
    refreshToken, err := jwt.NewWithClaims(jwt.SigningMethodHS256, refreshClaims).SignedString([]byte(SECRET_KEY))
    if err!= nil{
        log.Panic(err)
        return
    }
    return token, refreshToken, err
}

Also make sure to download the github.com/dgrijalva/jwt-go package:

go get github.com/dgrijalva/jwt-go

Here we are using github.com/dgrijalva/jwt-go for generating tokens.
We are creating a struct called SignedDetails with field names required for generating tokens.
we are using NewWithClaims to generate new tokens and are giving the value to the claims and refreshClaims structs. claims has token for the first time users and refreshClaims has it when the user has to refresh the token. that is, they previously had a token which is now expired.
time.Now().Local().Add(time.Hour *time.Duration(120)).Unix() is being used for setting the expiry of the token.
we are then simply returning three things - token, refreshToken and err which we are using in the SignUp() function.

Step 14. In the same file as SignUp() function, let's create the HashPassword() function we talked about in step 9.

func HashPassword(password string) string {
    hashed, err:=bcrypt.GenerateFromPassword([]byte(password), 14)
    if err!=nil{
        log.Panic(err)
    }
    return string(hashed)
}

We are simply using the GenerateFromPassword() method from bcrypt package which is used to generate hashed passwords from the actual password.
This is important because we would not want and hacker to hack into our systems and steal all the passwords, also for the users privacy.
[]byte (array of bytes) is simply string.

Step 15. Let's create the Login() function in 'userController.go' and in later steps we can create the functions that Login() uses:

func Login() gin.HandlerFunc{
    return func(c *gin.Context) {
        var ctx, cancel = context.WithTimeout(context.Background(), 100*time.Second)
        var user models.User
        var foundUser models.User
        // giving the user data to user variable
        if err := c.BindJSON(&user); err != nil {
            c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
            return
        }
        // finding the user through email and if found, storing it in foundUser variable
        err := userCollection.FindOne(ctx, bson.M{"email": user.Email}).Decode(&foundUser)
        defer cancel()
        if err!=nil{
            c.JSON(http.StatusInternalServerError, gin.H{"error": "email or password is incorrect"})
            return 
        }
        // we need pointer to acess the origina user and foundUser,
        // if we only pass user and foundUser, it will create a new instance of user and foundUser
        isPasswordValid, msg := VerifyPassword(*user.Password, *foundUser.Password)
        defer cancel()
        if isPasswordValid != true{
            c.JSON(http.StatusInternalServerError, gin.H{"error": msg})
            return
        }
        if foundUser.Email == nil {
            c.JSON(http.StatusInternalServerError, gin.H{"error": "user not found"})
        }
        token, refreshToken, _ := helper.GenerateAllTokens(*foundUser.Email, *foundUser.First_name, *foundUser.Last_name, *foundUser.User_type, foundUser.User_id)
        helper.UpdateAllTokens(token, refreshToken, foundUser.User_id)
        err = userCollection.FindOne(ctx, bson.M{"user_id":foundUser.User_id}).Decode(&foundUser)
        if err != nil {
            c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
            return
        }
        c.JSON(http.StatusOK, foundUser)
    }
}

We are creating two variables of type User, these are user and Founduser. and giving the data from request to user.
By the help of 'userCollection.FindOne(ctx, bson.M{"email": user.Email}).Decode(&foundUser)' we are finding the user through his/her email and if found, storing it in foundUser variable.
Then we are using VerifyPassword() function to verify the password and store it, remember that we are taking pointers as parameters in VerifyPassword(), if not, it would create a new instance of those in parameters rather than actually changing them.
We will create VerifyPassword() in the next step.
Then we are simply using GenerateAllTokens() and UpdateAllTokens() to generate and update the token and refreshToken (which are basically tokens).
And every step, we are all handling the errors.

Step 16. Let's create the VerifyPassword() function in the same file as Login() function:

func VerifyPassword(userPassword, providedPassword string) (bool, string) {

    err := bcrypt.CompareHashAndPassword([]byte(providedPassword), []byte(userPassword))
    check := true
    msg := ""
    if err != nil {
        check = false
        msg = fmt.Sprintf("email or password is incorrect.")
    }
    return check, msg
}

We are simply using the CompareHashAndPassword() method from bcrypt package which is used to compare hashed passwords. and returning a boolean value depening on the results.
[]byte (array of bytes) is simply string, but []byte helps in comparing.

Step 17. Let's create the UpdateAllTokens() function in the 'tokenHelper.go' file:

func UpdateAllTokens(signedToken string, signedRefreshToken string, userId string){
    var ctx, cancel = context.WithTimeout(context.Background(), 100*time.Second)
    var updateObj primitive.D
    updateObj = append(updateObj, bson.E{"token", signedToken})
    updateObj = append(updateObj, bson.E{"refresh_token", signedRefreshToken})
    Updated_at, _ := time.Parse(time.RFC3339, time.Now().Format(time.RFC3339))
    updateObj = append(updateObj, bson.E{"updated_at", Updated_at})
    upsert := true
    filter := bson.M{"user_id":userId}
    opt := options.UpdateOptions{
        Upsert: &upsert,
    }
    _, err := userCollection.UpdateOne(
        ctx,
        filter,
        bson.D{
            {"$set", updateObj},
        },
        &opt,
    )
    defer cancel()
    if err!=nil{
        log.Panic(err)
        return
    }
    return
}

We are creating a variable called updateObj which is of type primitive.D. primitive.D type in MongoDB's Go driver is a representation of a BSON document.
Append() is appending a key-value pair to updateObj each and every time its running.
Then 'time.Parse(time.RFC3339, time.Now().Format(time.RFC3339))' is used to update the current time (time when the updation happens and the function runs) to Updated_at.
Rest of the code block is performing update using the UpdateOne method of mongoDB collection.
At the last step we are also handling the error in case any error occurs.

Step 18. Before continuing ahead, let's download the go.mongodb.org/mongo-driver package:

go get go.mongodb.org/mongo-driver

Step 19. Let's now work on GetUserById() function. Remember that GetUserById() is for the users to access there own information, Admins can access all the users data, users can only access theirs.

func GetUserById() gin.HandlerFunc{
    return func(c *gin.Context){
        userId := c.Param("user_id") // we are taking the user_id given by the user in json
        // with the help of gin.context we can access the json data send by postman or curl or user

        if err := helper.MatchUserTypeToUserId(c, userId); err != nil{
            //checking if the user in admin or not.
            // we will create that func in helper package.
                c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
                return 
            }
        var ctx, cancel = context.WithTimeout(context.Background(), 100*time.Second)
        var user models.User

        err := userCollection.FindOne(ctx, bson.M{"user_id": userId}).Decode(&user)
        defer cancel()
        if err != nil {
            c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
            return
        }
        // if everything goes ok, pass the data of the user (UserModel.go)
        c.JSON(http.StatusOK, user)
    }
}

Taking the user_id from the request and storing it in userId variable.
creating a variable called user of type User. then simply searching the user in our database with the help of user_id, if the user_id matches, we will store that persons information in user variable.
If everything goes fine, StatusOk
we are also handling the errors at every step.

Step 20. Let's now work on GetUsers() function. Remember that only the admin can access the GetUsers() function because it would include the data of all the users. Create a GetUsers() function in the same file as GetUserById(), Login() and SignUp() function:

func GetUsers() gin.HandlerFunc{
    return func(c *gin.Context){
        if err := helper.CheckUserType(c, "ADMIN"); err != nil{
            c.JSON(http.StatusBadRequest, gin.H{"error":err.Error()})
            return
        }
        var ctx, cancel = context.WithTimeout(context.Background(), 100*time.Second)
        //  setting how many records you want per page.
        // we are taking the recodePerPage from c and converting it to int
        recordPerPage, err := strconv.Atoi(c.Query("recordPerPage"))
        // if error or recordPerPage is less than 1, by default we will have 9 records per page
        if recordPerPage<1||err != nil {
            recordPerPage = 9
        }
        // this is just like page number
        page, err1 := strconv.Atoi(c.Query("page"))
        // we want to start with the page number 1 by default.
        if err1 !=nil || page < 1{
            page = 1
        }
        startIndex := (page - 1) * recordPerPage
        startIndex, err = strconv.Atoi(c.Query("startIndex"))
        matchStage := bson.D{{"$match", bson.D{{}},
    }}
        // group all the data based on id, and then count them using $sum. then
        // pushing all the data to the root.
        groupStage := bson.D{{"$group", bson.D{{"_id", bson.D{{"_id", "null"}}},
        {"total_count", bson.D{{"$sum", 1}}},
        {"data", bson.D{{"$push", "$$ROOT"}}},
    }}}
        // in project stage we deside which data should go to the user and which not.
        projectStage := bson.D{
            {"$project", bson.D{
                {"_id", 0},
                {"total_count", 1},
                {"user_items", bson.D{{"$slice", []interface{}{"$data", startIndex, recordPerPage}}}},
            }},
        }
        result, err := userCollection.Aggregate(ctx, mongo.Pipeline{
            matchStage, groupStage, projectStage})
        defer cancel()
        if err != nil{
            c.JSON(http.StatusInternalServerError, gin.H{"error":"error occured while listing user items"})
        }
        // creating a slice called allUser and giving the result value
        var allUsers []bson.M
        if err := result.All(ctx, &allUsers); err != nil {
            log.Fatal(err)
        } 
        c.JSON(http.StatusOK, allUsers[0])
    }
}

Firstly, we will check if the request is coming from the admin or not, we do that by the help of CheckUserType() we created in previous steps.
Then we are setting how many records you want per page.
We can do that by taking the recodePerPage from the request and converting it to int, this is done by srtconv.
If any error occurs in setting recordPerPage or recordPerPage is less than 1, by default we will have 9 records per page
Similarly we are taking the page number in variable 'page'.
By default we will have page number as 1 and 9 recordPerPage.
Then we created three stages (matchStage, groupStage, projectStage).
Then we are setting these three stages in our Mongo pipeline using Aggregate() function
Also we are handling errors are every step.

Step 21. Our 'userController.go' is now ready, this is how the 'userController.go' file looks like after completion:

package controllers
import (
    "context"
    "fmt"
    "log"
    "net/http"
    "strconv"
    "time"
    database "github.com/1shubham7/jwt/database"
    helper "github.com/1shubham7/jwt/helpers"
    models "github.com/1shubham7/jwt/models"
    "github.com/gin-gonic/gin"
    "github.com/go-playground/validator/v10"
    "golang.org/x/crypto/bcrypt"
    "go.mongodb.org/mongo-driver/bson"
    "go.mongodb.org/mongo-driver/bson/primitive"
    "go.mongodb.org/mongo-driver/mongo"
)
var userCollection *mongo.Collection = database.OpenCollection(database.Client, "user")
var validate = validator.New()
func HashPassword(password string) string {
    hashed, err:=bcrypt.GenerateFromPassword([]byte(password), 14)
    if err!=nil{
        log.Panic(err)
    }
    return string(hashed)
}
func VerifyPassword(userPassword, providedPassword string) (bool, string) {

    err := bcrypt.CompareHashAndPassword([]byte(providedPassword), []byte(userPassword))
    check := true
    msg := ""
    if err != nil {
        check = false
        msg = fmt.Sprintf("email or password is incorrect.")
    }
    return check, msg
}
func SignUp()gin.HandlerFunc{
    return func(c *gin.Context){
        var ctx, cancel = context.WithTimeout(context.Background(), 100*time.Second)
        var user models.User
        if err := c.BindJSON(&user); err!=nil{
            c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
            return
        }
        validationErr := validate.Struct(user)
        // this is used to validate, but what? see the User struct, and see those validate struct fields
        if validationErr != nil {
            c.JSON(http.StatusBadRequest, gin.H{"error": validationErr.Error()})
            return
        }
        // we are using count to help us validate. if you find documents with the user email already
        // then count would be more than 0, and we can then handle that err
        count, err := userCollection.CountDocuments(ctx, bson.M{"email":user.Email})
        defer cancel()
        if err != nil {
            log.Panic(err)
            c.JSON(http.StatusInternalServerError, gin.H{"error":"error occured while checking for the email"})
        }
        password := HashPassword(*user.Password)
        user.Password = &password
        count, err = userCollection.CountDocuments(ctx, bson.M{"phone":user.Phone})
        defer cancel()
        if err != nil {
            log.Panic(err)
            c.JSON(http.StatusInternalServerError, gin.H{"error":"error occured while checking for the phone number"})
        }
        if count > 0 {
            c.JSON(http.StatusInternalServerError, gin.H{"error":"this email or phone number already exists"})
        }
        // by "c.BindJSON(&user)" user already have the information from the website user
        user.Created_at, _  = time.Parse(time.RFC3339, time.Now().Format(time.RFC3339))
        user.Updated_at, _  = time.Parse(time.RFC3339, time.Now().Format(time.RFC3339))
        user.ID = primitive.NewObjectID()
        user.User_id = user.ID.Hex()
        token, refreshToken, _ := helper.GenerateAllTokens(*user.Email, *user.First_name, *user.Last_name, *user.User_type, *&user.User_id)

        // giving value that we generated to user
        user.Token = &token
        user.Refresh_token = &refreshToken
        // now let's insert it to the database
        resultInsertionNumber, insertErr :=  userCollection.InsertOne(ctx, user)
        if insertErr != nil {
            msg := fmt.Sprintf("User item was not created")
            c.JSON(http.StatusInternalServerError, gin.H{"error": msg})
            return
        }
        defer cancel()
        c.JSON(http.StatusOK, resultInsertionNumber)
    }
}
func Login() gin.HandlerFunc{
    return func(c *gin.Context) {
        var ctx, cancel = context.WithTimeout(context.Background(), 100*time.Second)
        var user models.User
        var foundUser models.User
        // giving the user data to user variable
        if err := c.BindJSON(&user); err != nil {
            c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
            return
        }
        // finding the user through email and if found, storing it in foundUser variable
        err := userCollection.FindOne(ctx, bson.M{"email": user.Email}).Decode(&foundUser)
        defer cancel()
        if err!=nil{
            c.JSON(http.StatusInternalServerError, gin.H{"error": "email or password is incorrect"})
            return 
        }
        // we need pointer to acess the origina user and foundUser,
        // if we only pass user and foundUser, it will create a new instance of user and foundUser
        isPasswordValid, msg := VerifyPassword(*user.Password, *foundUser.Password)
        defer cancel()
        if isPasswordValid != true{
            c.JSON(http.StatusInternalServerError, gin.H{"error": msg})
            return
        }
        if foundUser.Email == nil {
            c.JSON(http.StatusInternalServerError, gin.H{"error": "user not found"})
        }
        token, refreshToken, _ := helper.GenerateAllTokens(*foundUser.Email, *foundUser.First_name, *foundUser.Last_name, *foundUser.User_type, foundUser.User_id)
        helper.UpdateAllTokens(token, refreshToken, foundUser.User_id)
        err = userCollection.FindOne(ctx, bson.M{"user_id":foundUser.User_id}).Decode(&foundUser)
        if err != nil {
            c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
            return
        }
        c.JSON(http.StatusOK, foundUser)
    }
}
// GetUsers can only be accessed by the admin.
func GetUsers() gin.HandlerFunc{
    return func(c *gin.Context){
        if err := helper.CheckUserType(c, "ADMIN"); err != nil{
            c.JSON(http.StatusBadRequest, gin.H{"error":err.Error()})
            return
        }
        var ctx, cancel = context.WithTimeout(context.Background(), 100*time.Second)
        //  setting how many records you want per page.
        // we are taking the recodePerPage from c and converting it to int
        recordPerPage, err := strconv.Atoi(c.Query("recordPerPage"))
        // if error or recordPerPage is less than 1, by default we will have 9 records per page
        if recordPerPage<1||err != nil {
            recordPerPage = 9
        }
        // this is just like page number
        page, err1 := strconv.Atoi(c.Query("page"))
        // we want to start with the page number 1 by default.
        if err1 !=nil || page < 1{
            page = 1
        }
        startIndex := (page - 1) * recordPerPage
        startIndex, err = strconv.Atoi(c.Query("startIndex"))
        matchStage := bson.D{{"$match", bson.D{{}},
    }}
        // group all the data based on id, and then count them using $sum. then
        // pushing all the data to the root.
        groupStage := bson.D{{"$group", bson.D{{"_id", bson.D{{"_id", "null"}}},
        {"total_count", bson.D{{"$sum", 1}}},
        {"data", bson.D{{"$push", "$$ROOT"}}},
    }}}
        // in project stage we deside which data should go to the user and which not.
        projectStage := bson.D{
            {"$project", bson.D{
                {"_id", 0},
                {"total_count", 1},
                {"user_items", bson.D{{"$slice", []interface{}{"$data", startIndex, recordPerPage}}}},
            }},
        }
        result, err := userCollection.Aggregate(ctx, mongo.Pipeline{
            matchStage, groupStage, projectStage})
        defer cancel()
        if err != nil{
            c.JSON(http.StatusInternalServerError, gin.H{"error":"error occured while listing user items"})
        }
        // creating a slice called allUser and giving the result value
        var allUsers []bson.M
        if err := result.All(ctx, &allUsers); err != nil {
            log.Fatal(err)
        } 
        c.JSON(http.StatusOK, allUsers[0])
    }
}
func GetUserById() gin.HandlerFunc{
    return func(c *gin.Context){
        userId := c.Param("user_id") // we are taking the user_id given by the user in json
        // with the help of gin.context we can access the json data send by postman or curl or user

        if err := helper.MatchUserTypeToUserId(c, userId); err != nil{
            //checking if the user in admin or not.
            // we will create that func in helper package.
                c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
                return 
            }
        var ctx, cancel = context.WithTimeout(context.Background(), 100*time.Second)
        var user models.User

        err := userCollection.FindOne(ctx, bson.M{"user_id": userId}).Decode(&user)
        defer cancel()
        if err != nil {
            c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
            return
        }
        // if everything goes ok, pass the data of the user (UserModel.go)
        c.JSON(http.StatusOK, user)
    }
}

Step 22. Now we can work on the authentication part. For that we will create a authenticate middleware. Create a folder called 'middleware' and create a file inside it called 'authMiddleware.go'. Enter the following code in the file:

package middleware
import (
    "net/http"
    "github.com/gin-gonic/gin"
    "fmt"
    helpers "github.com/1shubham7/jwt/helpers"
)
func Authenticate() gin.HandlerFunc{
    return func(c *gin.Context) {
        clientToken := c.Request.Header.Get("token")
        if clientToken == "" {
            c.JSON(http.StatusInternalServerError, gin.H{"error":fmt.Sprintf("No Authorization header provided")})
            c.Abort()
            return
        }
        claims, err := helpers.ValidateToken(clientToken)
        if err !="" {
            c.JSON(http.StatusInternalServerError, gin.H{"error":err})
            c.Abort()
            return
        }
        c.Set("email", claims.Email)
        c.Set("first_name", claims.First_name)
        c.Set("last_name", claims.Last_name)
        c.Set("uid", claims.Uid)
        c.Set("user_type", claims.User_type)
        c.Next()
    }
}

Step 23. Now let's create ValidateToken() function, we will create this function in the 'tokenHelper.go':

func ValidateToken(signedToken string) (claims *SignedDetails, msg string) {
    // this function is basically returning the token
    token, err := jwt.ParseWithClaims(
        signedToken,
        &SignedDetails{},
        func(token *jwt.Token)(interface{}, error){
            return []byte(SECRET_KEY), nil
        },
    )
    if err != nil {
        msg = err.Error()
        return
    }
    // checking if the token is correct or not
    claims, ok := token.Claims.(*SignedDetails)
    if !ok {
        msg = fmt.Sprintf("the token is invalid")
        msg = err.Error()
        return 
    }
    // if the token is expired, give error message
    if claims.ExpiresAt < time.Now().Local().Unix(){
        msg = fmt.Sprintf("token has been expired")
        msg = err.Error()
        return
    }
    return claims, msg
}

ValidateToken takes signedToken and returns SignedDetails of that along with an error message. "" if there is no error.
ParseWithClaims() function is being used to get us the token and store it in a variable called token.
Then we are checking if the token is correct or not using the Claims method on token. And we are storing the result in claims variable.
Then we are checking if the token has expired using ExpiresAt() function, if current time is greater than the ExpiresAt time, it would have expired.
And then simply return the claims variable as well as the message.

Step 24. We are mostly done now, let's do 'go mod tidy', this command checks in your go.mod file, it deletes all the packages/dependencies that we installed but are not using and downloads any dependencies that we are using but haven't downloaded yet.

go mod tidy

Output

With that our JWT authentication project is ready, to finally run the application enter the following command in the terminal:

go run main.go

You will get a similar output:

This will get the server up and running, and you can use curl or Postman API for sending request and receiving response. Or you can simply integrate this API with an frontend framework. And with that, our authentication API is ready, pat yourself on the back!

Conclusion

In this article we discussed one of the fastest ways to create JWT authentication, we used Gin-Gonic framework for our project. This is not your "just another authentication API". Gin is 300% faster than NodeJS, that makes this authentication API really fast and efficient. The project structure we are using is also an industry level project structure. You can make further changes like storing the SECRET_KEY in the .env file and a lot more to make this API better. You can also find the source code for this project here - 1Shubham7/go-jwt-token.

Make sure to follow all the steps in order to create the project and add some more functionality and just play with the code to understand it better. The best way to learn authentication is to create your own projects.

My journey from a CNCF contributor to LFX mentee

Shubham Singh — Sun, 17 Nov 2024 00:24:12 +0000

Contributing to open source, specially to the Cloud Native Community Foundation (CNCF) has been one of the most effective ways for me to learn programming, understand how large codebases work and work with experienced engineers on large scale projects. It's been a year for me as a contributor in the CNCF ecosystem and I also have recently completed my LFX (Linux Foundation Mentorship) program as a mentee. As I wrap up my LFX program I want to share my journey in open source - from contributing to CNCF projects to getting into the prestigious LFX (Linux Foundation Mentorship) program and completing it successfully.

My first contribution to CNCF

Let's start it from how I got introduced to CNCF, I got know about CNCF through YouTube videos, I saw some YouTubers in cloud native space talk about CNCF and I went to the CNCF home page but I couldn't understand anything, I think the reason was that I had never anything similar to CNCF. I was confused whether CNCF is a company where I can get placed? or is it a project? or is it like a community? But as I leaned more about cloud native technologies like Docker, Kubernetes I understood what CNCF is and what it stands for, by this time I also started searching of some CNCF projects to contribute to and one such project was CNCF ORAS (OCI Registries As Service), basically it is a tool for pushing and downloading OCI Artifacts from the OCI Registries. I contributed to ORAS for a month where I learned the how to contribute to a CNCF project. And with my ORAS experience I can suggest a newbie in open source that the best way to make your first contribution is to first, understand what the project is by reading docs and try using it, then using docs set it up locally and then look up for issues labelled "good first" or "help wanted" on their GitHub repo and start by solving those issues.

The first contribution I made to ORAS was some basic changes in the readme file, and then I tried understanding the project, watching tutorials on the CNCF YouTube channel, going through docs and trying to set it up locally. I then started contributing to the docs and then made my first code contribution in ORAS.

Applying for LFX for the first time

I contributed to ORAS for a month and I wanted to apply for LFX with them (this is during LFX 2023 term 3) but they did not have a proposal for that term so I had to pick up a different project. Later I realized I need to improve my skills before applying to LFX so I skipped that term and rather I went forward with an internship offer I had from a startup.

Contributing to CNCF Kyverno

For next few months along with my internship I was focusing was on building projects, learning go and Kubernetes, and leaning about another CNCF project called CNCF Kyverno, it is a Kubernetes native policy engine. If we go back a little bit, when ORAS did not come for LFX, I started searching for other CNCF projects I that is when I saw KubeEdge, the project I am currently working under and Kyverno where I became an official contributor later. I started learning about Kyverno, one of my friends recommended me to contribute to Kyverno and I would also recommend any newbie who wants to start contributing to open source that you should choose an active project (where maintainers are active and regularly help contributors). I can recommend Kyverno to any beginner because it has a really good documentation and maintainers a very supportive. Luckily all three projects I have contributed to till now have been amazing. Also I would suggest that at KubeEdge, we are continuously trying to improve our documentation so if you think you would want to help us, please join the community and contribute.

Tip - If you want to start contributing to Kyverno my recommendation would be to start by watching some CNCF talks about what Kyverno is and what it does, then complete the free certification from the Nirmata website and then pick up any good first issue from the project (they are very active and frequently post up good first issues to solve).

Even I did the same, I also went through some CNCF talks about Kyverno, completed the certification and then started contributing. I started with some code contributions and then also created a section in their documentation about admission controllers.

Applying for LFX again

I contributed to Kyverno for a few months while also managing my internship and college classes and finally the time came when projects for LFX term 2 2024 were announced. I saw the list and Kyverno was not there and once again I had to change my project just before a month from LFX. I was going through all the projects that were coming in LFX, I saw KubeEdge there, KubeEdge is a Kubernetes native edge computing framework. I had some idea about what KubeEdge is and I found the projects really interesting so I decided to apply for LFX under KubeEdge. I applied for two projects, one was about writing new documentation and the other one was about test enhancement. While I was more interested in code contributions but I had a background of working as a technical writer for 8 months and I also had good contributions in Kyverno documentation so I decided to focus more on the documentation enhancement project and also give time to learn things for the tests enhancement project.

For the documentation improvement project, I went through all the tutorials present online for KubeEdge, I went through the entire documentation and I tried improving the documentation by bringing in changes in sentence refactoring, rephrasing docs and some other improvements. majorly, I wrote some blogs for different KubeEdge releases from v1.10 to v1.17, for this I used the changelogs of these releases as reference. While for the tests enhancement project, I started learning about writing unit tests, E2E tests using ginkgo and gomega, TDD (Test driven development) and tinkering with some libraries I could use for testing in golang. I had about a month to contribute to KubeEdge, understand the project and prepare two cover letter for the two projects. By the time LFX registrations started, I had good number of Pull Requests merged in KubeEdge (11) and some were being reviewed.

After this, the tasks I had to complete in order to complete my LFX application were - submit a resume, and submit a cover letter (which is the case for most of the projects, some projects can also ask for another task testing your knowledge about the tool). I already had a good resume prepared so I made minor changes in it, I started preparing my cover letter for both the projects, in the cover letter I mentioned my past contributions to the CNCF community as well as to Kyverno, other than that I answered honestly all the standard questions that are asked, other that this I also mentioned how I would go about working on the project for the three months.

And I finally got in!

With my past experience as a technical writer, and the contributions I made to the KubeEdge documentation as well as Kyverno documentation I thought I had more chances of getting in to the documentation project, on the result date I was surprised for good that I have been selected to the "tests enhancement" project, this was even better because now I would get to make code contributions. I was super excited to work under my mentors. I just got started by revising some stuff related to unit testing and E2E testing, and then jumped into writing tests.

My LFX mentorship Experience

The first half of LFX mentorship

After I received the acceptance mail, I was really excited to get started with my mentorship, I communicated with my mentors and they told me to start by writing unit tests for simple files since those are more straight forward. This was the first time I was writing unit tests so I started by watching tutorials and deciding which library to use for testing. In KubeEdge we were using the standard testing library for unit tests and if else statements for assertion. I researched a bit and saw that using an assertion library like testify/assert would make more sense as it removes much boilerplate from the tests, and improves speed and quality of understanding and modifying the tests. And that there are negligible downsides to using this library. I talked with my mentor regarding this and we decided to go forward with testify/assert.

For these 3 months I was writing unit tests continuously but also working on other tests side by side, in the first week other than writing tests and researching I also wrote a release blog for KubeEdge v1.10. For the next few weeks I was only writing unit tests. I started with simpler and more straight-forward tests and then moved to tests that require mocking and tests that would test the integration (calling) of multiple functions.

I had never written E2E tests before this so I also had to watch tutorials and read documentation for E2E. Our project was using Ginkgo and Gomega for E2E so I learned about them, went through the official documentation for Ginkgo and wrote some E2E tests for dummy projects for practicing. Before the first evaluation (which happens after 1.5 months) I had improved the test coverage of the project by about 5%, written E2E tests for adding the liveness probe configurations in deployment and checking if it works in the edge, and written a few blogs for some KubeEdge releases (v1.10 ~ v1.17). And when I got my mid term evaluations, I had successfully passed them.

The second half of LFX mentorship

In the second half of my LFX mentorship, I continued writing unit tests, the only difference being they were getting more complex now and I regularly had to visit Kubernetes docs or https://pkg.go.dev/ for reference. During this time, I wrote E2E tests for verifying that the applications configured with probe works fine on the edge. Other than that since many tests in the project were simply using standard testing library without any assertion library, I migrated those tests to standard library + testify/assert.

By the time my LFX mentorship period ended, I had improved test coverage of out project by 10%, written about 20k lines of tests, migrated tests from standard testing library to a new assertion library and written blogs of 7 KubeEdge releases (v1.10 ~ v1.17). I also had my end semester exams during the second half of the mentorship so for a few days became very hectic but overall the mentorship went quite smooth and I got to learned a lot of things. Whenever I needed any help I communicated with my mentors and they were very supportive and helped me wherever I needed them. And with this on 29th August 2024 I received my final evaluations and I had successfully completed my LFX mentorship.

Final thoughts

The 3 months of LFX mentorship was one of the best learning experience I ever had in tech. In these 3 months, I explored how to use KubeEdge, worked with my mentors to improve test coverage of the project as well as contribute to the documentation. I am really grateful that I got to work on an emerging CNCF project with such experienced engineers as my mentors. Working closing with such great engineers have taught me a lot about cloud native application development, testing and a lot more stuff. I am thankful to the Linux Foundation for conducting such an amazing open source program and doing it consistently over the years and I highly recommend it to everyone that at least applying for LFX if you are a student or somebody interested in FOSS, even the application process and contributions will teach you a lot about FOSS development

A small thank you note to Linux Foundation

I want to thank the entire Linux Foundation team, specially Nate Waddington and Sriji Ammanath. During this LFX period I also suffered a cyber fraud and the LF team specially Nate and Sriji were kind enough to pause my payments and patiently waited for the whole thing to be fixed. Thank you guys :)

A small thank you note to my mentors

I would also like to thank my mentors Fisher Xu and Shelley Bao Yue for being so helpful and so supportive throughout the mentorship. I am thankful that you gave me some time from your busy days and helped me out wherever I got stuck. Thank you mentors, you guys are awesome :)

DEV Community: Shubham Singh

wardn: catch the regression your thresholds call normal (signoz native)

What wardn does

SigNoz Native

Metrics: PromQL over /api/v5/query_range

Logs and traces: the raw builder query

Discovery: /api/v2/metrics

Set it up against your SigNoz

Ending notes

How I spotted a slow release in SigNoz using one OTel attribute

Running SigNoz on a kind cluster

Simulating two deploys without deploying anything

Grouping by service.version

Alerting on it

What I'd tell myself before starting

What's next

Beginners guide to Kubernetes Statefulsets

What are Stateful Applications?

What are Stateless Applications?

What are StatefulSets?

When to Use StatefulSets

Example of Stateful and Stateless Applications

How to Create a StatefulSet in Kubernetes

Create a Nginx StatefulSet Application

Create a Service for the StatefulSet Application

Create a PersistentVolumeClaim for Application

Some Operations On StatefulSets

How Stateful Applications Work?

Conclusion

Kubernetes StatefulSets - FAQs

How do I increase volume size in Kubernetes?

When to use hostPath in Kubernetes?

What is the difference between PVC StatefulSet and deployment?

Can We Deploy A Stateless Application Using StatefulSets?

Is stateless better than stateful?

How to Use Codecov: Track Test Coverage with GitHub Actions in Your CI Pipeline (Step-by-Step Guide)

Step-by-Step Guide to Implementing JWT Authentication in Go (Golang)

What is JWT authentication?

Project Structure

Prerequisites

Output

Conclusion

My journey from a CNCF contributor to LFX mentee

My first contribution to CNCF

Applying for LFX for the first time

Contributing to CNCF Kyverno

Applying for LFX again

And I finally got in!

My LFX mentorship Experience

The first half of LFX mentorship

The second half of LFX mentorship

Final thoughts

A small thank you note to Linux Foundation

A small thank you note to my mentors

Metrics: PromQL over `/api/v5/query_range`

Discovery: `/api/v2/metrics`

Grouping by `service.version`