Caddy is an open-source web server written in Go that is designed to make running and deploying web applications simple. Unlike older servers such as Apache or Nginx, Caddy focuses on removing friction — especially around configuration and HTTPS management — so you can spend more time building and less time babysitting infrastructure.

One of Caddy’s biggest conveniences is automatic HTTPS. With sensible defaults and an easy-to-read Caddyfile, you don’t need to learn a complex configuration language or wrestle with TLS certificates. Caddy also includes built-in support for HTTP/3, which helps ensure fast, modern performance today and better compatibility for the future.

Caddy runs with zero runtime dependencies, making it lightweight and straightforward to install. It’s also capable: you can use it as a reverse proxy with load balancing, caching, circuit breaking, and health checks. If you need additional functionality, Caddy supports plugins to extend its capabilities.

These features make Caddy a reliable option for both hobby projects and enterprise deployments. Whether you’re just getting started or you’re an experienced developer, Caddy aims to make server management painless so you can focus on your application.

In this article, we’ll walk through key Caddy features — serving static files, proxying requests to backend apps, automatic HTTPS, and how it can integrate with observability tools for logging and uptime monitoring.

2. Prerequisites

Before you begin, make sure you have a few basic tools and settings in place so the examples run smoothly:

• Comfortable using the command line — you’ll be running a few terminal commands.

• Docker and Docker Compose (recent versions) installed on your machine so you can build and run the example containers.

• Git installed so you can clone the example repositories.

• (Optional) A domain name if you want to follow the HTTPS examples end-to-end.

If any of these are missing, you can install them quickly with your platform’s package manager or Docker’s official installer; the domain is only required when you want to test the automatic HTTPS flow.

3. Caddy’s Automatic HTTPS & SSL Features

One of Caddy’s most compelling value propositions is how it completely rethinks HTTPS. Traditionally, TLS setup has been operationally heavy — manual certificate issuance, cron-based renewals, and brittle configurations. Caddy removes that entire layer of complexity and makes HTTPS the default, not an afterthought.

3.1 How Automatic HTTPS Works

When you configure Caddy with a valid domain name, it automatically handles HTTPS for you. There is no need to generate certificates manually, install Certbot, or set up renewal scripts.

Basic workflow

Caddy starts
   ↓
Detects domain from config
   ↓
Requests SSL certificate
   ↓
Verifies domain ownership
   ↓
Enables HTTPS

Caddy communicates directly with a Certificate Authority such as Let’s Encrypt, configures secure TLS settings, and stores the certificate locally. Renewal is also handled automatically before the certificate expires.

Simple example

example.com {
    reverse_proxy localhost:3000
}

That’s enough. Once Caddy starts, https://example.com works automatically.

3.2 Wildcard SSL Certificates

Wildcard certificates are useful when you need to secure multiple subdomains under a single domain, such as:

• app.example.com

• api.example.com

• admin.example.com

• or even dynamic, user-generated subdomains

Instead of issuing and managing certificates for each subdomain individually, a wildcard certificate like *.example.com covers them all. This is especially valuable in multi-tenant systems, SaaS platforms, and environments where subdomains are created dynamically.

To issue a wildcard certificate, Caddy uses the DNS challenge. This method proves domain ownership by creating a temporary DNS record rather than serving a file over HTTP. Because of this, you need API access to your DNS provider (such as Cloudflare, Route53, or DigitalOcean).

3.3 Certificate Management & Security

After certificates are issued, Caddy continues managing them in the background.

Automatic renewals

Caddy monitors certificate expiration dates and renews them automatically. No cron jobs, no restarts, and no manual intervention are required.

Handling failures

If a challenge fails due to DNS issues or permission problems, Caddy:

• Logs clear error messages

• Retries automatically

• Keeps the existing certificate until renewal succeeds

This reduces the risk of unexpected HTTPS downtime.

4. Setting Up Caddy for Local Development

The examples below focus mainly on macOS and Linux, for Windows, follow the official documentation.

4.1 Installing Caddy

Installing Caddy is straightforward and doesn’t require complex dependencies.

macOS (Homebrew)

brew install caddy

Linux (official repository)

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Windows

Download the binary or installer from the official Caddy website and follow the installer steps.

Verifying the installation

After installation, confirm Caddy is available:

caddy version

If you see a version number, Caddy is ready to use.

4.2 Running Multiple Local Sites

A common local setup involves working on multiple projects at the same time. Caddy handles this cleanly using a single configuration file.

Example local project structure

~/projects/
 ├── blog
 ├── api
 └── dashboard

Each project can be mapped to its own local domain.

Using custom .test domains

Add entries to your /etc/hosts file:

127.0.0.1 blog.test
127.0.0.1 api.test
127.0.0.1 dashboard.test

.test domains are reserved for local use and work well for development.

Single Caddyfile with multiple sites

blog.test {
    root * ~/projects/blog
    file_server
}

api.test {
    reverse_proxy localhost:4000
}

dashboard.test {
    reverse_proxy localhost:5173
}

4.3 Local HTTPS

Modern applications often rely on HTTPS-only features such as:

• Secure cookies

• OAuth callbacks

• Service workers

• SameSite cookie policies

Caddy makes local HTTPS easy using internal certificates.

Using tls internal

blog.test {
    root * ~/projects/blog
    file_server
    tls internal
}

This tells Caddy to:

• Create a local Certificate Authority

• Issue trusted certificates for local domains

• Manage everything automatically

On first run, Caddy may ask for permission to trust its local CA.

5. Reusable Snippets (Custom Reusable Config Blocks)

As projects grow, Caddyfiles can quickly become repetitive. The same headers, compression rules, or security settings often appear across multiple sites. Caddy solves this problem with snippets — small, reusable configuration blocks that help keep your setup clean and consistent.

5.1 Why Snippets Matter

Snippets allow you to define common configuration once and reuse it everywhere. This is especially useful when working with multiple local projects or managing several environments.

Key benefits:

• Avoid repeating the same configuration across sites

• Reduce copy-paste errors

• Make updates easier and safer

• Keep Caddyfiles readable as setups grow

In short, snippets help you treat your Caddy configuration like real, maintainable code.

5.2 Creating Your Own Snippets

Snippets are defined using parentheses and can contain any valid Caddy directives, here are some snippets example.

Example: security headers snippet

(security_headers) {
    header {
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "no-referrer"
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
    }
}

Snippet for CORS (useful for API development)

(cors_dev) {
    @cors_preflight method OPTIONS
    handle @cors_preflight {
        header {
            Access-Control-Allow-Origin "*"
            Access-Control-Allow-Methods "GET, POST, PUT, PATCH, DELETE, OPTIONS"
            Access-Control-Allow-Headers "Content-Type, Authorization"
            Access-Control-Max-Age "3600"
        }
        respond 204
    }
    header {
        Access-Control-Allow-Origin "*"
        Access-Control-Allow-Credentials "true"
    }
}

Proxy with fallback and custom error handling

(proxy_with_fallback) {
    reverse_proxy {args[0]} {
        transport http {
            dial_timeout 2s
            response_header_timeout 30s
        }
    }
    handle_errors {
        respond "Service temporarily unavailable. Please try again later." 503
    }
}

Using snippets in a site

example.com {
    import security_headers

    import proxy_with_fallback 3000
}

5.3 Using Snippets Across Local & Production Sites

A common pattern is to keep all snippets at the top of the Caddyfile or move them into a separate file:

Example structure

caddy/
 ├── Caddyfile
 └── snippets/
     ├── security.caddy
     ├── proxy.caddy
     └── cors.caddy

Then just add this to your main Caddyfile.

