Forem: Hatem Temimi

Intro to kubernetes

Hatem Temimi — Wed, 06 May 2026 17:41:34 +0000

Intro to Kubernetes

This guide is aimed for people who do not know what kubernetes is, but know what a container and what a virtual machine is.
We will go through the why to kubernetes, and core concepts you need to know, along with a few commands and code snippets to put things into perspective.

Quickstart

Before kubernetes was created, containers were managed within a virtual machine, and one operating system had multiple virtual machines running, each with its own operating system and multiple containers, this method works, but it’s imperative and has its own limitations when we want to handle millions of containers. Google created kubernetes exactly for this usecase.

Kubernetes is used to manage containers, it was mainly created to orchestrate how multiple containers are being handled (networking / run / down..), it does this via multiple abstraction layers, these abstractions follow a hierarchy and are designed to simplify managing containers.

Kubernetes vs. Traditional Virtual Machines (VMs)

Before Kubernetes and containers, the standard for isolation was the Virtual Machine. While both allow you to run multiple applications on a single physical server, they operate at different layers of the stack.

1. Architectural Difference

Virtual Machines: Each VM includes a full copy of an operating system, the application, and necessary binaries/libraries. This runs on a Hypervisor (like VMware or Hyper-V).
Kubernetes (Containers): Containers share the host's OS kernel. They only package the application and its dependencies, making them significantly lighter.

2. Side-by-Side Comparison

Feature	Virtual Machines (VMs)	Kubernetes (Containers)
Size	Large (Gigabytes) - includes full OS.	Small (Megabytes) - includes only app + libs.
Boot Time	Minutes (needs to boot the whole OS).	Seconds (starts like a standard process).
Efficiency	High overhead; resources are often wasted.	High density; many containers on one host.
Portability	Hard to move between different cloud providers.	"Build once, run anywhere" (Docker/OCI standard).
Isolation	Stronger (hardware-level virtualization).	Process-level (shared kernel, though very secure).

3. Why the Shift?

In Kubernetes, If a pod fails (we will get to what a pod is), Kubernetes doesn't try to "heal" it; it simply kills it and starts a brand new one. This Self-Healing is the core power of Kubernetes.

Scalability

Scaling a VM-based app usually involves spinning up an entire new server, which is slow. Scaling in Kubernetes involves telling the Deployment to run more replicas, which happens almost instantly.

Resource Utilization

With VMs, you often pay for CPU/RAM that isn't being used because the OS itself is idling. Kubernetes allows you to "bin-pack" containers, squeezing the maximum value out of your AWS EC2 instances by filling up every available gap of memory and CPU.

Core and Abstractions

A simplified Kubernetes abstractions hierarchy looks like this: clusters are the parent component; they contain nodes and nodes contain pods and pods contain containers, but they also contain one special component called the control plane.

Within a cluster we find a control plane and one or multiple nodes, and for each node we have a special component called a kubelet that makes sure every pod within the node is running fine, as for the control plane it’s what we can access via kubectl: a CLI that allows us to access the control plane of kubernetes

Pods are the atomic unit that kubernetes handles, If we make an equivalent to the old model, pods are the equivalent of virtual machines as they have a dedicated IP address.

Within a pod we can run one or multiple containers, which share the same network, and can communicate with each other via localhost for example

Pods live and die within nodes, but they cannot come back to life, they can run on only one node and they are unique to it, they cannot for example run across multiple nodes

Kubernetes needs an environment to be run within such as: minikube which is well known and probably most used, kubeadm (most heavy) or kind (most lightweight)

We can use kubernetes imperatively by managing containers via the cli or we can use it declaratively with YAML (the most common way)

this is an example of a pod definition via YAML:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
spec:
  containers:
  - name: my-container
    image: nginx:1.14.2
    ports:
    - containerPort: 80
      ressources:
          requests: #this section checks for ressources in the pod before starting the container
              memory: "64Mi"
              cpu: "100m" #10% of the cpu
            limits:
                memory: "128Mi"
                cpu: "250m" #25% of the cpu

Mandatory commands kit

run a container inside a pod