import snippets/*.caddy

example.com, www.example.com {
    import security_headers
    import cors_dev
}

6. Caddyfile Configuration: Default vs Custom Paths

As your Caddy setup grows beyond a single site, understanding where Caddy loads its configuration from becomes important. Caddy is flexible here — it works out of the box with sensible defaults, but also gives you full control when you need custom paths or structured setups.

6.1 Default Caddyfile Path

By default, Caddy looks for a file named Caddyfile in a standard system location.

Common default paths:

• Linux: /etc/caddy/Caddyfile

• macOS (Homebrew): /opt/homebrew/etc/caddy/Caddyfile

• Windows: C:\caddy\Caddyfile (or install directory)

When Caddy is installed as a service, it automatically loads this file on startup.

6.2 Using a Custom Caddyfile Path

In real projects, especially during development, you often want multiple Caddyfiles — one per project or environment. Caddy supports this cleanly.

Running Caddy with a custom config

caddy run --config ./Caddyfile

Or explicitly specify the format:

caddy run --config ./Caddyfile --adapter caddyfile

For development uses

• Keep the Caddyfile inside the project

• Easy to version-control

• Quick local iteration

project/
 ├── Caddyfile
 └── src/

For production uses

• Use the system Caddyfile

• Managed by systemd or service manager

• Centralized configuration

/etc/caddy/Caddyfile

Typical workflow

Local dev → custom Caddyfile
Staging   → custom path
Production → default system path

This separation helps avoid accidental config changes in production.

6.3 Structure Tips for Large Configurations

As the number of sites increases, a single large Caddyfile can become hard to manage. Caddy provides simple tools to keep things organized.

Split configs using imports

import sites/*.caddy
import snippets/*.caddy

Example structure

caddy/
 ├── Caddyfile
 ├── sites/
 │   ├── blog.caddy
 │   ├── api.caddy
 │   └── dashboard.caddy
 └── snippets/
     ├── security.caddy
     ├── compression.caddy
     └── caching.caddy

Each site file contains only its site block:

blog.example.com {
    import security_headers
    import compression
    reverse_proxy localhost:3000
}

Using default paths keeps things simple, while custom paths and structured imports give you the flexibility needed for real-world applications. Caddy lets you start small and scale your configuration naturally — without rewriting everything later.

7. Setting Up Caddy on a Server

Okay, Let’s walk through a real-world server setup using caddy, where we will host a Laravel/PHP application and another is a static react application.

7.1 Installing Caddy on a Linux Server

To install Caddy on a Linux-based operating system, follow the installation part in this article above.

Enabling the Caddy service

Once installed, Caddy runs as a system service, we just need to start the service.

sudo systemctl enable caddy
sudo systemctl start caddy

Verify it’s running:

sudo systemctl status caddy

This makes Caddy suitable for long-running, unattended production systems.

Now you need to just point your domain to the server, like if your domain name is myblog.com and your API backend will be api.myblog.com then you need to point your DNS of this urls to your server like if your server IP address like this: 104.122.11.23 then your DNS record will be.

myblog.com      →  104.122.11.23
api.myblog.com  →  104.122.11.23

7.2 Hosting Multiple Websites on One Server

Assumptions

• Laravel is deployed at: /var/www/blog/laravel-app

• PHP-FPM is running (e.g. PHP 8.4)

• Laravel’s public directory is: /var/www/blog/laravel-app/public

• React build output is located at: /var/www/blog/react-app/dist

• App uses client-side routing (React Router)

Now let’s update our caddyfile, at first it will comes with some dummy code, let’s remove it and rewrite.

by running this command in your server terminal sudo nano /etc/caddy/Caddyfile the file will be open for edit. Now in this file remove all of it’s content and put the below code.

{
    email admin@example.com
}

myblog.com {
    root * /var/www/react-app/dist

    file_server
    encode zstd gzip

    try_files {path} /index.html
}

api.myblog.com {
    root * /var/www/blog/laravel-app/public

    php_fastcgi unix//run/php/php8.4-fpm.sock
    file_server

    encode zstd gzip
}

Now restart your caddy service by sudo systemctl restart caddy and your site will be live.

7.3 Caddy as a Reverse Proxy

In most cases, we use a reverse proxy in the server to run some dynamic applications. In such cases, Caddy provides a simple solution.

Let’s create a simple caddy proxy, where our application is serve by open it’s port to 3000.

Simple reverse proxy for port 3000

example.com {
    reverse_proxy localhost:3000
}

But most of the cases we do more like some health check, forwarding some headers also want to catch the error while the proxy is down or something wrong.

For this Let’s create a snippets for all of it configuration.

Backend Snippets (Advanced)

(proxy_backend) {
    reverse_proxy {args[0:]} {
        # Load balancing
        lb_policy least_conn

        # Health checks
        health_uri /up
        health_interval 10s
        health_timeout 5s
        health_status 2xx

        # Transport timeouts
        transport http {
            dial_timeout 2s
            response_header_timeout 30s
        }

        # Forward real client information
        # header_up Host {upstream_hostport}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-Port {server_port}
    }

    # Graceful fallback on upstream failure
    handle_errors {
        respond "Service temporarily unavailable. Please try again later." 503
    }
}

Now create another site with this proxy_backend snippet.

api.example.com {
    # For single upstream
    import proxy_backend localhost:4000

    # For multiple upstream
    import proxy_backend localhost:4400 localhost:4200
}

8. Running Caddy with Docker

The most straightforward way to begin using the Caddy server is by utilizing the official Docker image and running Caddy as a Docker container. This approach guarantees a smooth installation process that is also relatively straightforward to replicate on various systems.

8.1 Basic Docker Usage

Pull and run the official image

A practical baseline is: publish ports 80/443, mount your Caddyfile, mount your site files, and attach persistent volumes for /data and /config.

docker pull caddy:latest

Create a Caddyfile and run the command below after making changes in caddy file.

Caddyfile

localhost {
    tls internal
    root * /usr/share/caddy
    file_server
}

Then run this command.

docker run -d \
  --name caddy-server \
  -p 80:80 -p 443:443 -p 443:443/udp -p 8000:80 \
  -v $PWD/Caddyfile:/etc/caddy/Caddyfile:ro \
  -v caddy_data:/data \
  -v caddy_config:/config \
  --restart unless-stopped \
  caddy:latest

Then browse in your browser: https://localhost and you will see the caddy welcome page like below.

8.2 Docker Compose Multi-Site Setup

Okay, that’s a great start, right? Let’s move on to doing some real work.

Imagine our application architecture like this:

Browser
  ↓
Caddy (Edge / Gateway)
  ├── Static React build
  └── Reverse proxy → Node API container

First, create our actual project directory structure.

caddy-local/
├── docker-compose.yml
├── Caddyfile
└── sites/
    └── app/
        └── index.html
    └── api/
        ├── Dockerfile
        └── index.js

This keeps infra, config, and content properly decoupled.

docker-compose.yml (Single Source of Truth)

name: myapp

services:
  caddy:
    container_name: caddy
    image: caddy
    restart: always
    ports:
      - '80:80'
      - '443:443'
    volumes:
      - caddy-config:/config
      - caddy-data:/data
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./sites:/srv
    depends_on:
      - backend

  backend:
    build: ./sites/api
    container_name: node_backend
    expose:
      - "3000"

volumes:
  caddy-config:
  caddy-data:

In your Caddyfile

app.test {
    # React Router (SPA)
    root * /srv/app
    file_server
    try_files {path} /index.html

    # API
    handle_path /api/* {
        reverse_proxy backend:3000
    }

    tls internal
}

api.app.test {
    tls internal
    reverse_proxy backend:3000
}

API App dockerfile will be

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["npm", "start"]

Now we have to map the hosts to docker and local machine, so let’s do it by open hosts file sudo nano /etc/hosts

127.0.0.1 app.test
127.0.0.1 api.app.test

Then build and trust

docker compose up --build -d

docker exec -it caddy caddy trust

You can now access your site by your defined domain easily.

9. Using the Caddy API

Caddy isn’t just a static web server — its API allows you to change configuration dynamically without editing the Caddyfile or restarting the server. This is especially powerful for automated deployments, dynamic routing, and integrations with CI/CD pipelines.

9.1 What the API Does

The Caddy API provides endpoints to:

• Add, remove, or modify site blocks

• Enable or disable routes

• Adjust global settings (logging, TLS, compression)

• Inspect server status or loaded configuration

Unlike editing a Caddyfile manually, the API applies changes on-the-fly, making it ideal for automation

9.2 Practical Use Cases

Example 1: Dynamic Domain Addition

Imagine a SaaS platform where new users get custom subdomains. You can programmatically add routes via the API.

Request example (add new site block)

curl -X POST "http://localhost:2019/config/apps/http/servers/srv0/routes" \
  -H "Content-Type: application/json" \
  -d '{
    "match": [{"host": ["newuser.example.com"]}],
    "handle": [{
        "handler": "reverse_proxy",
        "upstreams": [{"dial": "127.0.0.1:4001"}]
    }]
}'

No restart or downtime is required.

Example 2: Automated Deployments

Suppose you deploy a new React frontend build. After uploading static files, you might want to:

• Clear cache rules

• Update file server paths

• Apply gzip or Brotli compression

Instead of editing the Caddyfile manually, you can send a POST request to the API to update the configuration automatically as part of your CI/CD pipeline.

curl -X POST "http://localhost:2019/config/apps/http/servers/srv0/routes" \
  -H "Content-Type: application/json" \
  -d '{
    "match": [{"host": ["app.example.com"]}],
    "handle": [{
        "handler": "file_server",
        "root": "/srv/react-dist-new"
    }]
}'

Example 3: On-the-Fly Routing Changes

If an upstream service fails or you want blue-green deployments, the API can redirect traffic dynamically:

curl -X POST "http://localhost:2019/config/apps/http/servers/srv0/routes" \
  -H "Content-Type: application/json" \
  -d '{
    "match": [{"host": ["api.example.com"]}],
    "handle": [{
        "handler": "reverse_proxy",
        "upstreams": [{"dial": "127.0.0.1:5000"}]
    }]
}'

The switch is instantaneous, and old traffic is immediately routed to the new backend.

9.3 Securing the API

Because the API allows full configuration changes, security is critical.

Best practices:

1. Bind to localhost or private network

{
  "admin": {
    "listen": "127.0.0.1:2019"
  }
}

Never expose the API directly to the public internet.

2. Use firewall rules or VPN

   • Only trusted servers or CI/CD runners should access the API.

3. Authentication

   • For production, consider using a reverse proxy in front of the API with basic auth or token validation.

4. Audit changes

   • Log all API requests.

   • Optionally, integrate with monitoring tools to detect unexpected modifications.

10. Best Practices

When working with Caddy, following a few simple best practices can make your configuration easier to maintain and your server more reliable.

Use Snippets Where Possible

Snippets are reusable blocks of configuration. For example, you can create a snippet for security headers, caching rules, or reverse proxy settings and then include it in multiple site blocks. This avoids repetition and keeps your Caddyfile clean. Instead of copying the same directives across many sites, just import the snippet wherever you need it.

Keep Site Blocks Readable

Even with multiple sites, try to organize your Caddyfile clearly. Group related settings together, use comments to explain why certain directives are there, and separate large configurations into multiple files if needed. Readable configuration makes it much easier to troubleshoot issues or onboard new team members.

Avoid Unnecessary Directives

Only include the directives your site actually needs. Extra or unused settings can confuse Caddy or create unexpected behavior. Focus on what matters for each site: SSL, reverse proxy targets, caching, and logging. Minimal, precise configuration is easier to manage and less prone to errors.

Enable Logging and Monitoring

Always enable access and error logs, even in development. Logs help you understand traffic patterns, catch issues early, and debug problems quickly. For production setups, consider combining Caddy logs with monitoring tools to get alerts when a site is down or an upstream service is failing.

By following these practices, you can build scalable, maintainable, and reliable Caddy configurations, whether you’re hosting a single site or dozens of applications.

11. Common Pitfalls & How to Avoid Them

Even though Caddy is beginner-friendly, there are a few common mistakes that can trip up developers and system administrators. Knowing these in advance will save you a lot of time and frustration.

1. DNS Issues

Caddy relies on DNS to issue certificates and route traffic. If your domain doesn’t point to the correct server, automatic HTTPS will fail, or users won’t reach your site.

How to avoid:

• Double-check A/AAAA records for your domains.

• For subdomains, ensure they’re correctly set in DNS.

• Use dig or nslookup to verify the records before starting Caddy.

• For local development, check your /etc/hosts file.

2. Wrong File Permissions

Caddy needs proper access to site files, Caddyfile, and data directories. If permissions are too restrictive, Caddy may fail to serve files or write certificates.

How to avoid:

• Ensure the Caddy user (or container user) can read site files and write to /data and /config.

• On Linux: chown -R caddy:caddy /srv /etc/caddy /data /config

• Avoid giving overly broad permissions; balance security and accessibility.

3. Misconfigured Docker Paths

When running Caddy in Docker, it’s common to mount the wrong paths or forget to include volumes for /data and /config. This can lead to missing TLS certificates or failed site builds.

How to avoid:

• Mount your Caddyfile and site directories correctly:

- ./Caddyfile:/etc/caddy/Caddyfile:ro
- ./site:/srv:ro
- caddy_data:/data
- caddy_config:/config

• Always use persistent volumes for certificates to prevent re-issuing on container restart.

4. Forgetting to Reload Config

Caddy can apply configuration dynamically via the API or Caddyfile reload, but forgetting to reload after edits means your changes won’t take effect.

How to avoid:

• Use caddy reload after editing Caddyfile:

caddy reload --config /etc/caddy/Caddyfile

• For Docker, you can reload inside the container:

docker exec caddy caddy reload --config /etc/caddy/Caddyfile

• For automated workflows, consider using the Caddy API to apply changes on-the-fly.

12. Conclusion

Caddy offers a refreshing approach to web servers. Unlike traditional servers that require long, complex configurations and manual SSL management, Caddy makes it easy to get sites up and running with automatic HTTPS, clean configuration syntax, and built-in features like reverse proxying, load balancing, and file serving.

Its simplicity reduces developer overhead, letting you focus on building applications instead of fighting with server setups. Whether you’re working on a local development environment for a Laravel or React app, or deploying multiple sites in production, Caddy handles the heavy lifting behind the scenes — TLS, routing, and health checks are taken care of automatically.

For developers and teams who value speed, security, and maintainability, trying Caddy is a no-brainer. Start small with a local project, explore snippets, multi-site configurations, and the API, and you’ll quickly see why many consider it one of the most developer-friendly web servers available today.

Give it a try — you might never look back at traditional web servers again. If you need more help or suggestions, please don’t hesitate to ask me. I’d be more than happy to assist you.

Resources:

• https://caddyserver.com/docs/getting-started

• https://betterstack.com/community/guides/web-servers/caddy/

• https://caddyserver.com/docs/api

• Custom snippets

The Problem

Before my solution, every time I encountered a new file type—say, a .tsx React file, a .dockerignore config, or even obscure extensions like .erl for Erlang—I had to manually set the default app for that format. It was slow and tedious, and often required digging into system settings or context menus. As my project stack grew to include new languages and frameworks, this became unmanageable.

The Solution

I decided to automate the entire process using a purpose-built Bash script and the macOS tool duti. duti allows command-line management of file associations, making it perfect for bulk operations.

Building the Script

The heart of the solution lay in combining two ideas:

• A comprehensive list of extensions relevant to software engineering (covering everything from .c for C, .py for Python, to .yaml for config files).

• Automation with Bash, looping through the list and setting Zed as the default app for each file type.

Here’s the script I used:

#!/bin/bash
# My Editor Id, you can get your desired editor id by running `osascript -e 'id of app "Visual Studio Code"'`
ZED_ID="dev.zed.Zed"

EXTENSIONS=(
  "c" "cpp" "cc" "h" "hpp"
  "java" "class"
  "js" "jsx" "ts" "tsx"
  "py" "pyw"
  "rb"
  "sh" "bash"
  "bat" "cmd"
  "go"
  "php"
  "swift"
  "cs"
  "pl" "pm"
  "lua"
  "kt" "kts"
  "scala"
  "rs"
  "r"
  "dart"
  # skip this cause it should open in browser by default
  # "html" "htm" "xhtml"
  "xml" "json" "yml" "yaml"
  "css" "scss" "sass" "less"
  "md"
  "sql"
  "asm" "s"
  "m" "mm"
  "ex" "exs"
  "erl"
  "hs"
  "lisp" "cl"
  "groovy"
  "fs" "fsi" "fsx"
  "vue"
  "coffee"
  "ini" "conf" "cfg" "toml" "env"
  "dockerfile" "dockerignore"
  "gemspec" "gradle" "pom.xml"
  "lock" "package" "yarn.lock"
  "pbxproj" "xcworkspace" "xcodeproj"
  "sln" "csproj" "vbproj"
  "make" "mak" "mk"
  "gitignore" "gitattributes"
  "proto"
  "f90" "f" "for"
  "pas"
  "adb" "ads"
  "matlab"
  "ps1"
  "hbs"
  "jade" "pug"
  "ejs"
  "tpl"
)
for ext in "${EXTENSIONS[@]}"; do
  duti -s "$ZED_ID" .$ext all
done

echo "All specified code file extensions are now set to open with Zed."

How It Worked

• Single command execution: Instead of manually changing settings for each extension, I saved this script as associate_zed.sh, made it executable, and ran it once.

• Instant results: Every file with an extension in the list now opens seamlessly in Zed across Finder and other apps.

• Easy maintenance: If I start working in a new language, I just add its extension to the EXTENSIONS array and rerun the script.

Impact on My Workflow

• No more interruptions: I never have to deal with files opening in the wrong editor or having to right-click and choose "Open With..." ever again.

• Onboarding made easy: Sharing the script with teammates lets everyone standardize their dev environment with a single command.

• Adaptable: If I ever switch to a different editor, I only need to change the ZED_ID variable.

Conclusion

Automating file extension associations rescued me from a frustrating, repetitive setup process and turned onboarding into a breeze. For anyone who spends their day immersed in code across a spectrum of formats, this simple Bash script is a game-changer.

The time saved lets me focus on actual engineering work—not wrangling file associations. If you’re using Zed (or any editor), I highly recommend this approach to dramatically simplify your dev environment setup.

You can find my code in this gist also.

What if I told you there's a better way? A way to make your release process seamless, consistent, and fully automated. In this article, I'll walk you through how I automated the entire release workflow for my project, "Bill Organizer," a Laravel and Vue.js application. We'll take a deep dive into the GitHub Actions workflow I created, breaking it down step-by-step, and exploring the "how," the "what," and the "why" behind it.

By the end of this article, you'll have a clear understanding of how to build your own automated release pipeline, saving you time, reducing the risk of human error, and allowing you to focus on what you do best: writing code.

The Problem with Manual Releases

Before we jump into the solution, let's talk about the pain points of manual releases. If you've ever been responsible for deploying an application, some of these might sound familiar:

• Time-Consuming: The process of pulling the latest code, installing dependencies, building assets, running tests, versioning, creating a changelog, and finally deploying can take a significant amount of time.

• Error-Prone: With so many steps involved, it's easy to make a mistake. Forgetting to install a dependency, building with the wrong environment variables, or making a typo in a version number can all lead to a broken release.

• Inconsistent: When different team members handle releases, they might do things slightly differently. This can lead to inconsistencies in your build artifacts and release notes.

• Lack of Visibility: It can be difficult to track what's in each release, especially if you're not diligent about keeping a changelog.

Automating your release process helps to solve all of these problems. It ensures that every release is built and deployed in exactly the same way, every single time.

The Goal: A Fully Automated Release Pipeline

For my "Bill Organizer" project, I had a clear set of goals for my automated release system:

1. Trigger on Push to main: I wanted the release process to kick off automatically every time I pushed new commits to the main branch.

2. Semantic Versioning: I wanted to automatically generate a new semantic version number (e.g., v1.2.3) for each release, incrementing the patch version each time.

3. Build for Production: The workflow should install all the necessary dependencies (both PHP and Node.js), build the frontend assets, and create a production-ready application.

4. Create a Production Archive: The system should generate a clean, production-only .zip archive, excluding all development files and dependencies.

5. Generate a GitHub Release: A new draft release should be created on GitHub for each new version.

6. Automated Changelog: The release notes should automatically include a list of all the commit messages since the last release.

7. Upload Artifacts: The .zip archive should be uploaded as an artifact to the GitHub release.

With these goals in mind, I turned to GitHub Actions, a powerful and flexible CI/CD platform that's built right into GitHub.

The Workflow: A Step-by-Step Breakdown

Let's dive into the release.yml workflow file and break down each section.

name: Release

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  contents: write
  packages: write

jobs:
  release:
    runs-on: ubuntu-latest

Triggering the Workflow

The on section defines when the workflow will run. In this case, it's triggered in two ways:

• push: branches: [main]: This is the primary trigger. Every time new commits are pushed to the main branch, this workflow will be executed. This is the heart of our continuous delivery pipeline.

• workflow_dispatch:: This allows me to trigger the workflow manually from the GitHub UI. This is useful for re-running a release or for testing purposes.

Permissions

The permissions block is crucial for security. It defines the permissions that the GITHUB_TOKEN will have for this workflow. By default, the token is read-only. We need to grant it some write permissions:

• contents: write: This is required to create a GitHub release and to push tags.

• packages: write: This is necessary if you're publishing packages to the GitHub Package Registry. While not strictly used for creating a release, it's good practice to have if you plan to extend your workflow in the future.

The release Job

Now we get to the meat of the workflow: the release job. This job runs on ubuntu-latest, which is a virtual machine hosted by GitHub.

1. Checking Out the Code

- name: Checkout repository
  uses: actions/checkout@v4
  with:
    fetch-depth: 0

The first step is to check out the repository's code. We use the actions/checkout@v4 action for this. The with: fetch-depth: 0 parameter is very important here. By default, checkout only fetches the latest commit. fetch-depth: 0 tells the action to fetch the entire Git history, including all tags. We need this for our semantic versioning step later on.

2. Setting Up the Environment

Next, we need to set up the build environment with all the necessary tools and dependencies.

- name: Setup PHP 8.3
  uses: shivammathur/setup-php@v2
  with:
    php-version: '8.3'
    tools: composer:v2
    extensions: bcmath, ctype, fileinfo, json, mbstring, openssl, pdo, tokenizer, xml, zip

- name: Get Composer cache directory
  id: composer-cache
  run: echo "dir=$(composer config cache-files-dir)" >> $GITHUB_OUTPUT

- name: Cache Composer dependencies
  uses: actions/cache@v4
  with:
    path: ${{ steps.composer-cache.outputs.dir }}
    key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
    restore-keys: ${{ runner.os }}-composer-

- name: Setup Node.js
  uses: actions/setup-node@v4
  with:
    node-version: '22'
    cache: 'yarn'

• Setup PHP: We use the shivammathur/setup-php@v2 action to install PHP 8.3, Composer v2, and all the required PHP extensions for our Laravel application.

• Cache Composer Dependencies: Caching is a key optimization technique in CI/CD pipelines. We first get the Composer cache directory, then use the actions/cache@v4 action to cache our Composer dependencies. The key is generated based on the operating system and a hash of the composer.lock file. If the composer.lock file hasn't changed, the cache will be restored, saving us from having to download all the dependencies again.

• Setup Node.js: Similarly, we use the actions/setup-node@v4 action to install Node.js 22. The cache: 'yarn' option automatically handles caching for our Yarn dependencies.

3. Building the Application

With our environment set up, it's time to build the application.

- name: Install Composer dependencies
  run: composer install --no-dev --optimize-autoloader --no-interaction --prefer-dist

- name: Install Yarn dependencies
  run: yarn install --frozen-lockfile

- name: Copy environment file
  run: cp .env.example .env

- name: Generate application key
  run: php artisan key:generate

- name: Publish Ziggy configuration
  run: php artisan ziggy:generate

- name: Type check TypeScript files
  run: yarn lint

- name: Build frontend assets
  run: yarn build

This is a series of standard build steps for a Laravel and Vue.js application:

• We install Composer dependencies with --no-dev to exclude development packages, and --optimize-autoloader for better performance.

• We install Yarn dependencies using --frozen-lockfile to ensure we're using the exact versions specified in our yarn.lock file.

• We then run our Laravel-specific build commands, such as generating an application key and publishing the Ziggy configuration.

• Finally, we run yarn lint to check for any TypeScript errors and yarn build to compile our frontend assets for production.

4. Semantic Versioning

This is where the magic happens. This step automatically determines the next version number.

- name: Generate semantic version
  id: version
  run: |
    # Get the latest tag
    LATEST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "v0.0.0")
    echo "Latest tag: $LATEST_TAG"

    # Remove 'v' prefix if it exists
    LATEST_VERSION=${LATEST_TAG#v}

    # Split version into parts
    IFS='.' read -ra VERSION_PARTS <<< "$LATEST_VERSION"
    MAJOR=${VERSION_PARTS[0]:-0}
    MINOR=${VERSION_PARTS[1]:-0}
    PATCH=${VERSION_PARTS[2]:-0}

    # Increment patch version
    NEW_PATCH=$((PATCH + 1))
    NEW_VERSION="v${MAJOR}.${MINOR}.${NEW_PATCH}"

    echo "New version: $NEW_VERSION"
    echo "version=$NEW_VERSION" >> $GITHUB_OUTPUT
    echo "version_number=${MAJOR}.${MINOR}.${NEW_PATCH}" >> $GITHUB_OUTPUT

Here's how it works:

1. git describe --tags --abbrev=0: This command finds the most recent tag in the Git history. If no tags are found, it defaults to v0.0.0.

2. We then parse this tag, split it into major, minor, and patch components.

3. We increment the patch version by one.

4. Finally, we construct the new version string (e.g., v1.2.4) and output it as version and version_number for use in later steps. We use id: version to be able to reference these outputs later with steps.version.outputs.version.

5. Creating the Production Archive

Now that our application is built and we have a new version number, we need to package it up into a clean, production-ready archive.

- name: Create production archive
  run: |
    # ... (rsync, composer install, cleanup, and zip commands) ...

This step is quite long, but it's doing some very important things:

• It creates a temporary directory.

• It uses rsync to copy all the application files, but it excludes all development-related files and directories like .git, node_modules, vendor, tests, etc. This ensures our archive is as small and clean as possible.

• It then cds into this temporary directory and runs composer install --no-dev again. This is crucial because it installs only the production dependencies inside our clean archive directory.

• It performs some final cleanup, creates necessary directories, sets the correct permissions, and then creates a .zip archive named with the new version number (e.g., bill-organizer-1.2.4.zip).

6. Creating the GitHub Release

This is the final and most rewarding part of the workflow.

- name: Delete existing draft release with same version (if any)
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: |
    # ... (gh release list and delete commands) ...

- name: Create Draft Release
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: |
    # ... (gh release create command) ...

We use the official GitHub CLI (gh) to interact with the GitHub API.

• Delete Existing Draft: First, we have a neat little step that checks if there's already a draft release with the same version tag. If there is, it deletes it. This is useful if you have to re-run the workflow, as it prevents you from having multiple draft releases for the same version.

• Create Draft Release: This is the main event.

  • We use git log to get all the commit messages since the last tag. This will be our automated changelog.

  • We then use gh release create to create a new draft release.

  • We pass the new version tag, the path to our .zip archive, and a title for the release.

  • The --notes flag is where we construct our detailed release notes. We include the new version number, the auto-generated changelog, installation instructions, and build information.

7. Uploading Build Artifacts

- name: Upload build artifacts
  uses: actions/upload-artifact@v4
  with:
    name: bill-organizer-${{ steps.version.outputs.version_number }}
    path: bill-organizer-${{ steps.version.outputs.version_number }}.zip
    retention-days: 30

Finally, we use the actions/upload-artifact@v4 action to upload our .zip archive as a build artifact. This is useful for debugging purposes and for keeping a record of all the builds.

The Result: A Seamless Release Experience

And that's it! With this workflow in place, my release process is now completely automated. Every time I push to main, a new, versioned, and production-ready release is created, complete with a changelog and a downloadable artifact.

This has been a game-changer for my development workflow. I no longer have to worry about the tedious and error-prone process of manual releases. I can simply push my code and be confident that a new release will be built and ready to go, allowing me to focus on what I love: building great software.

If you're still doing manual releases, I highly encourage you to explore GitHub Actions and build your own automated release pipeline. It's an investment that will pay for itself many times over in saved time, reduced stress, and more consistent, reliable releases.

You can download the full release.yml file from here.

In this article, you'll learn how to set up:

• ✅ bookmark [name] — Save the current directory under a friendly name

• ✅ goto [name] — Jump directly to a bookmarked folder (or interactively pick one)

• ✅ 🧠 Tab-autocomplete — Auto-suggest bookmark names with <TAB>

Let’s get started.

📁 1. Add Bookmarking Script to Your Shell

Add the following code to your ~/.bashrc (or ~/.zshrc if you use Zsh):

source ~/.bookmark

Now create a file in your home directory, ~/.bookmark and put these code in there.

# Bookmark storage file
BOOKMARKS_FILE="$HOME/.folder_bookmarks"

# Save current directory with a name
bookmark() {
    local name="$1"

    if [ -z "$name" ]; then
        echo -n "Enter bookmark name: "
        read name
    fi

    if [ -z "$name" ]; then
        echo "Bookmark name cannot be empty."
        return 1
    fi

    mkdir -p "$(dirname "$BOOKMARKS_FILE")"

    # Remove any existing entry with the same name
    grep -v "^$name|" "$BOOKMARKS_FILE" 2>/dev/null > "${BOOKMARKS_FILE}.tmp"
    mv "${BOOKMARKS_FILE}.tmp" "$BOOKMARKS_FILE"

    # Save the new bookmark
    echo "$name|$PWD" >> "$BOOKMARKS_FILE"
    echo "Bookmarked '$PWD' as '$name'"
}

# Navigate to a bookmarked directory
goto() {
    local name="$1"

    if [ ! -f "$BOOKMARKS_FILE" ]; then
        echo "No bookmarks found."
        return 1
    fi

    local dir

    if [ -n "$name" ]; then
        dir=$(grep "^$name|" "$BOOKMARKS_FILE" | cut -d'|' -f2)
        if [ -z "$dir" ]; then
            echo "Bookmark '$name' not found."
            return 1
        fi
    else
        # Interactive prompt using fzf
        local selection
        selection=$(awk -F '|' '{ printf "%s\t%s\n", $1, $2 }' "$BOOKMARKS_FILE" | fzf --prompt="Goto bookmark: " --with-nth=1)
        if [ -z "$selection" ]; then
            echo "No selection made."
            return 1
        fi
        dir=$(echo "$selection" | cut -f2)
    fi

    if [ -d "$dir" ]; then
        cd "$dir"
    else
        echo "Directory does not exist: $dir"
    fi
}

# Autocomplete function for goto
_goto_complete() {
    local cur_word bookmarks
    cur_word="${COMP_WORDS[COMP_CWORD]}"
    if [ -f "$BOOKMARKS_FILE" ]; then
        bookmarks=$(cut -d'|' -f1 "$BOOKMARKS_FILE")
        COMPREPLY=( $(compgen -W "$bookmarks" -- "$cur_word") )
    fi
}

# Register autocomplete for goto
complete -F _goto_complete goto

Download the file from here.

🧠 3. How It Works — Code Explanation

Let’s break down how the bookmark and goto functions work under the hood, along with tab completion logic.

📌 BOOKMARKS_FILE="$HOME/.folder_bookmarks"

This defines where all bookmarks will be saved — a simple text file where each line stores:

name|/absolute/path/to/folder

Example:

projectX|/home/user/code/projectX
work|/home/user/workspace

This file is used for reading and writing bookmark data.

💾 The bookmark Function

bookmark() {
    local name="$1"

    if [ -z "$name" ]; then
        echo -n "Enter bookmark name: "
        read name
    fi

• If a name is passed as an argument, it's used.

• If not, the user is prompted to enter one.

    if [ -z "$name" ]; then
        echo "Bookmark name cannot be empty."
        return 1
    fi

• Ensures that an empty name isn’t saved.

    mkdir -p "$(dirname "$BOOKMARKS_FILE")"

• Makes sure the folder for the bookmarks file exists (mostly redundant but safe).

    grep -v "^$name|" "$BOOKMARKS_FILE" 2>/dev/null > "${BOOKMARKS_FILE}.tmp"
    mv "${BOOKMARKS_FILE}.tmp" "$BOOKMARKS_FILE"

• Removes any previous entry with the same name, so each bookmark name is unique.

    echo "$name|$PWD" >> "$BOOKMARKS_FILE"
    echo "Bookmarked '$PWD' as '$name'"

• Appends the new bookmark as name|directory to the file.

🚀 The goto Function

goto() {
    local name="$1"

    if [ ! -f "$BOOKMARKS_FILE" ]; then
        echo "No bookmarks found."
        return 1
    fi

• If the bookmarks file doesn’t exist, it aborts.

📥 Option 1: Name is Given

    if [ -n "$name" ]; then
        dir=$(grep "^$name|" "$BOOKMARKS_FILE" | cut -d'|' -f2)
        if [ -z "$dir" ]; then
            echo "Bookmark '$name' not found."
            return 1
        fi

• Searches the file for the bookmark and extracts the path.

• If the name doesn’t match, shows an error.

📥 Option 2: No Name Provided

    else
        local selection
        selection=$(awk -F '|' '{ printf "%s\t%s\n", $1, $2 }' "$BOOKMARKS_FILE" | fzf --prompt="Goto bookmark: " --with-nth=1)

• Uses fzf to display an interactive list in the terminal.

• Shows bookmarks in the format: name /path.

        dir=$(echo "$selection" | cut -f2)

• Extracts the selected path after the user chooses.

📂 Navigate to the Folder

    if [ -d "$dir" ]; then
        cd "$dir"
    else
        echo "Directory does not exist: $dir"
    fi
}

• Navigates to the directory if it still exists.

• Shows an error if the path was deleted or moved.

🔄 Tab Completion for goto

For Bash:

_goto_complete() {
    local cur_word bookmarks
    cur_word="${COMP_WORDS[COMP_CWORD]}"
    bookmarks=$(cut -d'|' -f1 "$BOOKMARKS_FILE")
    COMPREPLY=( $(compgen -W "$bookmarks" -- "$cur_word") )
}
complete -F _goto_complete goto

• Uses Bash’s complete system.

• Pulls all bookmark names from the file and offers them as suggestions when the user presses <TAB>.

For Zsh, a similar logic is used with compctl.

✅ Summary

This approach is simple, portable, and doesn't require any external frameworks — just Bash and fzf.

Would you like a downloadable .sh version or install script for easy sharing?

⚙️ 3. Requirements

This setup uses fzf for fuzzy searching when goto is called without a name.

Install it using:

# macOS
brew install fzf

# Ubuntu/Debian
sudo apt install fzf

Or install manually:

git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf
~/.fzf/install

🚀 Usage Examples

bookmark project-alpha    # Save current directory as 'project-alpha'
goto project-alpha        # Jump to 'project-alpha'

bookmark                  # Prompts for a name
goto                      # Use fuzzy search to select one

Hit <TAB> after typing goto to autocomplete available bookmarks!

📌 Conclusion

With just a few lines of Bash and the power of fzf, you now have a fast, flexible, and friendly way to bookmark and navigate your filesystem. Whether you're managing multiple projects, deep folder hierarchies, or just want to speed up your workflow, this setup keeps your terminal navigation blazing fast.

Happy hacking! ⚡

In an age where digital services are the lifeblood of our personal and professional lives, it's easy to lose track of the ever-growing list of recurring payments. From streaming services and software subscriptions to monthly utilities, managing bills has become a complex and often stressful task. Missing a payment can lead to service interruptions or late fees, while forgetting to cancel an unused subscription can quietly drain your bank account.

This is the problem that Bill Organizer, an open-source application, sets out to solve. Built with a modern tech stack for performance and scalability, it offers a streamlined, self-hostable solution to take control of your financial obligations. This article will take you on a tour of the Bill Organizer project, exploring its architecture, how it works under the hood, and how you can become part of its journey through open-source contribution.

What is Bill Organizer?

At its core, Bill Organizer is a user-friendly platform designed to help you manage all your bills and subscriptions in one centralized place. It provides a clear and intuitive interface to track due dates, payment amounts, and payment history, ensuring you never miss a beat.

The project is built on the philosophy that financial management tools should be accessible, private, and powerful. By being open-source, it offers complete transparency and gives users the freedom to host their own instance, ensuring their sensitive financial data remains under their control.

Core Features:

• Centralized Dashboard: Get an at-a-glance overview of your upcoming bills, recent payments, and spending trends.

• Bill & Subscription Tracking: Easily add, edit, and manage all your recurring payments, from monthly subscriptions to annual renewals.

• Smart Categorization: Organize your bills into categories (e.g., "Entertainment," "Utilities," "Work Software") to better understand your spending habits.

• Payment History: Keep a log of all past payments for easy reference and financial auditing.

• Due Date Reminders: Receive timely notifications for upcoming bills, helping you avoid late fees and plan your finances accordingly.

• Currency Support: Manage bills in different currencies, making it suitable for users worldwide.

A Look Under the Hood: The Technology Stack

Bill Organizer is crafted using a powerful combination of modern web technologies, chosen specifically for their robustness, developer experience, and performance. This "modern monolith" architecture combines the power of a traditional server-rendered application with the seamless, dynamic experience of a single-page application (SPA).

Backend: The Power of Laravel 12

The entire backend is powered by Laravel, the latest version of the popular PHP framework. Laravel is renowned for its elegant syntax, robust feature set, and strong security foundations.

• Why Laravel? It provides a solid foundation with built-in features for routing, database management (through its Eloquent ORM), authentication, and more. This allows developers to focus on building core application features rather than reinventing the wheel.

• API & Web Routes: The application uses a combination of web and API routes to handle requests. The core of the application's interactivity is managed through web routes that are tightly integrated with the frontend via Inertia.

Here is a glimpse of how a route is defined in Laravel to fetch data for the frontend:

// routes/web.php

use App\Http\Controllers\BillController;

Route::get('/bills', [BillController::class, 'index'])
    ->name('bills.index');

This simple line of code maps a URL to a controller method that fetches bill data and renders the corresponding Vue component, all in one go.

Frontend: A Dynamic Experience with Vue.js 3

The user interface is a highly interactive SPA built with Vue.js 3. Vue is a progressive JavaScript framework that is approachable, performant, and versatile.

• Component-Based Architecture: The UI is broken down into reusable components (e.g., BillTable, AddBillModal, DashboardChart). This makes the codebase organized, maintainable, and easy to scale.

• Reactivity: Vue's reactivity system automatically updates the UI whenever the underlying data changes, providing a smooth and responsive user experience without manual DOM manipulation.

Here's a simplified snippet of what a Vue component for displaying a list of bills might look like:

// resources/js/Pages/Bills/Index.vue

<script setup lang="ts">
import { defineProps } from 'vue';

// Props are passed down from the Laravel controller
const props = defineProps({
  bills: Array,
  totalDue: Number,
});
</script>

<template>
  <h1>My Bills</h1>
  <div v-for="bill in props.bills" :key="bill.id">
    <p>{{ bill.name }}: ${{ bill.amount }}</p>
  </div>
  <strong>Total Due: ${{ props.totalDue }}</strong>
</template>

The Bridge: Inertia.js

The magic that connects the Laravel backend and Vue.js frontend is Inertia.js. It's not a framework itself, but a routing library that allows you to create modern, single-page Vue applications using classic server-side routing.

• How it Works: When you navigate to a page, your Laravel application handles the request, fetches the necessary data, and instead of returning a JSON API response, it returns a full Vue component with the data passed as "props". This gives you the best of both worlds: the development speed of a monolith and the user experience of an SPA.

Development and Tooling

The project is committed to a high standard of code quality and a smooth developer experience, enforced by modern tooling:

• Vite: A next-generation frontend build tool that provides lightning-fast hot module replacement (HMR) for a highly productive development workflow.

• TypeScript: The entire frontend codebase uses TypeScript, adding static type safety to prevent common errors and improve code maintainability.

• PHPStan & Pint: For the backend, PHPStan is used for static analysis to catch bugs before they reach production, while Pint automatically formats the PHP code to ensure a consistent style.

• ESLint & Prettier: These tools enforce a consistent coding style and catch potential issues in the TypeScript and Vue code.

How It Works: The User Journey

Let's walk through a typical user flow to understand how these technologies come together.

1. Viewing the Dashboard: When a user logs in, they are directed to the dashboard.

• The Laravel router catches the /dashboard request.

• The DashboardController fetches key data: upcoming bills, total unpaid amount, and recent payments.

• Laravel renders the Dashboard.vue component, passing the data as props via Inertia.

• The Vue component displays the data, perhaps using charts (powered by a library like ApexCharts) and summary cards.

2. Adding a New Bill: A user clicks the "Add Bill" button.

• This action likely opens a modal window (AddBillModal.vue) directly on the frontend.

• The user fills out a form with details like the bill's name, amount, due date, and category. This form is managed by VeeValidate for real-time validation.

• Upon submission, an API request is sent to a Laravel endpoint (e.g., POST /bills).

• The BillController validates the incoming data and creates a new record in the bills database table.

• After successfully creating the bill, Laravel redirects the user back to the bills list, and Inertia automatically fetches the updated data, causing the UI to update seamlessly.

3. Marking a Bill as Paid: A user wants to mark a bill as paid.

• They click a "Mark as Paid" button next to a bill in the list.

• A PATCH or PUT request is sent to an endpoint like /bills/{bill}/pay.

• The BillController updates the bill's status in the database.

• The frontend immediately reflects this change, perhaps moving the bill to a "Paid" section or changing its visual style.

4. Creating and Managing a Team: A user wants to manage bills with their family or business partners.

• The user navigates to the "Team Settings" area. This loads a TeamSettings.vue component.

• They click "Create New Team" and enter a name, like "Household Bills" or "Startup Subscriptions."

• On submission, a request hits the TeamController in Laravel, which creates a new team and assigns the user as the owner.

• Now in the team management view, the user can invite others by entering their email addresses. An API call to POST /teams/{team}/invitations sends out invitations.

• Invited users receive an email and an in-app notification. Accepting the invite adds them to the team.

• The team owner can now share bills with the team and assign different roles (e.g., 'Admin', 'Member') to control who can add or modify bills, creating a collaborative financial management space.

To get more details of the application: browse the live link and use it. (http://bills.msar.me/)

Open for Contribution: Let's Build It Together!

Bill Organizer is more than just a tool; it's a community-driven project. Whether you are a seasoned developer, a student looking to build your portfolio, or someone passionate about open source, your contributions are welcome.

We believe that collaboration is the key to creating robust and meaningful software. By contributing, you can help fix bugs, add new features, improve the documentation, and shape the future of the project.

How to Get Started

1. Explore the Repository: The first step is to visit the GitHub repository. Read the README.md file to understand the project setup and installation instructions.

2. Find an Issue: Check out the "Issues" tab. We use labels like good first issue and help wanted to highlight tasks that are perfect for new contributors.

3. Set Up Your Environment: Follow the local development setup guide. The project uses Laravel Sail and Yarn to make this process as smooth as possible. With a few simple commands, you'll have a fully functional development environment running on your machine.

4. Create a Pull Request: Once you've made your changes, submit a pull request (PR). Be sure to describe the changes you've made and reference the issue you're solving. Your PR will be reviewed by the maintainers, who will provide feedback and guide you through the process.

What We Need

We are looking for help in all areas, including:

• Feature Development: Have an idea for a new feature? Propose it in an issue and help us build it!

• Bug Fixes: Help us improve the stability of the application by tackling existing bugs.

• Refactoring & Performance: Improve the codebase by refactoring or optimizing performance-critical sections.

• Documentation: Good documentation is crucial. Help us improve our guides and inline code comments.

• Testing: Writing automated tests is essential for long-term stability. We use Pest for our PHP tests.

Join us in building the best open-source tool for managing personal finances. Your skills and ideas can make a real impact. Let's tame the chaos of bills, together!

Laravel is one of the most popular PHP frameworks, known for its elegant syntax and powerful tools that simplify web development. One of the strengths of Laravel is its flexibility and extensibility, allowing developers to create custom packages to extend the functionality of their applications. In this article, we'll explore the steps involved in creating a PHP package in Laravel, complete with examples and references.

Why Create a Laravel Package?

Creating a Laravel package is beneficial when you have functionality that you want to reuse across multiple projects. Instead of duplicating code, you can encapsulate it within a package that can be easily installed and maintained.

Some common use cases for Laravel packages include:

• Custom authentication systems

• Reusable UI components

• API integrations

• Command-line tools

Step 1: Setting Up the Package

To begin, you'll need to create a directory for your package. Laravel suggests placing your packages within the packages directory in the root of your Laravel project.

mkdir packages/YourVendorName/YourPackageName
cd packages/YourVendorName/YourPackageName

Here, YourVendorName represents the vendor or author of the package (usually your or your company’s name), and YourPackageName is the name of the package.

Next, you need to create the composer.json file, which defines the package's dependencies and metadata.

{
    "name": "your-vendor-name/your-package-name",
    "description": "A short description of your package",
    "authors": [
        {
            "name": "Your Name",
            "email": "your-email@example.com"
        }
    ],
    "autoload": {
        "psr-4": {
            "YourVendorName\\YourPackageName\\": "src/"
        }
    }
}

This composer.json file tells Composer (PHP’s dependency manager) how to autoload your package and its dependencies.

Step 2: Developing the Package

Inside the src directory, you can start developing your package. Let’s say you want to create a package that adds a custom greeting service to your Laravel application.

First, create a service provider. Service providers are the central place of configuration in a Laravel application.

// src/GreetingServiceProvider.php

namespace YourVendorName\YourPackageName;

use Illuminate\Support\ServiceProvider;

class GreetingServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->app->singleton('greeting', function ($app) {
            return new GreetingService();
        });
    }

    public function boot()
    {
        // Bootstrapping package functionalities (routes, views, etc.)
    }
}

Next, create the GreetingService class.

// src/GreetingService.php

namespace YourVendorName\YourPackageName;

class GreetingService
{
    public function greet($name)
    {
        return "Hello, $name!";
    }
}

The service provider registers the GreetingService so that it can be easily accessed throughout your Laravel application.

Step 3: Registering the Package

To make Laravel aware of your package, you need to add the service provider to the config/app.php file in the providers array.

'providers' => [
    // Other Service Providers

    YourVendorName\YourPackageName\GreetingServiceProvider::class,
],

Now, you can use your package within the Laravel application:

Route::get('/greet/{name}', function ($name) {
    return app('greeting')->greet($name);
});

Step 4: Publishing Package Assets (Optional)

If your package includes configuration files, views, or other assets that need to be published to the main Laravel project, you can use the publishes method in your service provider.

public function boot()
{
    $this->publishes([
        __DIR__.'/path/to/config/greeting.php' => config_path('greeting.php'),
    ]);
}

Step 5: Releasing the Package

Once your package is complete, you can version it and share it with others. You can publish it on Packagist, the default package repository for Composer. First, create a Git repository for your package and push your code.

Then, tag a release:

git tag -a v1.0.0 -m "Initial release"
git push origin v1.0.0

Finally, submit your package to Packagist by linking it to your GitHub repository.

Conclusion

Creating a Laravel package is a great way to modularize your code and share it with the community. By following the steps above, you can develop, register, and release a package that adds reusable functionality to any Laravel project.

For further reading and advanced features, such as testing your package and setting up continuous integration, consider the following resources:

• Laravel Package Development Documentation

• Composer Documentation

• PSR-4 Autoloading Standard

By following these steps and best practices, you'll be well on your way to developing robust and reusable packages for your Laravel applications. Happy coding!

What is Zustand?

Zustand is a small, fast, and scalable state management library for React. Unlike more complex libraries such as Redux, Zustand is designed to be minimalistic, with an API that's easy to use and integrate into any React application. It uses hooks to manage state, making it a perfect fit for modern React applications that leverage the power of hooks for state and side-effect management.

Key Features of Zustand

• Minimalistic and Lightweight: Zustand has a small bundle size and minimal API surface, making it easy to learn and use.

• No Boilerplate: It eliminates the need for boilerplate code, allowing developers to focus on application logic rather than wiring up actions and reducers.

• Performance: Zustand is optimized for performance, ensuring that state updates are efficient and don't cause unnecessary re-renders.

• Flexible and Scalable: It can be used for both simple and complex state management needs, making it suitable for a wide range of applications.

Use Cases for Zustand

Zustand can be used in various scenarios where state management is required. Here are a few common use cases:

1. Global State Management: Managing global state across the entire application, such as user authentication, theme settings, and application configuration.

2. Component State Management: Handling state that is shared between multiple components, such as form inputs, filters, and UI state.

3. Asynchronous State Management: Managing state that depends on asynchronous operations, such as fetching data from an API and handling loading and error states.

Getting Started with Zustand

To get started with Zustand, you need to install it in your React project:

npm install zustand
# or
yarn add zustand

Basic Example

Let's start with a basic example of using Zustand to manage the state of a counter:

import { create } from 'zustand';

interface State {
  count: number;
  increment: () => void;
  decrement: () => void;
}

const useStore = create<State>((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 })),
}));

const Counter: React.FC = () => {
  const { count, increment, decrement } = useStore();
  return (
    <div>
      <h1>{count}</h1>
      <button onClick={increment}>Increment</button>
      <button onClick={decrement}>Decrement</button>
    </div>
  );
};

export default Counter;

In this example, we define a store using the create function from Zustand. The store has a state object with a count property and two actions: increment and decrement. These actions update the state using the set function. The Counter component uses the useStore hook to access the state and actions, allowing it to display and modify the counter value.

Advanced Example: Asynchronous State Management

Zustand can also handle asynchronous operations seamlessly. Here's an example of fetching data from an API:

import { create } from 'zustand';

interface State {
  data: any;
  loading: boolean;
  error: string | null;
  fetchData: () => Promise<void>;
}

const useStore = create<State>((set) => ({
  data: null,
  loading: false,
  error: null,
  fetchData: async () => {
    set({ loading: true, error: null });
    try {
      const response = await fetch('https://api.example.com/data');
      const result = await response.json();
      set({ data: result, loading: false });
    } catch (error) {
      set({ error: error.message, loading: false });
    }
  },
}));

const DataFetcher: React.FC = () => {
  const { data, loading, error, fetchData } = useStore();

  return (
    <div>
      <button onClick={fetchData}>Fetch Data</button>
      {loading && <p>Loading...</p>}
      {error && <p>Error: {error}</p>}
      {data && <pre>{JSON.stringify(data, null, 2)}</pre>}
    </div>
  );
};

export default DataFetcher;

In this example, the store has additional state properties (data, loading, and error) and an asynchronous action (fetchData) that fetches data from an API. The DataFetcher component uses the useStore hook to access the state and action, allowing it to initiate the fetch operation and display the results.

Promising APIs in Zustand

Zustand offers several promising APIs that enhance its functionality:

1. Selectors: Zustand supports selectors for efficient state selection, allowing components to subscribe to specific parts of the state.

const counter = () => useStore((state) => state.count);
const setCounter = () => useStore((state) => state.setCount);

2. Middleware: Zustand allows middleware to be added to stores for advanced use cases such as logging, persisting state, and handling side effects.

import { create } from 'zustand';
import { persist } from 'zustand/middleware';

const useStore = create<State>(
  persist(
    (set) => ({
      count: 0,
      increment: () => set((state) => ({ count: state.count + 1 })),
      decrement: () => set((state) => ({ count: state.count - 1 })),
    }),
    { name: 'counter' }
  )
);

3. Computed State: Zustand supports derived state, enabling the creation of computed properties based on the store's state.

const doubleCount = () => useStore((state) => state.count * 2);

4. Devtools Integration: Zustand integrates with Redux DevTools for better debugging and state inspection.

import { devtools } from 'zustand/middleware';

const useStore = create<State>(
  devtools((set) => ({
    count: 0,
    increment: () => set((state) => ({ count: state.count + 1 })),
    decrement: () => set((state) => ({ count: state.count - 1 })),
  }))
);

Real life example with slice pattern

Using the slice pattern with Zustand allows you to modularize and organize your state management logic into smaller, reusable pieces. This pattern is particularly useful for larger applications where you want to maintain a clear separation of concerns. Below, we'll enhance the contact form example by using the slice pattern.

Setting Up the Zustand Store with Slices

First, create slices for the contact form state. Create a file named contactStore.ts:

import { create, type StateCreator } from 'zustand';

interface ContactFormSlice {
  name: string;
  email: string;
  subject: string;
  message: string;
  setName: (name: string) => void;
  setEmail: (email: string) => void;
  setSubject: (subject: string) => void;
  setMessage: (message: string) => void;
  resetForm: () => void;
}

const createContactFormSlice: StateCreator<ContactFormSlice> = (set) => ({
  name: '',
  email: '',
  subject: '',
  message: '',
  setName: (name) => set({ name }),
  setEmail: (email) => set({ email }),
  setSubject: (subject) => set({ subject }),
  setMessage: (message) => set({ message }),
  resetForm: () => set({
    name: '',
    email: '',
    subject: '',
    message: '',
  }),
});

interface Store extends ContactFormSlice {}

export const useStore = create<Store>((set) => ({
  ...createContactFormSlice(set),
}));

Creating the Contact Form Component

Now, create a page or component for the contact form. Here’s an example using a functional component:

import { useStore } from '../store/contactStore';
import { FormEvent } from 'react';

const ContactForm = () => {
  const { name, email, subject, message, setName, setEmail, setSubject, setMessage, resetForm } = useStore();

  const handleSubmit = (e: FormEvent) => {
    e.preventDefault();
    // Here, you can handle the form submission, e.g., send the data to an API
    console.log({ name, email, subject, message });
    resetForm();
  };

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="name">Name:</label>
        <input
          type="text"
          id="name"
          value={name}
          onChange={(e) => setName(e.target.value)}
          required
        />
      </div>
      <div>
        <label htmlFor="email">Email:</label>
        <input
          type="email"
          id="email"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
          required
        />
      </div>
      <div>
        <label htmlFor="subject">Subject:</label>
        <input
          type="text"
          id="subject"
          value={subject}
          onChange={(e) => setSubject(e.target.value)}
          required
        />
      </div>
      <div>
        <label htmlFor="message">Message:</label>
        <textarea
          id="message"
          value={message}
          onChange={(e) => setMessage(e.target.value)}
          required
        />
      </div>
      <button type="submit">Submit</button>
    </form>
  );
};

export default ContactForm;

Using the Contact form

You can now integrate the ContactForm component into any page in your application. For example, if you want to display it on the home page, you can modify pages/home.tsx:

import ContactForm from '../components/ContactForm';

const Home = () => {
  return (
    <div>
      <h1>Contact Us</h1>
      <ContactForm />
    </div>
  );
};

export default Home;

Using the slice pattern with Zustand, we have modularized the state management for a contact form in a React application. This approach helps in maintaining a clean and organized codebase, especially as the application grows. By defining slices and combining them into a single store, you can easily manage different parts of your application state in a scalable manner.

Conclusion

Zustand is a powerful and flexible state management library that offers a minimalistic API, making it an excellent choice for both simple and complex React applications. Its lightweight nature, combined with features like selectors, middleware, computed state, and devtools integration, makes it a compelling alternative to more heavyweight state management solutions. Whether you're building a small project or a large-scale application, Zustand provides the tools you need to manage state efficiently and effectively.

For more information visit there documentation from here. And still if you need help then let discuss and explore.

1. Performance Improvement:

   • Faster Query Execution: Indexes allow the database to find and retrieve specific rows much faster than it could without them. This significantly reduces the time it takes to execute queries, especially on large datasets.

   • Efficient Data Retrieval: With indexes, the database can quickly locate the data without scanning the entire table, resulting in quicker response times for SELECT queries.

2. Optimized Resource Usage:

   • Reduced CPU and Memory Usage: Since indexes make data retrieval more efficient, they help reduce the load on the CPU and memory. This optimization is crucial for maintaining the overall performance of the application, particularly under heavy load.

   • Lower I/O Operations: Indexes decrease the number of disk I/O operations required to retrieve data, which is beneficial for improving performance in environments where disk speed is a bottleneck.

3. Enhanced User Experience:

   • Responsive Applications: Fast data retrieval directly impacts the responsiveness of an application. Users experience quicker load times and smoother interactions, which is essential for maintaining user satisfaction and engagement.

   • Scalability: Efficient indexing allows an application to scale better. As the dataset grows, well-indexed databases can handle increased traffic and larger volumes of data without significant performance degradation.

4. Supporting Complex Queries:

   • Efficient Sorting and Filtering: Indexes are beneficial for operations that involve sorting and filtering data. They help optimize ORDER BY and WHERE clauses, making these operations more efficient.

   • Joins Optimization: Indexes can significantly speed up JOIN operations by quickly locating the matching rows in related tables, thus improving the performance of complex queries involving multiple tables.

5. Best Practices and Maintenance:

   • Index Management: Laravel’s Eloquent ORM provides methods to create and manage indexes easily. Properly managing indexes (adding, updating, or removing them as needed) ensures the database remains optimized.

   • Avoiding Over-Indexing: While indexes are beneficial, having too many can lead to performance issues during INSERT, UPDATE, and DELETE operations. It’s important to balance the number of indexes to maintain optimal performance for both read and write operations.

Improve database with proper indexing

Improving your database with proper indexing involves understanding the specific needs of your application and the queries that are being executed most frequently. Here are steps and best practices to guide you through the process:

1. Analyze Your Queries

Identify the queries that are run most frequently and those that have the highest impact on performance. Use tools and techniques like query logs, profiling, and monitoring tools to gather this information.

2. Identify Candidates for Indexing

Focus on the following types of columns when considering which to index:

• Primary Keys: These are often indexed automatically by the database.

• Foreign Keys: Indexing foreign keys can speed up joins and improve referential integrity checks.

• Columns in WHERE Clauses: Columns frequently used in WHERE clauses can benefit significantly from indexing.

• Columns in JOIN Conditions: Columns that are used in JOIN operations.

• Columns in ORDER BY and GROUP BY Clauses: Indexing these can speed up sorting and grouping operations.

• Columns used in Aggregate Functions: Such as COUNT(), AVG(), SUM().

3. Use the Right Type of Index

• Single-Column Index: Simple and useful for columns that are often queried alone.

• Composite Index: Useful for queries that filter or sort by multiple columns. The order of columns in the index should match the order of columns in your queries.

• Unique Index: Ensures that all values in the index are unique. This is automatically created for primary keys.

4. Avoid Over-Indexing

While indexes can speed up read operations, they can slow down write operations (INSERT, UPDATE, DELETE). Avoid creating unnecessary indexes that won’t be used frequently.

5. Use Indexes for Full-Text Search

For columns that store large text values and need full-text search capabilities, consider using full-text indexes.

6. Regular Maintenance

• Monitor and Analyze Index Usage: Regularly check which indexes are being used and which are not. Remove unused indexes.

• Rebuild and Reorganize Indexes: Over time, indexes can become fragmented. Periodically rebuild or reorganize them to maintain performance.

Monitoring and Tuning Indexes

1. Use Database-Specific Tools:

   • MySQL: EXPLAIN, SHOW INDEXES, and the slow query log.

   • PostgreSQL: EXPLAIN ANALYZE, pg_stat_user_indexes, and pg_stat_all_indexes.

2. Use Laravel Debugging Tools:

   • Laravel Telescope: Provides insights into queries and their execution times.

   • Laravel Debugbar: Offers a comprehensive view of the executed queries during a request.

Implementation in Laravel

In Laravel, you can create indexes using migrations, which makes the process straightforward and maintains consistency in your database schema. Here are some examples:

• Creating an Index:

    Schema::table('users', function (Blueprint $table) {
        $table->index('email');
    });
  

• Creating a Unique Index:

    Schema::table('users', function (Blueprint $table) {
        $table->unique('email');
    });
  

• Creating a Composite Index:

    Schema::table('users', function (Blueprint $table) {
        $table->index(['first_name', 'last_name']);
    });
    // another example
    Schema::table('orders', function (Blueprint $table) {
        $table->index(['user_id', 'product_id']);
    });
  

• Dropping an Index

    Schema::table('users', function (Blueprint $table) {
        $table->dropIndex(['email']); // drops index 'users_email_index'
    });
  

• Full-Text Index (if supported by your database)

    Schema::table('posts', function (Blueprint $table) {
        $table->fullText('content');
    });
  

Example: Improving Indexing Strategy

Consider we have an e-commerce application, Now let's make some improvement of this application Database.

Improving the database for an e-commerce Laravel application involves implementing a well-thought-out indexing strategy and optimizing database design. Here are some practical examples to illustrate this:

1. Indexing Key Columns

Products Table

• Query: Retrieve products by category.

    SELECT * FROM products WHERE category_id = 1;
  

  Index: category_id

    Schema::table('products', function (Blueprint $table) {
        $table->index('category_id');
    });
  

Orders Table

• Query: Fetch all orders for a specific user, sorted by date.

    SELECT * FROM orders WHERE user_id = 1 ORDER BY created_at DESC;
  

  Index: Composite index on user_id and created_at

    Schema::table('orders', function (Blueprint $table) {
        $table->index(['user_id', 'created_at']);
    });
  

Users Table

• Query: Find a user by email.

    SELECT * FROM users WHERE email = 'example@example.com';
  

  Index: email

    Schema::table('users', function (Blueprint $table) {
        $table->unique('email');
    });
  

2. Improving Full-Text Search

Products Table

• Query: Search products by name or description.

    SELECT * FROM products WHERE MATCH(name, description) AGAINST('laptop');
  

  Index: Full-text index on name and description

    Schema::table('products', function (Blueprint $table) {
        $table->fullText(['name', 'description']);
    });
  

3. Optimizing Join Operations

Orders and Products Tables

• Query: Retrieve order details with product information.

    SELECT orders.*, products.* FROM orders
    JOIN order_product ON orders.id = order_product.order_id
    JOIN products ON order_product.product_id = products.id
    WHERE orders.user_id = 1;
  

  Index: Foreign key indexes on order_product table

    Schema::table('order_product', function (Blueprint $table) {
        $table->index('order_id');
        $table->index('product_id');
    });
  

4. Caching Frequent Queries

• Query: Retrieve a list of featured products.

    SELECT * FROM products WHERE is_featured = 1;
  

  Cache: Use Laravel’s caching mechanism to store the result.

    $featuredProducts = Cache::remember('featured_products', 3600, function () {
        return Product::where('is_featured', 1)->get();
    });
  

5. Regular Maintenance

• Check how queries are perform: By using EXPLAIN, you can gain insights into how MySQL executes your queries and make informed decisions to optimize them.

  Like we have an query like this, now before the query just put a keyword EXPLAIN it will show the result how your query is executed.

•     SELECT * FROM products 
      WHERE category_id = 1 
      AND price BETWEEN 100 AND 500 
      AND MATCH(name, description) AGAINST('laptop');
  

•     EXPLAIN SELECT * FROM products 
      WHERE category_id = 1 
      AND price BETWEEN 100 AND 500 
      AND MATCH(name, description) AGAINST('laptop');
  

• Monitor Index Usage: Regularly check which indexes are being used and drop unused ones.

    SHOW INDEX FROM products;
  

• Rebuild Indexes: Periodically rebuild indexes to reduce fragmentation.

    OPTIMIZE TABLE products;
  

Example Scenario: Improving Product Retrieval

Consider a scenario where customers frequently search for products based on various filters such as category, price range, and name. Here's how to optimize it:

Products Table Structure

Schema::create('products', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->text('description');
    $table->unsignedBigInteger('category_id');
    $table->decimal('price', 8, 2);
    $table->boolean('is_featured')->default(false);
    $table->timestamps();

    $table->index('category_id');
    $table->index('price');
    $table->fullText(['name', 'description']);
});

Sample Query and Indexes

• Query: Filter products by category and price, and search by name.

    SELECT * FROM products 
    WHERE category_id = 1 
    AND price BETWEEN 100 AND 500 
    AND MATCH(name, description) AGAINST('laptop');
  

  With the above indexes, this query will be optimized for filtering by category and price, and searching by product name and description.

Conclusion

In conclusion, proper database indexing is essential for optimizing the performance of Laravel applications. By carefully analyzing query patterns and identifying which columns to index, developers can significantly enhance the speed and efficiency of data retrieval operations. This not only improves application responsiveness but also ensures better resource utilization, leading to a more scalable and robust system. Laravel’s migration tools make it straightforward to implement and manage indexes, allowing for easy adjustments as application requirements evolve.

However, it is crucial to strike a balance to avoid over-indexing, which can degrade performance during write operations. Regular monitoring and maintenance of indexes are necessary to ensure they continue to meet the application's needs effectively. By leveraging database-specific tools and Laravel's debugging utilities, developers can fine-tune their indexing strategy to sustain optimal performance. Ultimately, a well-planned indexing approach can dramatically enhance user experience and support the long-term success of a Laravel application.

To know how indexing works, you may see this article also.

End of this Series.

This is a Series of Article to start the series visithere.

Database relationships define how data in one table is related to data in another table. In Laravel, relationships are defined within Eloquent model classes, allowing you to easily query related data and navigate through your application's data structure.

Understanding Relationships

In Laravel, database relationships empower developers to model complex data structures with ease. Let's delve into a hypothetical scenario: building an e-commerce application. We'll explore how to architect the relationships between User, Product, and Order entities, demonstrating different types of relationships and their practical usage.

1. One-to-Many Relationship (User to Order):

   • A user can place multiple orders.

   • Each order belongs to one user.

2. Many-to-Many Relationship (Order to Product):

   • An order can contain multiple products.

   • A product can be part of multiple orders.

3. One-to-One Relationship (Order to ShippingAddress):

   • Each order has one associated shipping address.

Defining Relationships

Laravel supports several types of database relationships, each serving different purposes. Let's explore them with examples:

1. One-to-One Relationship

In a one-to-one relationship, each record in one table is associated with exactly one record in another table.

// User model
public function phone()
{
    return $this->hasOne(Phone::class);
}

// Phone model
public function user()
{
    return $this->belongsTo(User::class);
}

2. One-to-Many Relationship

In a one-to-many relationship, each record in one table can be associated with one or more records in another table.

// Post model
public function comments()
{
    return $this->hasMany(Comment::class);
}

// Comment model
public function post()
{
    return $this->belongsTo(Post::class);
}

3. Many-to-Many Relationship

In a many-to-many relationship, each record in one table can be associated with one or more records in another table, and vice versa.

// User model
public function roles()
{
    return $this->belongsToMany(Role::class);
}

// Role model
public function users()
{
    return $this->belongsToMany(User::class);
}

4. Has-Many-Through Relationship

This relationship allows you to define a relationship where a model has a relationship through another model.

// Country model
public function posts()
{
    return $this->hasManyThrough(Post::class, User::class);
}

5. Polymorphic Relationship

A polymorphic relationship is used when a model can belong to more than one other model on a single association.

// Comment model
public function commentable()
{
    return $this->morphTo();
}

// Post and Video models
public function comments()
{
    return $this->morphMany(Comment::class, 'commentable');
}

Utilizing Relationships

Once relationships are defined, you can easily query related data using Eloquent's expressive syntax. For example:

// Retrieve a user's phone number
$user = User::find(1);
$phone = $user->phone;

// Retrieve a post's comments
$post = Post::find(1);
$comments = $post->comments;

// Retrieve a user's roles
$user = User::find(1);
$roles = $user->roles;

// Eager loading to prevent N+1 query issues
$users = User::with('roles')->get();

// Querying through relationships
$country = Country::find(1);
$posts = $country->posts;

Eager Loading & The N+1 Query Problem

When you don't use eager loading in Laravel, you may encounter the "N+1 query problem." This problem occurs when your application executes one query to retrieve a list of records and then executes additional queries for each record to retrieve related data. This can lead to performance issues, especially with large datasets.

// User.php (Model)
class User extends Model
{
    public function posts()
    {
        return $this->hasMany(Post::class);
    }
}

// In a controller or somewhere else
$users = User::all();

foreach ($users as $user) {
    // This will execute an additional query for each user
    $posts = $user->posts;
}

In the above code, if you have 10 users, the application will execute the following queries:

1. One query to retrieve all users:

    SELECT * FROM users;
   

2. Ten additional queries to retrieve posts for each user:

    SELECT * FROM posts WHERE user_id = 1;
    SELECT * FROM posts WHERE user_id = 2;
    SELECT * FROM posts WHERE user_id = 3;
    ...
    SELECT * FROM posts WHERE user_id = 10;
   

This results in a total of 11 queries. As the number of users grows, the number of queries increases linearly, leading to significant performance issues.

Impact on Performance

The performance impact can be severe due to the following reasons:

1. Increased Database Load: Executing a large number of queries puts more load on the database server.

2. Longer Response Times: More queries mean longer response times, as each query has overhead.

3. Inefficiency: Many queries retrieving small amounts of data repeatedly are less efficient than fewer queries retrieving larger amounts of data.

Solving the Problem with Eager Loading

Eager loading can solve this problem by retrieving the related data in a single query.

1. Using Eager Loading:

// In a controller or somewhere else
$users = User::with('posts')->get();

2. Generated Queries with Eager Loading:

With eager loading, Laravel will execute the following queries:

1. One query to retrieve all users:

    SELECT * FROM users;
   

2. One query to retrieve all posts for those users:

    SELECT * FROM posts WHERE user_id IN (1, 2, 3, ..., 10);
   

This results in a total of 2 queries regardless of the number of users, significantly improving performance.

Without eager loading, you risk running into the N+1 query problem, which can degrade your application's performance. Eager loading allows you to optimize the number of queries executed, leading to faster response times and a more efficient application. Here's a comparison for clarity:

• Without Eager Loading:

  • N + 1 queries (1 query for users + N queries for posts)

  • Slower response times

  • Higher database load

• With Eager Loading:

  • 2 queries (1 query for users + 1 query for posts)

  • Faster response times

  • Lower database load

By using eager loading, you ensure that your application remains performant and scalable.

Conclusion

Laravel's Eloquent ORM provides a powerful and intuitive way to define and work with database relationships. By understanding and utilizing these relationships effectively, you can build complex applications with ease, while maintaining a clean and expressive codebase. Whether you're working with simple one-to-one relationships or complex many-to-many relationships, Laravel's Eloquent has you covered.

This is a Series of Article to start the series visit here.

In the realm of web development, database interactions are crucial for storing, retrieving, and manipulating data efficiently. Laravel, a popular PHP framework, offers robust support for database operations, making it a favorite among developers. One fundamental aspect of working with databases is mastering the art of join queries. In this article, we'll delve into various aspects of database join queries using MySQL, illustrating each concept with practical examples implemented in Laravel.

Understanding MySQL Join Types

MySQL joins are a fundamental concept for retrieving data from multiple tables in your database. Here's a breakdown of the different join types you'll encounter:

1. INNER JOIN (or Simple JOIN):

• This is the most common type of join.

• It returns only records that have matching values in both tables based on the join condition.

• Imagine it like finding the intersection between two sets of data.

2. OUTER JOINs:

• Outer joins return records from one table (the outer table) along with matching records from the other table (the inner table).

• There are two main types of outer joins:

  • LEFT JOIN (or LEFT OUTER JOIN):

    • This returns all records from the left table, and matching records from the right table.

    • For rows in the left table without a match in the right table, null values are filled in the right table's columns.

  • RIGHT JOIN (or RIGHT OUTER JOIN):

    • This is the opposite of LEFT JOIN.

    • It returns all records from the right table, and matching records from the left table.

    • Null values are filled in the left table's columns for unmatched rows in the right table.

3. FULL JOIN:

• A FULL JOIN returns all records from both tables, regardless of whether there's a match in the other table.

• It combines the results of a LEFT JOIN and a RIGHT JOIN.

• Rows without matches in either table will have null values in the corresponding columns.

4. CROSS JOIN (Cartesian Product):

• This is the least commonly used join type.

• It creates a new result set by pairing every row from one table with every row from the other table.

• This can result in a very large dataset, so use it cautiously.pen_spark

Let's illustrate these concepts with a scenario. Consider two tables: users and orders. We want to retrieve a list of users along with their corresponding orders, if any.

SELECT *
FROM users
INNER JOIN orders ON users.id = orders.user_id;

To implement this sql query in Laravel we can use like this below.

$users = User::join('orders', 'users.id', '=', 'orders.user_id')
  ->select('*')
  ->get();

Grouping Results With Aggregate Functions

Aggregate functions process multiple rows of data and return a single summarized value. Common examples include:

• COUNT(*): Counts the total number of rows in a group (often used with * to indicate all rows).

• SUM(column_name): Calculates the total sum of a specific column's values within a group.

• AVG(column_name): Computes the average value of a specific column for each group.

• MIN(column_name): Returns the minimum value of a specific column within a group.

• MAX(column_name): Returns the maximum value of a specific column within a group.

Grouping Data:

The GROUP BY clause specifies the column(s) to use for grouping the results. Rows with the same value(s) in the specified column(s) are grouped together, and aggregate functions are then applied to each group.

Example: Counting Orders per User

SELECT users.name, COUNT(orders.id) AS order_count
FROM users
LEFT JOIN orders ON users.id = orders.user_id
GROUP BY users.id;

Explanation:

1. SELECT: We select two columns: users.name and the result of COUNT(orders.id) aliased as order_count.

2. FROM: We specify the users table as the source.

3. LEFT JOIN: We perform a LEFT JOIN with the orders table on the condition users.id = orders.user_id.

4. GROUP BY: We group the results by the users.id column.

This query retrieves the name of each user and the total number of orders they have placed. Users without any orders will still be included with a NULL value for order_count.

Laravel Example:

$results = User::select('users.name', DB::raw('COUNT(orders.id) AS order_count'))
  ->leftJoin('orders', 'users.id', '=', 'orders.user_id')
  ->groupBy('users.id')
  ->get();

Explanation:

1. User::: We start with the User model.

2. select: We define the columns to be retrieved: users.name and the result of DB::raw('COUNT(orders.id) AS order_count').

3. leftJoin: Similar to the SQL query, we perform a LEFT JOIN.

4. groupBy: We group the results by users.id.

5. get: We execute the query and retrieve the results as a collection of User models.

This code achieves the same functionality as the SQL query, but with a more Laravel-specific syntax using Eloquent.

Performing Multiple Joins in One Query

In real-world scenarios, it's common to join more than two tables in a single query to retrieve comprehensive data. Laravel provides an elegant syntax for achieving this with its ORM (Object-Relational Mapping) capabilities.

Suppose we have three tables: users, orders, and products. We want to retrieve user details along with the products they have ordered.

SELECT users.name, orders.id AS order_id, products.name AS product_name
FROM users
INNER JOIN orders ON users.id = orders.user_id
INNER JOIN products ON orders.product_id = products.id;

$results = User::select('users.name', 'orders.id AS order_id', 'products.name AS product_name')
  ->join('orders', 'users.id', '=', 'orders.user_id')
  ->join('products', 'orders.product_id', '=', 'products.id')
  ->get();

Filtering Aggregated Data

Filtering aggregated data involves applying conditions to aggregated results. This is commonly done using the HAVING clause in SQL queries.

For instance, let's filter users based on the total number of orders they've placed:

SELECT users.name, COUNT(orders.id) AS order_count
FROM users
LEFT JOIN orders ON users.id = orders.user_id
GROUP BY users.id
HAVING order_count > 5;

In Laravel, achieving the same result is straightforward:

$users = User::select('users.name', DB::raw('COUNT(orders.id) AS order_count'))
    ->leftJoin('orders', 'users.id', '=', 'orders.user_id')
    ->groupBy('users.id')
    ->having('order_count', '>', 5)
    ->get();

Conclusion

By understanding the various join types, leveraging aggregate functions, performing multiple joins, and filtering aggregated data, developers can efficiently retrieve and manipulate data from multiple tables. With MySQL and Laravel's powerful tools and syntax, developers have everything they need to handle complex data operations seamlessly, ensuring the smooth functioning of their applications.

This is a Series of Article to start the series visit here.

In Laravel, database keys play a crucial role in defining relationships between different tables and ensuring data integrity. Keys help maintain the integrity and efficiency of the database by enforcing uniqueness and establishing relationships between tables. In this article, we'll explore the different types of keys used in Laravel migrations and how they are implemented. In this article we will use Laravel 11.

Primary Key

A primary key uniquely identifies each record in a table. In Laravel migrations, you can define a primary key using the increments or bigIncrements method. Here's an example:

Schema::create('users', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->string('email')->unique();
    $table->timestamps();
});

In this example, the id column is defined as the primary key using the bigIncrements method, which generates a big integer auto-incrementing ID.

Foreign Key

Foreign keys establish relationships between tables by referencing the primary key of another table. In Laravel migrations, you can define a foreign key using the foreign method. Here's an example of creating a foreign key in a migration:

Schema::table('posts', function (Blueprint $table) {
    $table->id();
    $table->foreignId('user_id')->constrained()->onDelete('cascade');
    $table->string('title');
    $table->string('slug')->unique();
    $table->text('content')->nullable();
    $table->timestamps();
});

In this example, we're adding a user_id column to the posts table, which references the id column of the users table. The foreign method establishes this relationship.

Unique Key

A unique key ensures that the values in a column are unique across all records in the table. In Laravel migrations, you can define a unique key using the unique method. Here's an example:

Schema::create('roles', function (Blueprint $table) {
    $table->id();
    $table->string('name')->unique();
    $table->timestamps();
});

In this example, the name column is defined as unique using the unique method. This ensures that each role name is unique within the roles table.

Composite Key

A composite key consists of multiple columns that, together, uniquely identify each record in a table. In Laravel migrations, you can define a composite key using the primary method with an array of column names. Here's an example:

Schema::create('orders', function (Blueprint $table) {
    $table->foreignId('user_id')->constrained()->onDelete('cascade');
    $table->foreignId('product_id')->constrained()->onDelete('cascade');

    $table->primary(['customer_id', 'product_id']);
});

In this example, the composite key consists of the customer_id and product_id columns, which together uniquely identify each order. We use the primary method to define this composite key.

Conclusion

Understanding and properly utilizing database keys is essential for designing efficient and maintainable database schemas in Laravel applications. Whether it's defining primary keys for uniqueness, foreign keys for relationships, unique keys for data integrity, or composite keys for complex relationships, Laravel provides powerful tools for managing database keys effectively.

By leveraging these features, Laravel developers can ensure the integrity and efficiency of their database structures, leading to robust and scalable applications.

JavaScript design patterns are essential tools for developers seeking to write clean, efficient, and maintainable code. By following established patterns, developers can structure their code in a way that promotes scalability, reusability, and ease of maintenance. In this article, we'll delve into some of the most widely used design patterns in JavaScript, highlighting their benefits and providing practical examples for implementation.

The Importance of Design Patterns: In the realm of software development, design patterns serve as proven solutions to recurring problems. They encapsulate best practices and design principles that enable developers to write code that is modular, flexible, and resilient to change. By leveraging design patterns, developers can streamline development workflows, reduce bugs, and improve code readability.

1. Module Pattern: The Module Pattern is a widely used design pattern in JavaScript for creating encapsulated modules with private and public methods. By using closures, developers can achieve data encapsulation and prevent the pollution of the global namespace, resulting in cleaner and more maintainable code.

Example:

var module = (function() {
  var privateVariable = 'I am private';

  function privateMethod() {
    console.log('Private Method');
  }

  return {
    publicMethod: function() {
      console.log('Public Method');
    }
  };
})();

1. Singleton Pattern: The Singleton Pattern ensures that a class has only one instance and provides a global point of access to that instance. This pattern is useful for managing global state and resources in applications, ensuring that there are no duplicate instances and facilitating centralized management.

Example:

var Singleton = (function() {
  var instance;

  function createInstance() {
    // Singleton logic
    return {};
  }

  return {
    getInstance: function() {
      if (!instance) {
        instance = createInstance();
      }
      return instance;
    }
  };
})();

1. Observer Pattern: The Observer Pattern facilitates communication between objects by defining a one-to-many dependency relationship. When the state of an object changes, all its dependents are notified and updated automatically. This pattern is commonly used in event-driven architectures and UI frameworks.

Example:

function Subject() {
  this.observers = [];

  this.addObserver = function(observer) {
    this.observers.push(observer);
  };

  this.notifyObservers = function() {
    this.observers.forEach(function(observer) {
      observer.update();
    });
  };
}

function Observer() {
  this.update = function() {
    console.log('Updated');
  };
}

var subject = new Subject();
var observer = new Observer();

subject.addObserver(observer);
subject.notifyObservers();

Conclusion

JavaScript design patterns offer a systematic approach to structuring code, promoting scalability and maintainability in software development projects. By incorporating patterns like the Module Pattern, Singleton Pattern, and Observer Pattern into their workflows, developers can write cleaner, more efficient code that is easier to understand, debug, and extend. As you continue to explore and apply design patterns in your JavaScript projects, remember to prioritize readability, flexibility, and adherence to best practices to achieve optimal results.

• A client, which sends commands. The client runs on your development machine. You can invoke a client from a command-line terminal by issuing an adb command.

• A daemon (adbd), which runs commands on a device. The daemon runs as a background process on each device.

• A server, which manages communication between the client and the daemon. The server runs as a background process on your development machine.

Here is a list of adb commands and there usages.

ADB Basics

adb devices (lists connected devices)
adb root (restarts adbd with root permissions)
adb start-server (starts the adb server)
adb kill-server (kills the adb server)
adb reboot (reboots the device)
adb devices -l (list of devices by product/model)
adb shell (starts the backround terminal)
exit (exits the background terminal)
adb help (list all commands)
adb -s (redirect command to specific device)
adb –d (directs command to only attached USB device)
adb –e (directs command to only attached emulator)

Package Installation

adb shell install (install app)
adb shell install (install app from phone path)
adb shell install -r (install app from phone path)
adb shell uninstall (remove the app)

Paths

/data/data//databases (app databases)
/data/data//shared_prefs/ (shared preferences)
/data/app (apk installed by user)
/system/app (pre-installed APK files)
/mmt/asec (encrypted apps) (App2SD)
/mmt/emmc (internal SD Card)
/mmt/adcard (external/Internal SD Card)
/mmt/adcard/external_sd (external SD Card)

adb shell ls (list directory contents)
adb shell ls -s (print size of each file)
adb shell ls -R (list subdirectories recursively)

File Operations

adb push (copy file/dir to device)
adb pull (copy file/dir from device)
run-as cat (access the private package files)

Phone Info

adb get-statе (print device state)
adb get-serialno (get the serial number)
adb shell dumpsys iphonesybinfo (get the IMEI)
adb shell netstat (list TCP connectivity)
adb shell pwd (print current working directory)
adb shell dumpsys battery (battery status)
adb shell pm list features (list phone features)
adb shell service list (list all services)
adb shell dumpsys activity / (activity info)
adb shell ps (print process status)
adb shell wm size (displays the current screen resolution)
dumpsys window windows | grep -E 'mCurrentFocus|mFocusedApp' (print current app's opened activity)

Package Info

adb shell list packages (list package names)
adb shell list packages -r (list package name + path to apks)
adb shell list packages -3 (list third party package names)
adb shell list packages -s (list only system packages)
adb shell list packages -u (list package names + uninstalled)
adb shell dumpsys package packages (list info on all apps)
adb shell dump (list info on one package)
adb shell path (path to the apk file)

Configure Settings Commands

adb shell dumpsys battery set level (change the level from 0 to 100)
adb shell dumpsys battery set status (change the level to unknown, charging, discharging, not charging or full)
adb shell dumpsys battery reset (reset the battery)
adb shell dumpsys battery set usb (change the status of USB connection. ON or OFF)
adb shell wm size WxH (sets the resolution to WxH)

Device Related Commands

adb reboot-recovery (reboot device into recovery mode)
adb reboot fastboot (reboot device into recovery mode)
adb shell screencap -p "/path/to/screenshot.png" (capture screenshot)
adb shell screenrecord "/path/to/record.mp4" (record device screen)
adb backup -apk -all -f backup.ab (backup settings and apps)
adb backup -apk -shared -all -f backup.ab (backup settings, apps and shared storage)
adb backup -apk -nosystem -all -f backup.ab (backup only non-system apps)
adb restore backup.ab (restore a previous backup)
adb shell am start|startservice|broadcast []
-a e.g. android.intent.action.VIEW
-c e.g. android.intent.category.LAUNCHER (start activity intent)

adb shell am start -a android.intent.action.VIEW -d URL (open URL)
adb shell am start -t image/* -a android.intent.action.VIEW (opens gallery)

Logs

adb logcat [options] [filter] [filter] (view device log)
adb bugreport (print bug reports)

Permissions

adb shell permissions groups (list permission groups definitions)
adb shell list permissions -g -r (list permissions details)

This post collected from Here

Understanding React Hooks

Here are the most commonly used built-in React hooks:

• useState: Manages state variables within functional components.

• useReducer: An alternative to useState for complex state logic, often used with many state variables that update interdependently.

• useEffect: Performs side effects, such as data fetching, subscriptions, or manually changing the DOM.

• useLayoutEffect: Similar to useEffect, but fires synchronously after DOM mutations.

• useContext: Accesses context values for sharing data across components without prop drilling.

• useRef: Creates mutable ref objects to hold references to DOM elements or other values.

• useCallback: Memoizes callback functions to prevent unnecessary re-renders.

• useMemo: Memoizes expensive computations to avoid re-calculations on every render.

• useImperativeHandle: Customizes the instance value exposed to parent components when using ref.

• useId: Generates unique IDs that are stable across server and client rendering.

• useInsertionEffect: Schedules effects to run before DOM mutations.

• useTransition: Pauses or suspends non-urgent updates for a smoother user experience.

• useDeferredValue: Defer re-renders of heavy components until the next screen frame.

Remember that React's hook system is designed to be extensible, so you can create your own custom hooks to encapsulate reusable stateful logic and share it across your components. Here is some example of useful react hooks.

useState

useState is a fundamental Hook used for managing state within functional components. It allows components to declare and utilize state variables. Consider an example of a simple counter:

import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

In this snippet, useState initializes the count state variable with an initial value of 0. The setCount function updates the count state, triggering re-renders when its value changes.

useEffect

useEffect is another crucial Hook used for handling side effects in functional components, such as data fetching, subscriptions, or manual DOM manipulations. Here’s an example demonstrating its usage:

import React, { useState, useEffect } from 'react';

function DataFetcher() {
  const [data, setData] = useState(null);

  useEffect(() => {
    // Simulating data fetching from an API
    fetch('https://api.example.com/data')
      .then((response) => response.json())
      .then((result) => setData(result))
      .catch((error) => console.error(error));
  }, []); // Empty dependency array runs the effect only once

  return (
    <div>
      {data ? (
        <p>Data: {data}</p>
      ) : (
        <p>Loading...</p>
      )}
    </div>
  );
}

Here, useEffect runs after the component renders and performs the data fetching operation using fetch. The empty dependency array ensures the effect runs only once, simulating a componentDidMount behavior.

useContext

The useContext Hook allows components to consume values from React Context. It’s handy for accessing global data without prop drilling. Consider this usage example:

import React, { useContext } from 'react';

const ThemeContext = React.createContext('light');

function ThemeComponent() {
  const theme = useContext(ThemeContext);

  return <p>Current Theme: {theme}</p>;
}

In this snippet, useContext(ThemeContext) retrieves the current value provided by the ThemeContext.

Custom Hooks

Custom Hooks enable developers to extract component logic into reusable functions, allowing shared stateful logic across components. Let’s create a custom Hook for handling a form input:

import { useState } from 'react';

function useFormInput(initialValue) {
  const [value, setValue] = useState(initialValue);

  function handleChange(e) {
    setValue(e.target.value);
  }

  return {
    value,
    onChange: handleChange,
  };
}

// Usage
function FormComponent() {
  const name = useFormInput('');
  const email = useFormInput('');

  return (
    <form>
      <input type="text" {...name} placeholder="Name" />
      <input type="email" {...email} placeholder="Email" />
    </form>
  );
}

In this example, useFormInput is a custom Hook managing the state of form inputs, returning value and onChange functions, simplifying form management across components.

Conclusion

React Hooks have significantly enhanced the development experience by offering a more concise and functional approach to managing state and side effects in React components. Understanding and leveraging these Hooks empower developers to create cleaner, more maintainable, and efficient code. As you explore further, you'll discover various other Hooks catering to different scenarios, enabling you to craft more robust and dynamic React applications.

Resources:

• https://react.dev/reference/react/hooks

But Git needs a home, and that's where GitHub comes in. It's a bustling online platform where developers host their Git repositories, share code, and collaborate on projects. Think of it as a vibrant marketplace for ideas, where you can showcase your work, find inspiration, and join forces with others to build amazing things.

GitHub Actions is your personal code-butler provided by GitHub! This automation platform stitches tasks like building, testing, and deploying into seamless workflows, triggered by every push or pull request. Think "mini-robots" whirring through your project, leaving you free to focus on the creative spark. So, embrace the automation revolution, let GitHub Actions take the wheel, and watch your development process hum smoothly like a well-oiled machine.

What is GitHub Actions

Imagine you're baking a cake. You gather ingredients (your code), mix them (build it), check if it's yummy (test it), and finally share it with everyone (deploy it). But wouldn't you love robots to handle all the mixing and checking while you focus on frosting the masterpiece?

That's what GitHub Actions does! It's like a robot army for your code, automating repetitive tasks in your development process. You tell it what to do in simple steps, like "mix for 5 minutes" or "run all the tests," and it just gets it done, triggered by every new batch of code (code change, pull request). No more manual work, just smooth sailing from baking to dessert!

So, GitHub Actions is your personal kitchen assistant for coding, freeing you to be the creative chef and whip up amazing software!

Learn about GitHub Actions

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

Github actions triggered based on the workflows files, let's create a workflow.

• In your repository, create the .github/workflows/ directory to store your workflow files.

• In the .github/workflows/ directory, create a new file called learn-github-actions.yml and add the following code.

•       name: learn-github-actions
        run-name: ${{ github.actor }} is learning GitHub Actions
        on: [push]
        jobs:
          check-bats-version:
            runs-on: ubuntu-latest
            steps:
              - uses: actions/checkout@v4
              - uses: actions/setup-node@v3
                with:
                  node-version: '14'
              - run: npm install -g bats
              - run: bats -v
  

• Commit these changes and push them to your GitHub repository.

Your new GitHub Actions workflow file is now installed in your repository and will run automatically each time someone pushes a change to the repository. To see the details about a workflow's execution history go to Actions tab from your repository and in the left sidebar, click the workflow you want to see.

To help you understand how YAML syntax is used to create a workflow file, this section explains each line of the introduction's example:

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions
# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions

# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request.  This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]

# Groups together all the jobs that run in the `learn-github-actions` workflow.
  jobs:

# Defines a job named `check-bats-version`. The child keys will define properties of the job.
  check-bats-version:

# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
    runs-on: ubuntu-latest

# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
    steps:

# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
      - uses: actions/checkout@v4

# This step uses the `actions/setup-node@v3` action to install the specified version of the Node.js. (This example uses version 14.) This puts both the `node` and `npm` commands in your `PATH`.
      - uses: actions/setup-node@v3
        with:
          node-version: '14'

# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
      - run: npm install -g bats

# Finally, you'll run the `bats` command with a parameter that outputs the software version.
      - run: bats -v

What can you do with Github Actions Actually

Here is a list of task you can do with Github Actions and you can find a list of events from here.

Build and test your code:

• Run your build scripts and tools (e.g., Maven, Gradle, npm)

• Execute unit and integration tests

• Perform code coverage analysis

• Generate documentation

Deployment and release:

• Deploy your code to various platforms (e.g., cloud providers, servers)

• Automate release processes like tagging, versioning, and publishing

• Trigger notifications on successful deployments

• Rollback deployments in case of errors

Continuous Integration and Continuous Delivery (CI/CD):

• Set up automated pipelines for your build, test, and deployment process

• Trigger actions on every push, pull request, or schedule

• Track the progress of your pipelines and visualize their status

• Integrate with other CI/CD tools and platforms

Other automation tasks:

• Run security scans and vulnerability checks

• Manage project dependencies

• Perform code formatting and linting

• Send emails and notifications

• Run database migrations

• Back up your code repositories

• Generate reports and dashboards

• Interact with external APIs

• Run actions on a schedule

• ... and much more!

Okay, enough learning let's build something.

Examples

Here are some examples about Github Actions.

Run a test

Imagine we have a react application, and every time we push a new changes we want to check that, the test is perfectly work or not.

So for this we should create a YAML file in the .github/workflows directory (e.g., react-tests.yml) and put the code below in the workflow file.

name: React Tests

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 20
      - run: npm ci
      - run: npm test

Push the changes in your Github repository and see the magic.

Build and deploy

Okay let's make an application to build and deploy a javascript application to GitHub pages.

As before create a new file in your project at .github/workflows/deploy.yml and paste in the YAML below.

name: Deploy to GitHub Pages

on:
  # Trigger the workflow every time you push to the `main` branch
  # Using a different branch name? Replace `main` with your branch’s name
  push:
    branches: [ main ]
  # Allows you to run this workflow manually from the Actions tab on GitHub.
  workflow_dispatch:

# Allow this job to clone the repo and create a page deployment
permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout your repository using git
        uses: actions/checkout@v3
      - name: Install, build, and upload your site
        uses: withastro/action@v1
        # with:
          # path: . # The root location of your Astro project inside the repository. (optional)
          # node-version: 18 # The specific version of Node that should be used to build your site. Defaults to 18. (optional)
          # package-manager: pnpm@latest # The Node package manager that should be used to install dependencies and build your site. Automatically detected based on your lockfile. (optional)

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v1

Your site should now be published! When you push changes to your Astro project’s repository, the GitHub Action will automatically deploy them for you.

Deploy and run actions on server

Now let's create a deployment actions for a PHP (Laravel) application.

name: Deploy to DO

# Trigger the workflow on push and
# pull request events on the production branch
on:
  push:
    branches:
      - main

# Authenticate to the the server via ssh
# and run our deployment script
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USERNAME }}
          port: ${{ secrets.PORT }}
          password: ${{ secrets.PASSWORD }}
          script: |
            cd /var/www/taksme
            source ~/.nvm/nvm.sh
            sh ./deploy.sh

To run this you have to need set some env variables in your GitHub repository.

HOST="ip-address-of-server"
USERNAME="deploy-user"
PORT="21" # by default 21, use your port of diff.
PASSWORD="user-password"

You can find Digital Ocean deployment article from here.

Run a schedular

This is an interesting actions, this workflow generate a GitHub contribution graph as animation in your repository.

name: gitartwork from a contribution graph
on:
  push:
  schedule:
    - cron: '* */24 * * *'