kubectl run -f file.pod.yml ## will crash if the container already exist
kubectl apply -f file.pod.yml ## creates the container if not running

view running pods

kubectl get all ##gets all pods
kubecet get pod ## gets all pods

inspect a certain pod (gets networking info, running containers inside..)

kubectl describe pod/my-nginx

Check the logs of a certain pod

kubectl logs pod/my-nginx

shells into a container running inside a pod

kubectl exec pod-name -c container-name -it /bin/sh

delete a pod

kubectl delete pod/my-nginx

Probes

To ensure a pod is alive, we can check the logs, or use describe, but we can also set this conditionally in the yaml definition of the pod via probes; liveness probes and readiness probes

liveness tells us if the pod is alive and when the pod should restart, and readiness if it’s ready to receive requests

Liveness and readiness probe via http (can be done via other ways such as TCP)

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3
    readinessProbe:
        ##same as liveness probe for http

Deployments & ReplicaSets:

Until now, we have focused on Pods. While pods are the smallest unit in Kubernetes, they are "mortal." If a standalone pod crashes or a node fails, the pod is gone. In a production environment, you don't manually recreate pods; you use Deployments.

1. The Updated Hierarchy

Kubernetes uses a layered abstraction to manage your containers:

Cluster → Nodes → Deployment → ReplicaSet → Pods → Containers

Deployment: The high-level object. It handles updates, rollbacks, and the desired state of your application.
ReplicaSet: The "enforcer" under the hood. Its only job is to ensure that the exact number of pod replicas you requested are running at all times.

2. Declarative "Magic" (Self-Healing)

Kubernetes is declarative. You don't tell the cluster to "start a pod." You tell the Deployment: "I want 3 replicas of this pod."

If you manually delete a pod belonging to a ReplicaSet, Kubernetes notices the gap (e.g., only 2 pods are running when 3 were requested) and instantly spins up a new one to match your Desired State.

3. Understanding the Deployment YAML

The syntax for a Deployment introduces Selectors and Templates, which act as the "glue" between the deployment and the pods.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo-app
spec:
  replicas: 2           # Desired number of pod units
  selector:             # How the Deployment finds its Pods
    matchLabels:
      app: http-echo-app
  template:             # The Blueprint for the Pods to be created
    metadata:
      labels:           # These MUST match the selector above
        app: http-echo-app
    spec:
      containers:
        - name: http-echo
          image: hashicorp/http-echo:0.2.3
          args:
            - "-text=Hello from the app!"
            - "-listen=:8080"
          ports:
            - containerPort: 8080

          # ---------- HEALTH CHECKS ----------
          # Liveness: Is the container alive? If not, restart it.
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

          # Readiness: Is the app ready to receive traffic?
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 5

ZERO DOWNTIME DEPLOYMENTS

this is probably kube’s most powerful feature, the ability to rollout older images and create new ones with zero downtime, if you had to do this manually, it’s far more challenging as you will taking down the older release images and manually creating the new ones which will probably cause an outage in the updated service while this process is done, kubernetes does this automatically, via aliases, you can create multiple versions of the app, as long as we have the same alias in common between these files, when using apply, kubectl will terminate the older pods, and create new ones, here is a sample deployment file of our new version of the app that bumps the image to latest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo-app
  labels:
    app: http-echo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: http-echo-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    metadata:
      labels:
        app: http-echo-app
    spec:
      containers:
        - name: http-echo
          image: hashicorp/http-echo:latest
          args:
            - "-text=Hello from Kubernetes v2!"
            - "-listen=:8080"
          ports:
            - containerPort: 8080

          readinessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 2
            periodSeconds: 5

          livenessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

we now only have to run:

kubectl apply -f *echo-v2.deployment.yml*

this will terminate older pods and create new ones with the newer version.

Up until now, all of these deployments are not exposed, we are just checking them running or not, well it’s time to expose these pods and start poking on with http, this can be done via services.

Services: Connecting to your Pods

In Kubernetes, Pods are ephemeral (they die and are replaced). If you tried to connect directly to a Pod's IP address, your connection would break the moment that Pod was recreated.