jobs:
  build:
    name: Make gitartwork SVG
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: jasineri/gitartwork@v1
        with:
          # Use this username's contribution graph
          user_name: 4msar
          # Text on contribution graph
          text: MSAR
      - uses: jasineri/simple-push-action@v1

This actions will trigger everyday at 12:00 AM and generate a artwork like below.

Okay, hope you enjoy the examples and got an idea what you can do with GitHub actions.

Conclusion

In conclusion, GitHub Actions stands as a transformative tool in the world of software development, emerging as a secret weapon for streamlining workflows, automating tasks, and fostering collaboration within teams.

Its seamless integration with the GitHub ecosystem empowers developers to create, customize, and deploy workflows that suit their unique project needs. The versatility and flexibility of Actions not only enhance productivity but also elevate the overall quality of software by enabling continuous integration, testing, and deployment.

Embracing GitHub Actions isn't just adopting a tool; it's embracing a culture of efficiency, innovation, and collaborative development in the modern software landscape.

Resources

• https://github.com/features/actions

• https://github.com/actions

• https://github.com/marketplace?type=actions

• https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

• Checkout my GitHub Profile

The Power of Tests

Testing isn't simply about catching bugs; it's about preventing them. By simulating user interactions and various scenarios, you proactively identify potential flaws, ensuring predictable, consistent behavior.

Laravel is built with testing in mind. In fact, support for testing with PHPUnit is included out of the box and a phpunit.xml file is already set up for your application. The framework also ships with convenient helper methods that allow you to expressively test your applications.

PHPUnit Testing tool

PHPUnit is one of the oldest and most well-known unit testing packages for PHP. It is primarily designed for unit testing, which means testing your code in the smallest components possible, but it is also incredibly flexible and can be used for a lot more than just unit testing. Moreover, it supports all major PHP frameworks including Laravel.

PHPUnit is developed with simple assertions, which make it pretty easier for you to test codes completely. Further it gives optimum results when you are testing code components individually, giving you magnified results, so that errors can be figure out easily. However, this means that testing much more advanced components like controllers, models and form validations can be a bit complicated as well.

In your newly installed Laravel application, you will find two files in the ./tests/ directory, one of ExampleTest.php and the other TestCase.php. TestCase.php file is basically a bootstrap file which sets the Laravel environment and features within our tests. It makes easy to use Laravel features in tests, and also enables framework for the testing helpers. The ExampleTest.php constitutes an example test class which contains basic test case using app testing helpers.

For creating new test class, you can either create a new file manually, or can run the inbuilt artisan make:test command of the Laravel.

Before running the test you should update the test environment in .env.testing file or phpunit.xml file.