Services act as a stable "Entry Point" (or a tunnel) that routes traffic to a set of Pods using labels.

1. Service Types: Finding the Right Entry Point

Service Type	Scope	Use Case
ClusterIP	Internal Only	Default type. Used for internal communication (e.g., your Frontend talking to your Backend).
NodePort	External	Opens a specific port (30000-32767) on every Node's IP. Great for testing or simple dev environments.
LoadBalancer	External	The standard for Production. On AWS/GCP/Azure, it provisions a real Cloud Load Balancer with a public IP.
ExternalName	Proxy	Acts as a redirect to an external DNS name (e.g., an external RDS database or a third-party API).

2. Anatomy of a Service

The most important part of a Service is the Selector—this is how the Service knows which Pods to send traffic to.

Example: LoadBalancer

This is ideal for exposing your app to the internet.

apiVersion: v1
kind: Service
metadata:
  name: http-echo-service
spec:
  type: LoadBalancer
  selector:
    app: http-echo-app # Finds Pods with this label
  ports:
    - protocol: TCP
      port: 80         # Port accessible on the LoadBalancer IP
      targetPort: 8080 # Port your Go/Node/Python app is listening on

Now that we have setup our app and exposed it via the service, we have one more thing to worry about: storage. For now if we take down a pod, we loose all the data, since pods are ephemeral, we need a way to link pods to some sort of storage, this can be done via Volumes.

Volumes: Orchestrating Storage in Kubernetes

In Kubernetes, a Volume is a directory accessible to the containers within a pod. Unlike a container's local writable layer—which is destroyed if the container crashes or restarts—volumes allow data to persist and be shared across the pod's lifecycle.

1. Storage Lifecycles

Kubernetes handles the lifecycle of data in two primary ways:

Ephemeral Storage: Tied strictly to the Pod's lifetime. If the pod is deleted, the data is gone forever.
- Core Example: emptyDir. Often used as a "scratch pad" for temporary computation or as a shared space between containers in the same pod.
Persistent Storage: Decoupled from the Pod. If the pod dies or is moved to another node, the volume remains and can be re-attached to a new pod.
- Core Examples: hostPath (storing data on the node's disk), NFS, or cloud-specific storage like AWS EBS.

2. The Persistence Workflow: PV vs. PVC

To manage persistent storage efficiently, Kubernetes uses an abstraction layer that separates the physical storage from the developer's request.

PersistentVolume (PV): This is a "physical" resource in the cluster (e.g., a 10GB SSD on AWS). It is provisioned by an administrator or a StorageClass and exists independently of any pod.
PersistentVolumeClaim (PVC): This is a "request" for storage by a developer. You define the size and access mode, and Kubernetes automatically "binds" it to a matching PV.

Analogy: A PV is a physical hard drive sitting on a shelf. A PVC is a request form for a drive of a certain size. Once the request is fulfilled, the drive is "plugged into" your Pod.

3. Access Modes

When configuring persistent volumes, you must define how they can be mounted:

Mode	Description
ReadWriteOnce (RWO)	Mounted as read-write by a single node.
ReadOnlyMany (ROX)	Mounted as read-only by many nodes.
ReadWriteMany (RWX)	Mounted as read-write by many nodes (ideal for shared logs/CMS).

4. Implementation Example

To use persistent storage, the Pod points to the Claim, not the disk itself. This ensures the application remains portable.

# 1. The Claim: "I need 1GB of storage"
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-storage-claim
spec:
  accessModes: [ "ReadWriteOnce" ]
  resources:
    requests:
      storage: 1Gi
---
# 2. The Pod: "Use the claim named app-storage-claim"
apiVersion: v1
kind: Pod
metadata:
  name: app-server
spec:
  volumes:
    - name: data-volume
      persistentVolumeClaim:
        claimName: app-storage-claim
  containers:
    - name: app-container
      image: nginx
      volumeMounts:
        - mountPath: "/var/www/html"
          name: data-volume

AND / OR operators, Short-Circuiting and Nullish Coalescing in Javascript

Hatem Temimi — Tue, 04 Jun 2024 16:16:26 +0000

Introduction

Short Circuiting and Nullish Coalescing are mechanisms available in javascript to enhance code efficiency and readability, by providing special way of evaluating values.

It relies on the logical operators && and ||, while nullish Coalescing relies on the operator ??, Both tools are powerful, but have to be used in the right context to shine

A detailed comparaison

Get some coffee and buckle up, we're going full technical.

Short-Circuiting

Short-Circuiting Applies to the logical operators && (AND) and || (OR) in JavaScript, But these operators originate from a neighbour field of science: Logical Gates in Electronics

Logic Gates

Logical Gate AND

In Electronics Engineering, The AND logical gate is nothing more but a circuit that represents the boolean logic:

A.B meaning A and B, which is written in programming as A && B

Let's Imagine two switches connected in series with a light bulb; For the bulb (output) to light up 1 / ON / Truthy, both switches (inputs) need to be closed 1 / ON / Truthy.

If either switch is open 0 / OFF / Falsy, the circuit is broken, and the bulb stays off (0).

Now if we consider the light bulb to be Q , Q will only evaluate to true if both A and B allow the current to pass through, else Q will be falsy.

Therefore, the expression A + B = Q will only evaluate to 1(true) if A=1 and B=1, which is illustrated by what is called in electronics: a truth table.

Logical Operator AND

The expression might differ in programming, but the logic is the same, Q will only be truthy if both A and B are truthy

// AND operator  
Q = A && B // A and B Must Have truthy values in order for Q to be truthy  

// Similar example using only if statement  
if (!A) {  
 Q = false;} else if (!B) {  
 Q = false;} else {  
 Q = true;}

Logical Gate OR

Similarly to the AND gate, the OR gate will represent a boolean logic, the Boolean logic for an OR circuit is represented by the plus symbol + (OR). So, for an OR circuit, the Boolean logic expression would be:

A + B which means A OR B, which is written in programming as A || B

Let's revisit our previous light bulb example, If either switch (input) is closed (1), the light (output) turns on (1). Only when both switches are open (0) will the light stay off (0).

The logic or Boolean expression for an OR gate is A+B = Q which means: If A or B is true, then Q is true, below is the truth table for an OR gate.

Logical Operator OR

// OR operator  
Q = A || B // A OR B Must be truthy in order for Q to be truthy  

// Similar example using only if statement  
if (A) {  
 Q = true;} else if (B) {  
 Q = true;} else {  
 Q = false;}

The Why to Logical Operators

As seen in the precious examples, logical operators are cleaner and shorter to write but that's not convincing enough right ?

When evaluating an expression involving these operators, JavaScript only evaluates one side of the expression if necessary, which is a big win in performance when evaluating conditions that come with costly operations to resolve;

For && (AND):
- If the left side is false, the entire expression is false without evaluating the right side.
For || (OR):
- If the left side is true, the entire expression is true without evaluating the right side.

Example:

const isLoggedIn = true;  
const hasPremium = true;  
const isAdmin = false;  
const isGuest = false;  

const canViewPremium = isLoggedIn && hasPremium //canViewPremium = true  
const canViewAdmin = isLoggedIn && isAdmin //canViewAdmin = false  
const canNavigate = isLoggedIn || isGuest // will default to true because isLoggedIn is true

we can also use logical operators for conditional execution of functions

const isLoggedIn = true;  
const isAdmin = false;  
const hasPremium = true;  

isLoggedIn && RedirectToHome() //the function will be executed  
isAdmin && isLoggedIn && RedirectToAdminPanel() //the function will not be executed  
 (isLoggedIn && (isAdmin || hasPremium)) && RedirectToPremium() //the function will be executed

one more use case for logical operators is fallback values or default values using the OR operator.
these come in handy when dealing with values that could be falsy: undefined, null, false, 0, Empty string (pay attention to what we are considering falsy in here)

const user = {}  
const isAdmin = user.isAdmin || false // if user.isAdmin is not defined, isAdmin defaults to false

Nullish Coalescing Operator (??) (Introduced in ES2020)

The Nullish Coalescing Operator was introduced to complement the logical OR operator by providing a way to assign a default value ONLY if the left operand is null or undefined.

It obviously differs from || (OR), because ||(OR) considers all falsy values (including false, 0, and an empty string "") as equivalent to null or undefined, while ?? considers only null and undefined to be falsy

Example:

let user = {  
 name: ''};  
let name1 = user.name || "Default User"; // name1 will be Default User  
let name2 = user.name ?? "Default User"; // name2 will be ''  

let maybeValue = 0;  
let result = maybeValue ?? 10; // 'result' will be 0 (falsy but not null/undefined)

Key Points:

Feature	Behavior
Short-Circuiting	Optimizes evaluation of logical expressions
Nullish Coalescing	Assigns default value specifically for null/undefined
OR Operator	Considers all falsy values as equivalent to null/undefined

When to Use:

Use short-circuiting for conditional logic where you only need to evaluate one side of the expression based on the other side's truthiness/falsiness.
Use nullish coalescing when you want to provide a default value only for null or undefined cases, and other falsy values should retain their meaning.
Additional Ressources *

Short Circuiting and Nullish-Coalescing Operators.

Testing with Playwright

Hatem Temimi — Wed, 10 Apr 2024 15:21:03 +0000

Intro

In this brief walkthrough, we will learn how to create and run a test with playwright, an End to End testing library.
Basic javascript // typescript knowledge and a frontend project that you want to test, are required.
This tutorial will cover the playwright fundamentals, and I will go into more advanced subjects in future articles, such as authentication and running tests on ci for example.

If my code runs, why should i test it ?

Once the code works, we usually go through some cleanup, and then we call it a day, with a bit of luck, it might not cause problems, but.. Hear me out on this; Even if code runs and appears to be functioning correctly, there can still be hidden bugs, edge cases, and performance issues that may only become apparent later on, once we start stockpiling lines of code.
Testing helps to uncover these problems and ensure that the code is working as intended in various situations and conditions. Additionally, testing helps to ensure that future changes to the code do not break existing functionality.
In other words, testing helps to ensure that the code is reliable, maintainable, and fit for its intended purpose. By thoroughly testing code, you can increase confidence in its behavior and reduce the likelihood of problems arising in the future.

But what is playwright ?

Playwright is the Javascript library we will be using the test our code to perform End To End Tests. When we run the tests, it will start a browser and run through the set of tests we have defined through the code.
Playwright's particularity in the market now, is that it can run tests on any browser, compared to it's competitors who do not cover web-kit which is the browser engine used by safari.

Installation

npx is used to install and run playwright (npx runs npm packages)
npx playwright install && npx playwright install-deps will install the required dependencies in your projects

Configuration

In the root of the your project, create a file named: playwright.config.ts this file will hold the playwright's default configuration to run the tests with, it can be overriden from the test file itself, but that's a subject for another day.
Here is an example config file that goes through the different configuration attributes:

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  // Look for test files in the "tests" directory, relative to this configuration file.
  testDir: 'tests', // Value: A string representing the directory path.

  headless: false // Explanation below 

  // Run all tests in parallel.
  fullyParallel: true, // Value: true or false.

  // Fail the build on CI if you accidentally left test.only in the source code.
  forbidOnly: !!process.env.CI, // Value: true or false.

  // Retry on CI only.
  retries: process.env.CI ? 2 : 0, // Value: A number, typically 0 or more retries.

  // Opt out of parallel tests on CI.
  workers: process.env.CI ? 1 : undefined, // Value: A number representing the number of workers or undefined.

  // Reporter to use
  reporter: 'html', // Value: Name of the reporter to use, e.g., 'html', 'dot', etc.

  use: {
    // Base URL to use in actions like `await page.goto('/')`.
    baseURL: 'http://127.0.0.1:3000', // Value: A string representing the base URL.

    // Collect trace when retrying the failed test.
    trace: 'on-first-retry', // Value: 'on-first-retry' or 'off'.
  },

  // Configure projects for major browsers.
  projects: [
    {
      name: 'chromium', // Value: Name of the browser, e.g., 'chromium'.
      use: { ...devices['Desktop Chrome'] }, // Value: Configuration object for the browser.
    },
  ],

  // Optionally run your local dev server before starting the tests.
  webServer: {
    command: 'npm run start', // Value: A string representing the command to start the local server.
    url: 'http://127.0.0.1:3000', // Value: A string representing the URL of the local server.
    reuseExistingServer: !process.env.CI, // Value: true or false.
  },
});