<env name="DB_CONNECTION" value="sqlite"/>
<env name="DB_DATABASE" value=":memory:"/>

Let's create a test by running this command on your terminal.
php artisan make:test BasicTest it will create a test file in ./tests/ directory.

<?php
# test/Feature/BasicTest.php

namespace Tests\Feature;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;
use Tests\TestCase;

class BasicTest extends TestCase
{
    /**
     * A basic feature test example.
     *
     * @return void
     */
    public function test_example()
    {
        $response = $this->get('/');

        $response->assertStatus(200);
    }
}

You can create multiple method for your test class, individual method behave like a individual test case. Okay, now run the tests.

php artisan test

You will see a output like this.

Given, When, Then in Testing

If you want to test particular functions of your code, then you should follow the intrinsic pattern of Given, When and Then.

Given – It states the initial environment setup you would like to test. You can use some data, or can even setup a model factory in this step.

When – When refers to test specific function/method and called at some particular stage of the testing process.

Then – In this part, you declare about the result how it should look like.

<?php 
// ...
    public function testStartsWithALetter()
    {
        # Given
        $box = new Box(['toy', 'torch', 'ball', 'cat', 'tissue']);

        # When
        $results = $box->startsWith('t');

        # Then
        $this->assertCount(3, $results);
        $this->assertContains('toy', $results);
        $this->assertContains('torch', $results);
        $this->assertContains('tissue', $results);

        // Empty array if passed even
        $this->assertEmpty($box->startsWith('s'));
    }

There are some common assertion helper in PHPUnit

1. assertTrue()

2. assertFalse()

3. assertEquals()

4. assertNull()

5. assertNotNull()

6. assertContains()

7. assertCount()

8. assertEmpty()

9. assertSame()

10. and etc, you can find all the assertion method here

Pest Testing tool

Pest is a new testing PHP Framework developed by Nuno Maduro. While Pest itself is built on top of PHPUnit, the popular and widely adopted PHP testing framework, Pest aims to provide a better experience for writing tests. The philosophy is simple. Keep the TDD experience simple and elegant by providing expressive interfaces.

Setting up Pest

Installing Pest PHP Testing Framework is a simple process that can be completed in just a few steps. Before you begin, make sure you have PHP 8.1+ or higher installed on your system.

The first step is to require Pest as a "dev" dependency in your project by running the following command on your command line.

composer require pestphp/pest --dev --with-all-dependencies

Secondly, you'll need to initialize Pest in your current PHP project. This step will create a configuration file named Pest.php at the root level of your test suite, which will enable you to fine-tune your test suite later.

./vendor/bin/pest --init

Finally, you can run your tests by executing the pest command.

./vendor/bin/pest

Let's create a Pest test by running this command.
php artisan make:test HomepageTest --pest

it will create a test file for Pest

<?php

test('example', function () {
    $response = $this->get('/');

    $response->assertStatus(200);
});

Now update the test case like this.

<?php

it('can display the homepage', function () {
    $response = $this->get('/');

    $response->assertStatus(200);
});

Now run the test by php artisan test or ./vendor/bin/pest you will see output like this below.

Each test usually consists of three steps:

1. Prepare your test first (creating models from factories, other setup)

2. Act – do the test, execute the code that is being tested

3. Assert that the 'Act' step has had the intended consequences

use App\Models\Post;

it('can display a post on the homepage', function () {
    // Prepare
    $post = Post::factory()->create();

    // Act
    $response = $this->get(route('home'));

    // Assert
    $response->assertOk();
});

Imagine we have a ToDo model and we are going to test the API endpoints so a full API testing example below.

<?php

use App\Models\Todo;
use Illuminate\Foundation\Testing\RefreshDatabase;

uses(Tests\TestCase::class, RefreshDatabase::class);

it('does not create a to-do without a name field', function () {
    $response = $this->postJson('/api/todos', []);
    $response->assertStatus(422);
});

it('can create a to-do', function () {
    $attributes = Todo::factory()->raw();
    $response = $this->postJson('/api/todos', $attributes);
    $response->assertStatus(201)->assertJson(['message' => 'Todo has been created']);
    $this->assertDatabaseHas('todos', $attributes);
});

it('can fetch a to-do', function () {
    $todo = Todo::factory()->create();

    $response = $this->getJson("/api/todos/{$todo->id}");

    $data = [
        'message' => 'Retrieved To-do',
        'todo' => [
            'id' => $todo->id,
            'name' => $todo->name,
            'completed' => $todo->completed,
        ]
    ];

    $response->assertStatus(200)->assertJson($data);
});

it('can update a to-do', function () {
    $todo = Todo::factory()->create();
    $updatedTodo = ['name' => 'Updated To-do'];
    $response = $this->putJson("/api/todos/{$todo->id}", $updatedTodo);
    $response->assertStatus(200)->assertJson(['message' => 'To-do has been updated']);
    $this->assertDatabaseHas('todos', $updatedTodo);
});

it('can delete a to-do', function () {
    $todo = Todo::factory()->create();
    $response = $this->deleteJson("/api/todos/{$todo->id}");
    $response->assertStatus(200)->assertJson(['message' => 'To-do has been deleted']);
    $this->assertCount(0, Todo::all());
});

And the output for this test.

Expectation API

Now comes the interesting part, where Pest really stands apart from PHPUnit. In the above examples we used the $this->assertSame(...) methods to do an assertion. Pest also offers the so-called Expectation API, where you can write tests as if they were plain English. Let's refactor the previous example to use expectations:

it('is a dummy test', function () {
    $post = Post::factory()->create(['title' => 'Hello']);

    $title = $post->title;

    expect($title)->toBe('Hello');
});

You can test your title also by writing this way,

it('is a dummy test', function () {
    $post = Post::factory()->create(['title' => 'Hello']);

    expect($post)
        ->title
        ->toBe('Hello');
});

// You can also chain multiple Higher Order expectations
it('is a dummy test', function () {
    $post = Post::factory()->create(['title' => 'Hello']);

    expect($post)
        ->title->toBe('Hello')
        ->body->toBeNull();
});

You can also write our own custom Pest expectation by using the expect()->extend(...) function. See the following example from the Pest docs:

expect()->extend('toBeWithinRange', function ($min, $max) {
    return $this
       ->toBeGreaterThanOrEqual($min)
       ->toBeLessThanOrEqual($max);
});

test('numeric ranges', function () {
    expect(100)->toBeWithinRange(90, 110);
});

Conclusion: A Code of Confidence

Your journey to mastering Laravel testing isn't just about learning tools; it's about cultivating a developer's superpower - the unwavering confidence that your code will shine. Each executed test becomes a brick in the fortress of your application, protecting it from the unpredictable winds of real-world use.

So, embrace the test-driven mantra. Let curiosity be your compass, experiment be your fuel, and the Laravel community your support system. As you navigate the exciting landscape of testing, remember that the true reward isn't just bug-free code, but the empowerment to build software that stands tall, whispers quality, and roars with reliability.

Take the first step today. Pick up your keyboard, write your first test, and watch your confidence soar as you master the art of Laravel testing.

Resources

• https://laravel.com/docs/10.x/testing

• https://docs.phpunit.de/en/9.6/assertions.html

• https://pestphp.com/docs

• https://ralphjsmit.com/pest-php-testing-laravel

The Callback Catastrophe: A JavaScript Horror Story

Before Promises, callbacks were the only way to handle asynchronous operations. Imagine you're trying to bake a cake. You ask your friend to mix the batter (the asynchronous function), and you give them a callback (a function) to run with the results (the mixed batter). But then you need to wait for the eggs to boil (another asynchronous function), and you need to pass another callback to handle those results and so on.

This quickly leads to "callback hell," a nested structure of functions that becomes difficult to track and debug. Imagine the cake recipe with callbacks:

mixBatter(function(batter) {
  boilEggs(function(eggs) {
    creamButter(function(creamedButter) {
      combineIngredients(batter, eggs, creamedButter, function(cake) {
        bakeCake(cake, function(bakedCake) {
          console.log("Delicious cake is ready!");
        });
      });
    });
  });
});

This spaghetti code makes it hard to follow the flow of execution and identify errors. Debugging becomes a nightmare, like searching for a specific ingredient in a messy pantry.

Promises: Knights in Shining Armor

Promises come to the rescue, offering a clear and structured way to handle asynchronous operations. Imagine them as envelopes you send containing your instructions and a placeholder for the eventual results. You give the envelope to the asynchronous function (your friend with the mixer), and when they're done, they fill the envelope with the mixed batter and send it back. You can then open the envelope (using the then method) and use the results (the batter) to continue baking.

Promises make your code much cleaner and easier to read. No more nesting callbacks! You can chain multiple asynchronous operations one after another using then, creating a clear flow of execution:

mixBatter().then(batter => {
  return boilEggs();
}).then(eggs => {
  return creamButter();
}).then(creamedButter => {
  return combineIngredients(batter, eggs, creamedButter);
}).then(cake => {
  return bakeCake(cake);
}).then(bakedCake => {
  console.log("Delicious cake is ready!");
});

The code reads just like the recipe steps, one after another, making it much easier to understand and debug. So, no more callback chains stretching across your code like vines! With Promises, you can:

• Write cleaner code: Instead of juggling callbacks, you use then and catch methods to handle successful results and errors, respectively.

• Chain operations with ease: then allows you to seamlessly link multiple asynchronous tasks, one after the other.

• Improve error handling: catch provides a central location to deal with any issues that may arise during asynchronous operations.

Async/Await: The Code Whisperer

While Promises improve asynchronous code, Async/Await takes it to another level. Imagine being able to write asynchronous code as if it were synchronous! That's exactly what Async/Await allows you to do.

Simply mark a function as async, and you can use the await keyword before any Promise-returning function. The magic happens here: instead of waiting for the Promise to resolve and then continuing, the execution will simply pause at that point. When the Promise is resolved, the value within the Promise will be assigned to a variable for you to use further.

This makes your code look incredibly clean and linear. It reads almost like a step-by-step recipe, each await marking a point where you wait for something to happen before moving on:

async function bakeCake() {
  const batter = await mixBatter();
  const eggs = await boilEggs();
  const creamedButter = await creamButter();
  const cake = await combineIngredients(batter, eggs, creamedButter);
  const bakedCake = await bakeCake(cake);
  console.log("Delicious cake is ready!");
}

bakeCake();

Async/Await is your cartographer, allowing you to write code as if it were synchronous, even when dealing with asynchronous operations.

Here's the magic:

• Mark functions as async: This tells the compiler that the function might contain asynchronous operations.

• Use the await keyword: This keyword indicates a point where you want to wait for a Promise to resolve before moving on.

• The code pauses and waits: While waiting for the Promise, the rest of the code execution is paused, giving you a linear flow.

Beyond the Basics: Advanced Techniques

Promises and Async/Await offer even more power beyond the basic examples. You can chain multiple asynchronous operations together using then and await in sequence, handle parallel tasks with Promise.all, and even use techniques like error handling and cancellation for robust and reliable asynchronous code.

Here are some examples of advanced techniques you can explore with Promises and Async/Await in JavaScript:

1. Chaining Promises with Error Handling:

Imagine fetching data from multiple APIs in sequence, where each step depends on the successful completion of the previous one. You can chain Promises with then and catch to handle errors and gracefully propagate them throughout the chain:

async function fetchDataChain() {
  try {
    const user = await fetch('/api/users/123');
    const data = await user.json();
    const posts = await fetch(`/api/posts/${data.id}`);
    const postList = await posts.json();
    // Use postList data
    return postList;
  } catch (error) {
    console.error(error);
    // Handle error gracefully and possibly return a fallback value
  }
}

fetchDataChain().then(postList => {
  // Do something with the post list
}).catch(error => {
  // Handle any errors from the chain
});

2. Parallel Execution with Promise.all:

Sometimes you need to perform multiple asynchronous operations simultaneously, like fetching data from several APIs at once. Promise.all allows you to wait for all promises in an array to resolve and then access the results as a single array:

const promises = [
  fetch('/api/products/1'),
  fetch('/api/products/2'),
  fetch('/api/products/3'),
];

Promise.all(promises)
  .then(responses => Promise.all(responses.map(response => response.json())))
  .then(products => {
    // Process all product data together
  })
  .catch(error => {
    console.error(error);
  });

3. Error Cancelling with AbortController:

Imagine fetching data from a slow API but needing to cancel the request if the user navigates away from the page. AbortController allows you to create a signal that can be used to cancel an ongoing asynchronous operation:

const controller = new AbortController();
const signal = controller.signal;

fetch('/api/large-data', { signal })
  .then(response => response.json())
  .then(data => {
    // Use the data
  })
  .catch(error => {
    if (error.name === 'AbortError') {
      console.log('Request cancelled');
    } else {
      console.error(error);
    }
  });

// On user navigation, cancel the request
controller.abort();

These are just a few examples to spark your exploration of advanced techniques with Promises and Async/Await. Remember, the possibilities are endless! By mastering these tools and experimenting with their capabilities, you can build robust, efficient, and enjoyable asynchronous applications in JavaScript.

The Synergistic Duo: Promises and Async/Await, Hand in Hand

Promises and Async/Await are best friends. Promises provide the underlying mechanism for handling asynchronous operations, while Async/Await simplifies their usage with a more synchronous-like syntax. They work together seamlessly, making asynchronous programming in JavaScript an enjoyable and productive experience.

Resources:

• Promise MDN docs

• Asynchronous JavaScript

• Promise API

• Eloquent JavaScript

Beyond Basic Authentication:

Laravel's built-in authentication features provide a solid foundation, but for enhanced security, consider implementing advanced strategies:

Password Hashing and Salting:

Store user passwords securely using strong hashing algorithms like Bcrypt, and combine them with unique salts for additional protection. This mitigates the risk of password breaches and rainbow table attacks.

Example of Password Hashing and Salting in Laravel

Here's an example of password hashing and salting in Laravel:

1. Hashing a Password:

use Illuminate\Support\Facades\Hash;

$password = "password123"; // User's input password

// Hash the password with Bcrypt algorithm
$hashedPassword = Hash::make($password);

// Store the hashed password in the database
User::create([
    'name' => 'John Doe',
    'email' => 'john.doe@example.com',
    'password' => $hashedPassword,
]);

2. Verifying a Password:

$user = User::where('email', 'john.doe@example.com')->first();

$password = "password123"; // User's input password

// Verify the password against the stored hash
if (Hash::check($password, $user->password)) {
    // Password is valid
    echo "Login successful";
} else {
    // Password is invalid
    echo "Invalid password";
}

3. Salting the Password:

By default, Laravel automatically generates a random salt when hashing passwords. However, you can also manually create and store the salt separately if needed.

use Illuminate\Support\Str;

$password = "password123";
$salt = Str::random(32); // Generate a random salt

$hashedPassword = Hash::make($password, ['rounds' => 12, 'salt' => $salt]); // Hash with custom rounds

// Store the hashed password and salt in the database
User::create([
    'name' => 'John Doe',
    'email' => 'john.doe@example.com',
    'password' => $hashedPassword,
    'salt' => $salt,
]);

4. Verifying a Salted Password:

$user = User::where('email', 'john.doe@example.com')->first();

$password = "password123";
$salt = $user->salt; // Retrieve the stored salt

$hashedPassword = Hash::make($password, ['rounds' => 12, 'salt' => $salt]); // Hash with the stored salt

// Verify the password against the stored hash
if (Hash::check($password, $user->password)) {
    // Password is valid
    echo "Login successful";
} else {
    // Password is invalid
    echo "Invalid password";
}

This example demonstrates how to hash and salt passwords in Laravel using the Hash facade. Remember to choose a strong hashing algorithm like Bcrypt and use appropriate salt generation techniques for optimal security.

Multi-Factor Authentication (MFA):

Implement MFA to add a layer of verification beyond just passwords. This can include codes sent via SMS, authenticator apps, or physical security tokens, significantly increasing the difficulty of unauthorized access.

Here is an example of the Google 2FA authentication process and implementation in laravel.

Installing a 2FA package

Use Composer to install it:

composer require pragmarx/google2fa-laravel

Publish the config file

php artisan vendor:publish --provider="PragmaRX\Google2FALaravel\ServiceProvider"

Generate the 2FA secret

use Google2FA;

return Google2FA::generateSecretKey();

Middleware

This package has a middleware that will help you code 2FA on your app. To use it, you just have to:

Add the middleware to your Kernel.php:

protected $routeMiddleware = [
    ...
    '2fa' => \PragmaRX\Google2FALaravel\Middleware::class,
];

Using it in one or more routes:

Route::get('/admin', function () {
    return view('admin.index');
})->middleware(['auth', '2fa']);

For more details about this implementation, you can look at this.

Secure Session Management:

Utilize Laravel's session management features like session drivers and "remember me" functionality responsibly. Ensure sessions are protected from session hijacking attacks by utilizing secure cookies with HTTPS and setting appropriate timeouts.

Here's an example of implementing key practices:

1. Configure Session Driver:

• By default, Laravel uses file-based session storage. Consider using a more secure driver like database-based sessions for persistent data and increased security.

• Configure the driver in config/session.php:

'driver' => 'database',

'database' => [
    'table' => 'sessions',
],

2. Secure Cookies:

• Enable the secure and http_only attributes for session cookies to prevent eavesdropping and XSS attacks in session.php config:

'secure' => true,
'http_only' => true,

3. Set Session Lifetime:

• Define a reasonable session lifetime to automatically log out users after inactivity to reduce the risk of unauthorized access:

'lifetime' => 120, // Minutes

4. Use HTTPS:

• Enforce HTTPS communication for all interactions between the user and the application to ensure data encryption in transit:

URL::forceScheme('https');

5. Implement Session Invalidation:

• Invalidate user sessions on specific events like password changes or logout to ensure a secure user state:

Auth::logout();

6. Use Session Middleware:

• Implement session middleware to restrict access to specific routes only for authenticated users:

Route::get('/admin', function () {
    // ...
})->middleware('auth');

7. Remember Me Functionality:

• Use Laravel's "remember me" functionality cautiously, ensuring appropriate cookie settings and secure storage for the remember-me token:

Auth::attempt(['email' => 'john@example.com', 'password' => 'password'], true);

By implementing these best practices for secure session management in your Laravel application, you can significantly enhance user security and protect sensitive data from unauthorized access.

API Token Authentication:

For API access, consider leveraging Laravel Sanctum. This package provides secure token-based authentication, offering granular control over access to specific resources and scopes.