Headless vs Headed browsing

the headless attribute will tell playwright wether to start the testing browsers with or without a GUI, the browser you are using right now to read this, is most likely in headed mode, which means the GUI is running and you can navigate the interface. With headless browsing there is no GUI, which means it starts and runs faster, this mode comes in handy with large numbers of automated tests, since it makes the execution time significantly faster.
For our case, we will start the browsers in headed mode, so you can have a more visual experience, you can change it later.

With headless=false which means the browser will run with a GUI,
If you had errors with the browsers starting, you can try the following commands:

# Install Xvfb (X Virtual Framebuffer) for headless browsing.
# This package provides a virtual display server for running the browser in headless mode.
sudo apt-get install xvfb

# Start Xvfb on display :99 in the background.
# Xvfb creates a virtual display that allows the browser to render without a physical screen.
Xvfb :99 &

# Set the DISPLAY environment variable to point to the virtual display.
# This ensures that the browser renders its output to the virtual display created by Xvfb.
export DISPLAY=:99

How does it work ?

A Playwright test, basically and usually, performs three things;

Locate --> Act --> Assert

1) Locate something on the page via locators such as getByRole()
2) Act on the located element via actions

page
.getByRole('textbox') //locate the element
.fill('Peter'); //perform action

3) Assert the result of the performed action via assertions like expect(page).toHaveTitle('some title');