The most recent versions of Laravel already include Laravel Sanctum. However, if your application's composer.json file does not include laravel/sanctum, you may follow the installation instructions below.

1. Installation and Configuration:

• Install the Laravel Sanctum package:

composer require laravel/sanctum

• Publish the Sanctum configuration and migration files:

php artisan vendor:publish --provider="Laravel\Sanctum\SanctumServiceProvider"

• Configure the config/sanctum.php file to activate Sanctum for your API routes.

2. Generate API Tokens:

• Implement a controller method to generate API tokens for authenticated users:

public function createToken(Request $request)
{
    $user = Auth::user();

    $token = $user->createToken('api');

    return response()->json(['token' => $token->plainTextToken]);
}

• Store the generated token securely, for example, in a local storage or database.

3. Secure API Routes:

• Protect your API routes by requiring an API token in the request header:

Route::group(['middleware' => 'auth:sanctum'], function () {
    // Your API routes
});

4. Token Abilities: Sanctum allows you to assign "abilities" to tokens. Abilities serve a similar purpose as OAuth's "scopes". You may pass an array of string abilities as the second argument to the createToken method:

return $user->createToken('token-name', ['server:update'])->plainTextToken;

You may then verify that a token has a given ability using the tokenCan method:

if ($user->tokenCan('server:update')) {
    // ...
}

You may also determine if a token is missing a given ability using the ability middleware:

'abilities' => \Laravel\Sanctum\Http\Middleware\CheckAbilities::class,
'ability' => \Laravel\Sanctum\Http\Middleware\CheckForAnyAbility::class,

Once the middleware has been registered, you may assign it to a route or a group of routes:

Route::get('/orders', function () {
    // Token has both "check-status" and "place-orders" abilities...
})->middleware(['auth:sanctum', 'abilities:check-status,place-orders']);

The ability` middleware may be assigned to a route to verify that the incoming request's token has at least one of the listed abilities:

Route::get('/orders', function () {
    // Token has the "check-status" or "place-orders" ability...
})->middleware(['auth:sanctum', 'ability:check-status,place-orders']);

5. Revoke API Tokens:

• Implement methods in your user model to revoke specific or all API tokens:

// Revoke all tokens...
$user->tokens()->delete();

// Revoke the token that was used to authenticate the current request...
$request->user()->currentAccessToken()->delete();

// Revoke a specific token...
$user->tokens()->where('id', $tokenId)->delete();

By implementing API token authentication, you can enhance the security and flexibility of your Laravel API and ensure that only authorized users can access your resources.

Authorization: Granting Access with Granularity:

Beyond authentication, authorization controls what users can do within your application. Laravel offers powerful tools for implementing fine-grained access controls:

Role-Based Access Control (RBAC):

Define user roles with specific permissions, assigning them to individual users or groups. This ensures users only access resources and perform actions authorized for their role.

1. Define Roles and Permissions:

• Create models for Role and Permission:

// Role Model
class Role extends Model
{
    public function permissions()
    {
        return $this->belongsToMany(Permission::class);
    }
}

// Permission Model
class Permission extends Model
{
    public function roles()
    {
        return $this->belongsToMany(Role::class);
    }
}

• Define roles and associated permissions in your database:

// Roles
DB::table('roles')->insert([
    ['name' => 'admin'],
    ['name' => 'editor'],
    ['name' => 'user'],
]);

// Permissions
DB::table('permissions')->insert([
    ['name' => 'create posts'],
    ['name' => 'edit posts'],
    ['name' => 'publish posts'],
    ['name' => 'manage users'],
]);

// Assign permissions to roles
$adminRole = Role::where('name', 'admin')->first();
$adminRole->permissions()->attach([1, 2, 3, 4]);

$editorRole = Role::where('name', 'editor')->first();
$editorRole->permissions()->attach([1, 2]);

$userRole = Role::where('name', 'user')->first();
$userRole->permissions()->attach(1);

2. Assign Roles to Users:

• Define a relationship between User and Role models:

// User Model
class User extends Authenticatable
{
    public function roles()
    {
        return $this->belongsToMany(Role::class);
    }
}

• Assign roles to users:

$user = User::find(1);
$user->roles()->attach(1); // Assign 'admin' role

3. Implement Authorization Checks:

• Use Laravel's Gate class to define authorization checks based on roles and permissions:

Gate::define('create-post', function (User $user) {
    return $user->hasPermission('create posts');
});

Gate::define('edit-post', function (User $user) {
    return $user->hasPermission('edit posts');
});

• Utilize authorization checks in your controller methods to restrict access:

public function store(Request $request)
{
    if (!Gate::allows('create-post')) {
        abort(403);
    }

    // ...
}

public function edit(Post $post)
{
    if (!Gate::allows('edit-post', $post)) {
        abort(403);
    }

    // ...
}

4. Middleware for Role-Based Access Control:

• Create middleware to enforce authorization based on roles:

class AuthorizeRoleMiddleware
{
    public function handle(Request $request, Closure $next, ...$roles)
    {
        if (!Auth::user()->hasRole($roles)) {
            abort(403);
        }

        return $next($request);
    }
}

• Apply the middleware to specific routes:

Route::group(['middleware' => AuthorizeRoleMiddleware::class], function () {
    // Routes requiring admin role
});

Additional Resources:

• Laravel Gate documentation: https://laravel.com/docs/10.x/authorization

• Implementing Role-Based Access Control in Laravel: https://ollieread.com/archive/read/laravel-rbac-role-based-access-control-without-over-engineering/

• Laravel Spatie Roles and Permissions: https://spatie.be/docs/laravel-permission/v6/basic-usage/role-permissions

By implementing RBAC in your Laravel application, you can ensure that users only access resources and functionalities permitted by their assigned roles, enhancing security and user experience.

Policies:

Leverage Laravel's policy system for more granular control. Create policies to define access permissions for specific models and resources, allowing for dynamic and context-aware authorization decisions.

Policies provide a flexible way to manage authorization logic in Laravel applications. Here's an example:

1. Create a Policy:

• Generate a policy for a specific model:

php artisan make:policy PostPolicy --model=App\Models\Post

This command creates a policy class (App\Policies\PostPolicy) responsible for authorizing actions on the Post model.

2. Define Authorization Methods:

• In the policy class, define methods for specific actions:

class PostPolicy
{
    public function create(User $user)
    {
        // Check if the user has permission to create posts
        return $user->hasRole('author');
    }

    public function update(User $user, Post $post)
    {
        // Check if the user is the post author or has edit permission
        return $user->owns($post) || $user->hasPermission('edit posts');
    }

    public function delete(User $user, Post $post)
    {
        // Check if the user has permission to delete posts
        return $user->hasPermission('delete posts');
    }
}

3. Register Policies:

• Register your policies in the AppServiceProvider to be used by Laravel:

public function boot()
{
    Gate::define('create-post', 'App\Policies\PostPolicy@create');
    Gate::define('update-post', 'App\Policies\PostPolicy@update');
    Gate::define('delete-post', 'App\Policies\PostPolicy@delete');
}

4. Use Policies in Controllers:

• Utilize the defined policies in your controller methods for authorization checks:

public function store(Request $request)
{
    $this->authorize('create', Post::class);

    // ...
}

public function update(Post $post)
{
    $this->authorize('update', $post);

    // ...
}

You can learn more about Laravel policy here.

Middleware:

Use middleware to enforce authorization checks before specific routes are accessed. This provides a convenient way to ensure that only authorized users can access specific functionalities.
Middleware plays a crucial role in Laravel applications by providing a powerful mechanism for intercepting and manipulating requests and responses. Here's an example:

1. Create a Middleware:

• Generate a middleware class:

php artisan make:middleware AdminMiddleware

This command creates a middleware class (App\Http\Middleware\AdminMiddleware) that can be used to implement custom logic before and after a request is processed.

2. Define Middleware Logic:

• In the middleware class, write your logic using the handle method:

class AdminMiddleware
{
    public function handle(Request $request, Closure $next)
    {
        $isAdmin = Auth::check() && $request->user()->isAdmin();

        if (!$isAdmin) {
            return redirect('/login');
        }

        return $next($request);
    }
}

This middleware checks if the user is authenticated before proceeding with the request. If not, it redirects them to the login page.

3. Register Middleware:

• Register your middleware in the app/Http/Kernel.php file:

protected $middleware = [
    // ... other middleware ...
    'admin' => \App\Http\Middleware\AdminMiddleware::class,
];

This registers the AdminMiddleware globally for all requests.

4. Apply Middleware to Specific Routes:

• You can also apply middleware to specific routes using route groups or individual route definitions:

// Apply middleware to all routes in a group
Route::group(['middleware' => ['auth', 'admin']], function () {
    // Protected routes
});

// Apply middleware to a specific route
Route::get('/admin', 'AdminController@index')->middleware('auth', 'admin');

5. Middleware Parameters:

• Optionally, you can pass parameters to the middleware through the route definition:

Route::get('/profile/{user}', 'UserController@profile')->middleware('auth:web,admin');

This middleware will receive the user ID as a parameter within the handle method. Learn more about Laravel Middleware https://laravel.com/docs/10.x/middleware

Advanced Security Practices:

Advanced Security Practices constitute a comprehensive and proactive approach aimed at fortifying digital systems against a spectrum of cyber threats, encompassing strategies, tools, and methodologies meticulously designed to safeguard sensitive data, thwart unauthorized access, and bolster overall system resilience. Here are some key points you can follow to secure your application.

1. Implement Rate Limiting: Limit the number of failed login attempts or API requests to prevent brute-force attacks. Laravel provides features like throttling and rate-limiting middleware to mitigate such threats.

2. Content Security Policy (CSP): Implement a CSP to define valid sources for scripts, styles, and images. This helps prevent malicious code injection attacks and protects your application from XSS vulnerabilities.

3. Secure File Uploads: Implement stringent validation and sanitization procedures for user-uploaded files. This helps prevent file upload vulnerabilities and protects your application from malware injection.

4. Secure Communication: Always use HTTPS for secure communication between your application and users, ensuring data is encrypted in transit. This protects against eavesdropping and man-in-the-middle attacks.

5. Regularly Update and Monitor: Regularly update Laravel, its dependencies, and packages to benefit from the latest security patches and fixes. Implement logging and monitoring tools to detect suspicious activity in your application and respond promptly to any security incidents.

By implementing these advanced authentication and authorization strategies, you can significantly improve the security posture of your Laravel application. Remember, security is an ongoing process, requiring continuous vigilance and adaptation to evolving threats. By staying informed and proactively implementing security best practices, you can ensure your Laravel application remains a safe and secure haven for your users and their data.

Conclusion

In conclusion, safeguarding Laravel applications through Advanced Authentication and Authorization Strategies is imperative in today's cybersecurity landscape. By leveraging robust authentication mechanisms, implementing multi-factor authentication, and employing granular authorization controls, developers fortify their applications against diverse threats. These advanced strategies, complemented by encryption, secure session handling, and regular security audits, not only protect sensitive data but also instill user confidence and ensure compliance with stringent security standards.

As digital ecosystems evolve, embracing these advanced practices becomes not just a measure of protection but a commitment to fostering trust, reliability, and resilience in Laravel applications amidst the dynamic and ever-changing threat environment. Through a proactive approach to security, developers establish a solid foundation for the integrity, confidentiality, and availability of their Laravel-powered systems.

Resources

• Authorization - Laravel 10.x - The PHP Framework For Web Artisans

• Laravel middleware

• Google 2FA laravel

• Spatie laravel permission

• Role-based access control

• Laravel Sanctum

Here we will discuss fetching API calls and some tools for API calls.

API call using fetch API

The Fetch API provides an interface for fetching resources (including across the network). It is a more powerful and flexible replacement for XMLHttpRequest.

The Fetch API provides a JavaScript interface for accessing and manipulating parts of the protocol, such as requests and responses. It also provides a global fetch() method that provides an easy, logical way to fetch resources asynchronously across the network.

Example of fetch API

Here is a simple API call using fetch API

const url = "https://jsonplaceholder.typicode.com/todos"

// using async-await
async function getData(){
    const response = await fetch(url)
    const data = await response.json()
    return data
}

// using then method
function getData() {
    fetch(url)
    .then(response => response.json())
    .then(data => console.log(data))
    .catch(error => console.log(error))
}

I have shown two types of API calling methods, in this article we will use the first one, to how we catch the error in the first method, Okay, for that we have to wrap the API call with a try-catch block like this.

const url = "https://jsonplaceholder.typicode.com/todos"

// using async-await
async function getData(){
    try{
        const response = await fetch(url)
        const data = await response.json()
        return data
    }catch(error){
        // return the error or throw the error
    }
}

Let's call another API call with more options.

const url = "https://jsonplaceholder.typicode.com/todos"

async function postData(data = {}) {
  // Default options are marked with *
  const response = await fetch(url, {
    method: "POST", // *GET, POST, PUT, DELETE, etc.
    mode: "cors", // no-cors, *cors, same-origin
    cache: "no-cache", // *default, no-cache, reload, force-cache, only-if-cached
    credentials: "same-origin", // include, *same-origin, omit
    headers: {
      "Content-Type": "application/json",
      "Accept": "application/json"
    },
    redirect: "follow", // manual, *follow, error
    referrerPolicy: "no-referrer", // no-referrer, *no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url
    body: JSON.stringify(data), // body data type must match "Content-Type" header
  });
  return response.json() // parses JSON response into native JavaScript objects
}

const data = await postData({ title: 'Update the API call' })
console.log(data) // JSON data parsed by `response.json()` call
// {"title": "Update the API call", "id": 201}

You can pass your header by the example above or you can also pass a header instance

const myHeaders = new Headers({
  "Content-Type": "text/plain",
  "Accept": "application/json"
  "X-Custom-Header": "ProcessThisImmediately",
})

Canceling a request

Sometimes we need to cancel an API call after calling the API, To abort incomplete fetch() operations, fetch-API can do it easily with the AbortController and AbortSignal interfaces.

const controller = new AbortController()
const signal = controller.signal
const url = "https://jsonplaceholder.typicode.com/todos"

const fetchBtn = document.querySelector("#fetch-todos")
const abortBtn = document.querySelector("#abort")

fetchBtn.addEventListener("click", async () => {
  try {
    const response = await fetch(url, { signal })
    console.log("Fetch complete", response)
  } catch (error) {
    console.error(`Fetch error: ${error.message}`)
  }
});

abortBtn.addEventListener("click", () => {
  controller.abort()
  console.log("Fetch aborted")
});

In the current world, all the API responses are within a few milliseconds so you can test this API call by modifying your network interceptor to slow 3G connection.

Upload file using fetch API

In modern web applications, there must be file upload requirements, so how we can do it with fetch API, for the file upload methodology we have to add the data as FormData is an example below.

async function upload(formData) {
  try {
    const response = await fetch("https://example.com/profile/avatar", {
      method: "PUT",
      body: formData,
    });
    const result = await response.json();
    console.log("Success:", result);
  } catch (error) {
    console.error("Error:", error);
  }
}

const formData = new FormData()
const fileField = document.querySelector('input[type="file"]')

formData.append("username", "msar")
formData.append("avatar", fileField.files[0])

upload(formData)

Enough for fetch API if you want to learn more about the fetch API you can browse MDN documentation or JavaScript.info docs.

Alternate to fetch API - Axios

There were many tools for API calls, Axios is a great alternative tool for API calls in JS, and Axios is a simple promise-based HTTP client for the browser and node.js. Axios provides a simple-to-use library in a small package with a very extensible interface.

Loading the Axios library

To load the Axios library you can add this line to your HTML page <script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.min.js"></script> or you can add the package via npm/yarn npm install axios or yarn add axios in this article we use as yarn package.

Basic example to send an API call using Axios.

import axios from 'axios'

// Make a request for a user with a given ID
axios.get('/user?ID=12345')
  .then(function (response) {
    // handle success
    console.log(response)
  })
  .catch(function (error) {
    // handle error
    console.log(error)
  })
  .finally(function () {
    // always executed
  })

// Want to use async/await? Add the `async` keyword to your outer function/method.
async function getUser() {
  try {
    const response = await axios.get('/user?ID=12345')
    console.log(response)
  } catch (error) {
    console.error(error)
  }
}

In this example, the API request will send an API call to this URL, /user

Digging deeper with Axios

We can call the APIs via Axios in many ways, we can pass a full config to the Axios instance

const base_url "https://jsonplaceholder.typicode.com"
// Send a POST request
axios({
  method: 'post',
  url: `${base_url}/users`,
  data: {
    firstName: 'Fred',
    lastName: 'Flintstone'
  }
})

// Send a GET request (default method)
// GET request without options or anything.
axios(`${base_url}/users`)

// the structure of axios
axios(url[, config])

here is a list of available methods Axios provides.

Request method aliases

For convenience, aliases have been provided for all supported request methods.

axios.request(config)

axios.get(url[, config])

axios.delete(url[, config])

axios.head(url[, config])

axios.options(url[, config])

axios.post(url[, data[, config]])

axios.put(url[, data[, config]])

axios.patch(url[, data[, config]])

axios.postForm(url[, data[, config]])

axios.putForm(url[, data[, config]])

axios.patchForm(url[, data[, config]])

Customizing Axios

We can create multiple instances for the Axios and use it as our necessity.
we can create an instance, and use it in our next API calls.

const instance = axios.create({
  baseURL: 'https://jsonplaceholder.typicode.com',
  headers: {
      'Accept': 'application/json'
  },
  transformRequest: [function (data, headers) {
    // Do whatever you want to transform the data
    return data;
  }],
  // `transformResponse` allows changes to 
  // the response data to be made before
  // it is passed to then/catch
  transformResponse: [function (data) {
    // Do whatever you want to transform the data
    return data;
  }],
});

// API call
instance.get('/todos')
    .then(response => {
        console.log(response.data)
    })

// response will be
// [
//   {
//     "userId": 1,
//     "id": 1,
//     "title": "delectus aut autem",
//     "completed": false
//   },
//   {
//     "userId": 1,
//     "id": 2,
//     "title": "quis ut nam facilis et officia qui",
//     "completed": false
//   },
// ......

Now we can just call the rest of the path, we don't need to pass the whole URLs,

transformRequest will transform our request config or data before calling the API, transformResponse will transform the response after successfully calling the API.
more config can be found here. We can create a global instance, so every time we use the axios we do not need to pass the config on each request, we can do that by,

axios.defaults.baseURL = 'https://jsonplaceholder.typicode.com';
axios.defaults.headers.common['Authorization'] = AUTH_TOKEN;
axios.defaults.headers.post['Content-Type'] = 'application/json';

So in this process, we can use the axios method directly as below.

axios.get('/todos')
    .then(response => {
        console.log(response.data)
    })

In Axios, we can use interceptors, for the request and response.

// Add a request interceptor
axios.interceptors.request.use(function (config) {
    // Do something before request is sent
    return config;
  }, function (error) {
    // Do something with request error
    return Promise.reject(error);
  });

// Add a response interceptor
axios.interceptors.response.use(function (response) {
    // Any status code that lie within the range of 2xx cause this function to trigger
    // Do something with response data
    return response;
  }, function (error) {
    // Any status codes that falls outside the range of 2xx cause this function to trigger
    // Do something with response error
    return Promise.reject(error);
  });

If you see we log the response.data - not the response, so what contains the response property, the response property contains the data as below.

{
  // `data` is the response that was provided by the server
  data: {},

  // `status` is the HTTP status code from the server response
  status: 200,

  // `statusText` is the HTTP status message from the server response
  // As of HTTP/2 status text is blank or unsupported.
  // (HTTP/2 RFC: https://www.rfc-editor.org/rfc/rfc7540#section-8.1.2.4)
  statusText: 'OK',

  // `headers` the HTTP headers that the server responded with
  // All header names are lower cased and can be accessed using the bracket notation.
  // Example: `response.headers['content-type']`
  headers: {},

  // `config` is the config that was provided to `axios` for the request
  config: {},

  // `request` is the request that generated this response
  // It is the last ClientRequest instance in node.js (in redirects)
  // and an XMLHttpRequest instance in the browser
  request: {}
}

Axios provides a handy configuration for request cancelation as before we saw the fetch API abort controller.

const controller = new AbortController();

const CancelToken = axios.CancelToken;
const source = CancelToken.source();

axios.get('/user/12345', {
  cancelToken: source.token,
  signal: controller.signal
}).catch(function (thrown) {
  if (axios.isCancel(thrown)) {
    console.log('Request canceled', thrown.message);
  } else {
    // handle error
  }
});

axios.post('/user/12345', {
  name: 'new name'
}, {
  cancelToken: source.token
})

// cancel the request (the message parameter is optional)
source.cancel('Operation canceled by the user.');
// OR
controller.abort(); // the message parameter is not supported

More details about cancel tokens can be found here.

Okay, let's deep dive into the API calling process, The above two processes can be used anywhere in a javascript application. But what if we use those in a React application or any front-end application? Okay now let's talk about it.

API call in a react application

There are many ways to call the API in a React application.

We can use useEffect hook and useState to store the data an example below.

const [data, setData] = useState(null);

useEffect(() => {
    fetch('https://jsonplaceholder.typicode.com/posts?_limit=10')
      .then(response => response.json())
      .then(json => setData(json))
      .catch(error => console.error(error));
}, []);

In this process, the problem is if we have to call the data again in another component we can't do that, yes if we separate the logic to a custom hook it can be possible.

const usePosts = ({ per_page = 10, page = 1 }) => {
    const [data, setData] = useState(null);

    useEffect(() => {
        fetch(
            `https://jsonplaceholder.typicode.com/posts?_limit=${per_page}&_page=${page}`
        )
            .then((response) => response.json())
            .then((json) => setData(json))
            .catch((error) => console.error(error));
    }, []);

    return data;
};