Now that we know all the steps of the test we will go through an idiomatic example that illustrates each one of those:

Your First Test

As per the config file we created, we said we will store our tests in the directory /tests, so we will create that directory and create our first test file inside of it: username.spec.ts with this boiler plate:


import { test, expect } from '@playwright/test';

test('has username', async ({ page }) => {
 //
 // testing code here
});

This will create a test named 'has username', that we will eventually run once we fill the test logic part, for now, note that we have access to the 'page' object, which we will be using later to navigate.

Locators

Locators are used to get elements on pages, once you get the element with the locator you are free to perform actions on it and assert the results, there are a multitude of locators depending on the situation:

page.getByRole() to locate by explicit and implicit accessibility attributes.
page.getByText() to locate by text content.
page.getByLabel() to locate a form control by associated label's text.
page.getByPlaceholder() to locate an input by placeholder.
page.getByAltText() to locate an element, usually image, by its text alternative.
page.getByTitle() to locate an element by its title attribute.
page.getByTestId() to locate an element based on its data-testid attribute (other attributes can be configured).

In our example we will use getByRole()

Actions

For the sake of simplicity, we will fill the username input, and that will be our action:

await usernameLocator.fill("myusername");

Assertions

The final step is to evaluate the result:

// Evaluate the content of our input
await expect(usernameLocator).toContainText('myusername');  

// The other way around using .not
await expect(usernameLocator).not.toContainText('some text');

Running tests

By default, npx playwright test will run all the tests located in the folder chosen in the playwright.config.ts, which is /tests in our case
You can run only specific tests in a file, by mentionning the file name as an argument:

npx playwright test username.spec.ts

Good to knows

You can also Contextualize tests with describe and nested tests

import { test, expect } from '@playwright/test';

//this can be used to group tests or to give more context
test.describe('navigation', () => {

//A particularly useful hook, since it can be used for authentication for example
  test.beforeEach(async ({ page }) => {
    // Go to the starting url before each test.
    await page.goto('/login');
  });

  test('main navigation', async ({ page }) => {
    // Assertions use the expect API.
    await expect(page).toHaveURL('/login');
  });
});

VSCode Playwright plugin makes your life a little bit easier(am a cli guy)
You do not need to think about racing tests with playwright, it manages the event loop for you.
npx killp PORT_NUMBER will kill ports for you just run npx killp and it will prompt you for installation