But every time we call the hook the same API will be called as our data is the same, we can prevent it by saving the first API-called data to a global store or something else. In this process we can't get the metadata like the loading state, fetching state or maybe the re-fetch functionality, then we have to create all the things from scratch.
But there were many smooth and good ways to do that, like.

• useSWR hook by Vercel

• ReactQuery by tanstack

Okay, let's call our API with that.

Vercel useSWR hook

SWR is a handy and lightweight tool to manage these API calls and data fetching.

SWR features as their website

• Lightweight

• Realtime

• Suspense

• Pagination

• Backend Agnostic

• SSR / SSG Ready

• TypeScript Ready

• Remote + Local

To use SWR in our application first, we have to install it.
yarn add swr after successfully installed we can use it like this.

import useSWR from 'swr'

function Profile() {
  const { data, error, isLoading } = useSWR('/api/user', fetcher)

  if (error) return <div>failed to load</div>
  if (isLoading) return <div>loading...</div>
  return <div>hello {data.name}!</div>
}

Here fetcher could be the Axios instance or the fetch instance.

Let's make a hook, so our SWR does not need to pass the key every time.

import useSWR from "swr";

export function useUser(userId) {
    const { data, error, isLoading } = useSWR(
      "/api/user", // key
      () => fetch(`/api/user/${userId}`).then((res) => res.json()) //fetcher
    );

    return {
      user: data,
      isLoading,
      error,
    };
}

So what is it?

Okay, here in the useSWR hooks' first attribute is the unique key for the request, and the second one is the fetcher, there are other attribute options which is optional, so the SWR looks like this.

const { data, error, isLoading, isValidating, mutate } = useSWR(key, fetcher, options)

By default, key will be passed to fetcher as the argument. So the following 3 expressions are equivalent:

useSWR('/api/user', () => fetcher('/api/user'))
useSWR('/api/user', url => fetcher(url))
useSWR('/api/user', fetcher)

In options, we can pass a custom config for the request.

Options receive these properties.

• suspense = false: enable React Suspense mode

• fetcher(args): the fetcher function

• revalidateIfStale = true: automatically revalidate even if there is stale data

• revalidateOnMount: enable or disable automatic revalidation when the component is mounted

• revalidateOnFocus = true: automatically revalidate when the window gets focused

• revalidateOnReconnect = true: automatically revalidate when the browser regains a network connection (via navigator.onLine) (details)

• refreshInterval (details):

  • Disabled by default: refreshInterval = 0

  • If set to a number, the polling interval in milliseconds

  • If set to a function, the function will receive the latest data and should return the interval in milliseconds

• refreshWhenHidden = false: polling when the window is invisible (if refreshInterval is enabled)

• refreshWhenOffline = false: polling when the browser is offline (determined by navigator.onLine)

• shouldRetryOnError = true: retry when fetcher has an error

• dedupingInterval = 2000: dedupe requests with the same key in this time span in milliseconds

• focusThrottleInterval = 5000: only revalidate once during a time span in milliseconds

• loadingTimeout = 3000: timeout to trigger the onLoadingSlow event in milliseconds

• errorRetryInterval = 5000: error retry interval in milliseconds

• errorRetryCount: max error retry count

• fallback: a key-value object of multiple fallback data (example)

• fallbackData: initial data to be returned (note: This is per-hook)

• keepPreviousData = false: return the previous key's data until the new data has been loaded (details)

• onLoadingSlow(key, config): callback function when a request takes too long to load (see loadingTimeout)

• onSuccess(data, key, config): callback function when a request finishes successfully

• onError(err, key, config): callback function when a request returns an error

• onErrorRetry(err, key, config, revalidate, revalidateOps): handler for error retry

• onDiscarded(key): callback function when a request is ignored due to race conditions

• compare(a, b): comparison function used to detect when returned data has changed, to avoid spurious rerenders. By default, stable-hash is used.

• isPaused(): function to detect whether pause revalidations, will ignore fetched data and errors when it returns true. Returns false by default.

• use: array of middleware functions

More details can be found here.

Instead of passing the configuration, we can use a global configuration for the SWR.

import useSWR, { SWRConfig } from 'swr'

function Dashboard () {
  const { data: events } = useSWR('/api/events')
  const { data: projects } = useSWR('/api/projects')
  const { data: user } = useSWR('/api/user', { refreshInterval: 0 }) // override

  // ...
}

function App () {
  return (
    <SWRConfig 
      value={{
        refreshInterval: 3000,
        fetcher: (resource, init) => fetch(resource, init).then(res => res.json())
      }}
    >
      <Dashboard />
    </SWRConfig>
  )
}

In return, the hooks give us

• data: data for the given key resolved by the fetcher (or undefined if not loaded)

• error: error thrown by fetcher (or undefined)

• isLoading: if there's an ongoing request and no "loaded data". Fallback data and previous data are not considered "loaded data"

• isValidating: if there's a request or revalidation loading

• mutate(data?, options?): function to mutate the cached data

Axios example

import axios from 'axios'

const fetcher = url => axios.get(url).then(res => res.data)

function App () {
  const { data, error } = useSWR('/api/data', fetcher)
  // ...
}

For data mutation, SWR provides a mutate method to mutate the cached data

import useSWR from 'swr'

function Profile () {
  const { data, mutate } = useSWR('/api/user', fetcher)

  const handleClick = async () => {
        const newName = data.name.toUpperCase()
        // send a request to the API to update the data
        await requestUpdateUsername(newName)
        // update the local data immediately and revalidate (refetch)
        // NOTE: key is not required when using useSWR's mutate as it's pre-bound
        mutate({ ...data, name: newName })
  }

  return (
    <div>
      <h1>My name is {data.name}.</h1>
      <button onClick={handleClick}>Uppercase my name!</button>
    </div>
  )
}

More about mutation can be found here.

Conditional

Use null or pass a function as key to conditionally fetch data. If the function throws or returns a false value, SWR will not start the request.

// conditionally fetch
const { data } = useSWR(shouldFetch ? '/api/data' : null, fetcher)

// ...or return a falsy value
const { data } = useSWR(() => shouldFetch ? '/api/data' : null, fetcher)

// ...or throw an error when user.id is not defined
const { data } = useSWR(() => '/api/data?uid=' + user.id, fetcher)

Prefetch

SWR provides the preload API to prefetch the resources programmatically and store the results in the cache. preload accepts key and fetcher as the arguments.

You can call preload even outside of React.

import { useState } from 'react'
import useSWR, { preload } from 'swr'

const fetcher = (url) => fetch(url).then((res) => res.json())

// Preload the resource before rendering the User component below,
// this prevents potential waterfalls in your application.
// You can also start preloading when hovering the button or link, too.
preload('/api/user', fetcher)

function User() {
  const { data } = useSWR('/api/user', fetcher)
  ...
}

export default function App() {
  const [show, setShow] = useState(false)
  return (
    <div>
      <button onClick={() => setShow(true)}>Show User</button>
      {show ? <User /> : null}
    </div>
  )
}

There were beautiful docs for SWR, you can look at them for more details.

Okay, SWR is the simplest way to handle the API request, but maybe you need something more than you must use the react-query to handle your API calls.

React Query

Powerful asynchronous state management for TS/JS, React, Solid, Vue and Svelte

Toss out that granular state management, manual re-fetching and endless bowls of async-spaghetti code. TanStack Query gives you declarative, always-up-to-date auto-managed queries and mutations that directly improve both your developer and user experiences.

React Query is often described as the missing data-fetching library for React, but in more technical terms, it makes fetching, caching, synchronizing and updating server state in your React applications a breeze.

#Enough talk, show me some code already!

import { QueryClient, QueryClientProvider, useQuery } from 'react-query'

const queryClient = new QueryClient()

export default function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  )
}

function Example() {
  const { isLoading, error, data } = useQuery('repoData', () =>
    fetch('https://api.github.com/repos/tannerlinsley/react-query').then(res =>
      res.json()
    )
  )

  if (isLoading) return 'Loading...'

  if (error) return 'An error has occurred: ' + error.message

  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.description}</p>
      <strong>👀 {data.subscribers_count}</strong>{' '}
      <strong>✨ {data.stargazers_count}</strong>{' '}
      <strong>🍴 {data.forks_count}</strong>
    </div>
  )
}

So let's install the react-query

npm i react-query
# or
yarn add react-query

A quick start

Here is a quick start example.
This example very briefly illustrates the 3 core concepts of React Query:

• Queries

• Mutations

• Query Invalidation

import {
  useQuery,
  useMutation,
  useQueryClient,
  QueryClient,
  QueryClientProvider,
} from 'react-query'
import { getTodos, postTodo } from '../my-api'

// Create a client
const queryClient = new QueryClient()

function App() {
  return (
    // Provide the client to your App
    <QueryClientProvider client={queryClient}>
      <Todos />
    </QueryClientProvider>
  )
}

function Todos() {
  // Access the client
  const queryClient = useQueryClient()

  // Queries
  const query = useQuery('todos', getTodos)

  // Mutations
  const mutation = useMutation(postTodo, {
    onSuccess: () => {
      // Invalidate and refetch
      queryClient.invalidateQueries('todos')
    },
  })

  return (
    <div>
      <ul>
        {query.data.map(todo => (
          <li key={todo.id}>{todo.title}</li>
        ))}
      </ul>

      <button
        onClick={() => {
          mutation.mutate({
            id: Date.now(),
            title: 'Do Laundry',
          })
        }}
      >
        Add Todo
      </button>
    </div>
  )
}

render(<App />, document.getElementById('root'))

These three concepts make up most of the core functionality of React Query. The next sections of the documentation will go over each of these core concepts in great detail.

Let's describe this.

At first, we have to create a QueryClient instance and provide it to the QueryClientProvider and the QueryClientProvider should be on top of the application so we can use the client inside the components.

So in the Todos component you see there were some hooks from the react-query we used, useQueryClient gives us the instance of the react-query client initiated by the provider, useQuery is the actual query hook that we will use each time and the useMutation hook is to revalidate the data after a successful update or delete operation.

More about useQuery hook

A query is a declarative dependency on an asynchronous source of data that is tied to a unique key. A query can be used with any Promise-based method (including GET and POST methods) to fetch data from a server.

To subscribe to a query in your components or custom hooks, call the useQuery hook with at least:

• A unique key for the query

• A function that returns a promise that:

  • Resolves the data, or

  • Throws an error

const result = useQuery('todos', fetchTodoList)

The result object contains a few very important states you'll need to be aware of to be productive. A query can only be in one of the following states at any given moment:

• isLoading or status === 'loading' - The query has no data and is currently fetching

• isError or status === 'error' - The query encountered an error

• isSuccess or status === 'success' - The query was successful and data is available

• isIdle or status === 'idle' - The query is currently disabled (you'll learn more about this in a bit)

Beyond those primary states, more information is available depending on the state of the query:

• error - If the query is in an isError state, the error is available via the error property.

• data - If the query is in a success state, the data is available via the data property.

• isFetching - In any state, if the query is fetching at any time (including background refetching) isFetching will be true.

For most queries, it's usually sufficient to check for the isLoading state, then the isError state, then finally, assume that the data is available and render the successful state:

function Todos() {
  const { isLoading, isError, data, error } = useQuery('todos', fetchTodoList)

  if (isLoading) {
    return <span>Loading...</span>
  }

  if (isError) {
    return <span>Error: {error.message}</span>
  }

  // We can assume by this point that `isSuccess === true`
  return (
    <ul>
      {data.map(todo => (
        <li key={todo.id}>{todo.title}</li>
      ))}
    </ul>
  )
}

The Query Key

The query key can be a string, array, or object.
If something is dependable you should include it as a query key.

function Todos({ todoId }) {
  const result = useQuery(['todos', todoId], () => fetchTodoById(todoId))
}

// Example of key
// A list of todos
useQuery('todos', ...) // queryKey === ['todos']

// Something else, whatever!
useQuery('somethingSpecial', ...) // queryKey === ['somethingSpecial']

// An individual todo
useQuery(['todo', 5], ...)
// queryKey === ['todo', 5]

// An individual todo in a "preview" format
useQuery(['todo', 5, { preview: true }], ...)
// queryKey === ['todo', 5, { preview: true }]

// A list of todos that are "done"
useQuery(['todos', { type: 'done' }], ...)
// queryKey === ['todos', { type: 'done' }]

Query Functions

A query function can be literally any function that returns a promise. The promise that is returned should either resolve the data or throw an error.

useQuery(['todos'], fetchAllTodos)
useQuery(['todos', todoId], () => fetchTodoById(todoId))
useQuery(['todos', todoId], async () => {
  const data = await fetchTodoById(todoId)
  return data
})
useQuery(['todos', todoId], ({ queryKey }) => fetchTodoById(queryKey[1]))
// throughing an error
useQuery(['todos', todoId], async () => {
  const response = await fetch('/todos/' + todoId)
  if (!response.ok) {
    throw new Error('Network response was not ok')
  }
  return response.json()
})

Using a Query Object instead of parameters

Anywhere the [queryKey, queryFn, config] signature is supported throughout React Query's API, you can also use an object to express the same configuration:

import { useQuery } from 'react-query'

useQuery({
  queryKey: ['todo', 7],
  queryFn: fetchTodo,
  ...config,
})

react-query is a huge feature list that is used as needed, as it is a large library to handle the API calls I think this basic is enough for now, to more details and dive I will share another individual article for this, IA.

for now, you can look at the documentation of react-query and the tkdodo blogs.

Conclusion

In conclusion, JavaScript offers a plethora of options for making API calls, each with its own advantages and specific use cases. The Fetch API provides a built-in method for fetching resources across the web, offering a straightforward and modern interface. Axios, on the other hand, simplifies the process of making HTTP requests with additional features like interceptors and support for older browsers. For React applications, libraries like useSWR and react-query enhance data fetching by providing caching, revalidation, and a more streamlined approach to handling asynchronous data.

Ultimately, the choice of which method or library to use depends on the project requirements, developer preferences, and the specific functionalities needed. Understanding the nuances and strengths of each approach empowers developers to efficiently retrieve and manage data, ensuring a smoother and more responsive user experience in their web applications.

Resources

• https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

• https://axios-http.com/

• https://swr.vercel.app/

• https://tanstack.com/query/v3/

Recently, I encountered this issue firsthand. We were working on a React application that displayed numerous charts across multiple pages. On each page, there were typically 5-7 charts, all powered by Apache ECharts.

The Problem

Consider the example chart below. We had six such charts on a single page.

Each chart had customizable options, allowing users to modify the x-axis length, y-axis scale, and other parameters.

The application would load once and then remain idle until refreshed. An API call was made every minute to update the chart data automatically. With six charts, this meant that each chart could make one or two API calls per minute, and the page could stay idle for 7-30 days.

The component structure looked like this:

SitePage
├── ReactGridLayout
│   ├── Components loop
│   │   ├── SiteChartContainer
│   │   ├── API call
│   │   │   ├── DataChart
│   │   │   └── SingleValue
│   │   │   └── ChartSettings

Within the DataChart, we had additional child components like SingleValue and ChartOptions.

The issue arose because every time a new API call was made, the SingleValue component was re-rendered. We monitored the memory usage and noticed that it increased by approximately 1MB every 10 minutes.

After one or two days—or sometimes after 7+ days—the memory usage would increase by ~1GB, eventually causing the tab (and sometimes the entire browser) to crash.

The Solutions

When the browser crashed, we began a thorough investigation to identify the root cause of the problem. It became evident that the application's memory usage was gradually increasing to an unsustainable level.

Identifying the Issue

In our React application, we had numerous event listeners, such as click and mouse event listeners, as well as some timer functions that weren't being cleared when a component unmounted. As a result, the memory consumed by these listeners, timers, and hooks wasn't being released, and the JavaScript garbage collector wasn't clearing them either.

Additionally, we discovered issues with the chart's tooltip formatting, which relied on a closure function. This caused the entire series to depend on certain calculations.

After identifying these issues, we were able to take action by reviewing every component related to this page and making the necessary updates.

Optimizing the Component Hierarchy

As you can see from our initial component hierarchy, we decided to refactor it—particularly the SiteChartContainer component.

Initially, we used the React Context API to pass data to child components. However, we found that the Context API wasn't ideal in this case, as it caused the entire component tree to re-render whenever the context value changed. We decided to switch to Zustand for state management and used React's memo to optimize child component rendering.

01 - The New Component Hierarchy

SitePage
├── ReactGridLayout
│   ├── Components loop
│   │   ├── SiteChartContainer
│   │   ├── ├── DataFetcher
│   │   │   ├── DataChartDom
│   │   │   └── DataChartOptions
│   │   │   └── SingleValue
│   │   │   └── ChartSettings

We restructured the SiteChartContainer component, separating it into sibling components instead of nested components. Data is now passed to child components through the Zustand store, ensuring that only the relevant component re-renders when the data changes.

Key Components:

• SiteChartContainer: Contains all initialization and sibling components.

• DataFetcher: Fetches data from the API and stores it in Zustand.

• DataChartDom: Renders the eChart using React DOM references.

• DataChartOptions: Sets initial eChart options and updates them when the data changes.

• SingleValue: Renders the latest chart value from the Zustand store.

• ChartSettings: Manages chart settings and updates options accordingly.

02 - Adding Clean-Up Functionality: Timers & Listeners

We also refactored event listeners and timers, using the useEffect hook to add these functionalities and ensure they were cleared when the component unmounted.

JavaScript provides built-in functions like setTimeout for executing code asynchronously after a specific duration, setInterval for regular intervals, and addEventListener for DOM event manipulation. However, if not properly cleared, these can cause memory issues.

Here's a simple example of a listener with clean-up functionality:

useEffect(() => {
  const listener = () => {
    // handle click event
  };
  window.addEventListener('click', listener);
  return () => {
    window.removeEventListener('click', listener);
  };
}, []);

If you don't remove these listeners during component unmount, they will persist in memory, causing problems with each re-render.

Another example of clearing timer functions:

useEffect(() => {
  const timer = setInterval(() => {
    // perform some action
  }, 1000);
  return () => {
    clearInterval(timer);
  };
}, []);

Always ensure that you remove or clear timers and event listeners to avoid memory issues.

03 - Refactoring the Chart Tooltip

This was a tricky part. We discovered that the chart tooltip wasn't releasing memory, which turned out to be an internal issue with eCharts (reference issue). To mitigate this, we passed the necessary data to the series value for the tooltip during the data calculation in the DataChartOptions component and used a format function to handle the tooltip formatting.

type ChartSeriesData = [
    number, // timestamp
    number, // value
    string, // unit
    string|object, // necessary data for tooltip
];

By decoupling the tooltip from the series data, the memory was successfully released.

The Result

After optimization, we observed that memory usage no longer increased significantly, and the application has been running smoothly for over 20+ days.

We also refactored the Material-UI theme switcher functionality. Previously, switching between light and dark themes caused the entire page to re-render.

JavaScript Garbage Collection and Manual Clean-Up

JavaScript employs a form of automatic memory management known as garbage collection. The garbage collector monitors memory allocation, reclaiming memory that is no longer needed. However, since the problem of automatically identifying unused memory is undecidable, garbage collectors provide only an approximate solution.

To avoid memory issues, keep the following checklist in mind:

1. Timers and Callbacks

2. Closures

3. Event Listeners

4. Detached DOM Elements

5. API Calls (e.g., React Query, Axios)

Tools for Testing Memory Leaks:

• Browser DevTools - Memory Tab

• Memlab by Meta

Conclusion

This issue taught us a lot, including that the React Context API may not always be the best solution for data passing. We also deepened our understanding of Zustand as a state management tool.

The solutions outlined here may seem straightforward, but they came after extensive research and development. This was a team effort—the "Avengers" of development! 😎