DEV Community: Ahmed Raza Idrisi

# 🎉 Happy Birthday, PHP! 🎂

Ahmed Raza Idrisi — Wed, 10 Jun 2026 18:34:45 +0000

On June 8th, we celebrate another year of PHP—the language that transformed my career from writing simple CRUD applications to building enterprise-grade systems used by thousands of users.

Over the last few years, PHP has enabled me to build:

✅ Insurance API integrations with multiple providers
✅ Enterprise-scale applications
✅ Customer and business dashboards
✅ Standalone REST APIs and microservices
✅ PDF generation and document automation systems
✅ AI-powered application features
✅ School and hotel management solutions
✅ High-performance applications with Laravel, OpenSwoole, and FrankenPHP

What I admire most about PHP is its evolution. The PHP of today is not the PHP people joked about years ago.

Modern PHP offers:

Strong typing
Enums and Attributes
Fibers for async programming
Improved performance
Excellent tooling
A mature ecosystem

Combined with frameworks like Laravel and Symfony, PHP remains one of the most productive technologies for building real-world business applications.

From handling millions of API requests to powering enterprise workflows, PHP continues to prove its reliability every day.

A big thank you to Rasmus Lerdorf, the PHP core team, and the entire open-source community for making this ecosystem what it is today.

Happy Birthday, PHP! 🎉

What's the most interesting project you've built with PHP?

Why 1 Million GoRoutines Don't Use Your GPU: Understanding CPUs, GPUs, Go's GMP Scheduler, and GPU Computing

Ahmed Raza Idrisi — Tue, 02 Jun 2026 13:37:43 +0000

Article Goal:
Write a deep technical article for software engineers explaining why millions of Go goroutines still execute on CPU cores instead of GPU cores, even though both ultimately process binary instructions. The article should start from first principles and progressively build understanding of CPU architecture, GPU architecture, Go's GMP scheduler, operating system threads, concurrency vs parallelism, and GPU computing.

Sections to Cover

1. Introduction

Discuss a common misconception:

"If a GPU has thousands of cores and Go can create millions of goroutines, why doesn't Go automatically run goroutines on the GPU?"

Introduce the core idea:

Goroutines run on CPU threads.
GPUs are specialized compute devices.
Concurrency is different from GPU parallelism.

2. Understanding CPU Architecture

Explain:

Modern CPUs (Intel i5, i7, AMD Ryzen).
Small number of powerful cores.
Branch prediction.
Large caches.
Out-of-order execution.
Context switching.

Include diagram:

CPU
├── Core 1
├── Core 2
├── Core 3
└── Core 4

Discuss why CPUs excel at:

APIs
Databases
Filesystems
Operating system tasks
Business logic

3. Understanding GPU Architecture

Explain:

NVIDIA RTX 4090
CUDA cores
Streaming Multiprocessors
Massive parallelism
Throughput-oriented design

Diagram:

GPU
├── SM 1
│   ├── 100s of threads
├── SM 2
│   ├── 100s of threads
...
└── SM N

Discuss why GPUs excel at:

Matrix multiplication
AI
Simulations
Image processing
Scientific computing

4. Go's GMP Scheduler Explained

Explain:

G = Goroutine

M = Machine (OS Thread)

P = Processor (Logical Scheduler)

Diagram:

1,000,000 Goroutines
        ↓
 Go Scheduler
        ↓
     P Pool
        ↓
    M Threads
        ↓
    CPU Cores

Clarify:

P is NOT a GPU processor.
P is a scheduling context inside Go runtime.

5. What Happens When You Launch One Million Goroutines

Example:

for i := 0; i < 1000000; i++ {
    go worker(i)
}

Explain:

Go does not create 1 million OS threads.
Goroutines are multiplexed onto a small number of CPU threads.
Scheduler performs work stealing.
Lightweight stack allocation.

Memory comparison:

OS Thread ≈ 1MB–8MB
Goroutine ≈ 2KB initial stack

6. Why API Calls Don't Benefit From GPUs

Example:

go fetchMarketData()

Break down:

DNS
TCP
TLS
Socket operations
Waiting for remote server

Timeline:

CPU Work: 0.5ms
Network Wait: 99.5ms

Explain why GPU acceleration provides no benefit.

7. When GPUs Actually Shine

Examples:

Black-Scholes calculations
Greeks calculations
Monte Carlo simulations
Option chain analytics
Risk analysis
AI trading models

Diagram:

1 Million Option Contracts
        ↓
GPU Threads
        ↓
Delta
Gamma
Theta
Vega

8. Go + CUDA Architecture

Show architecture:

Go
├── Market Data
├── APIs
├── WebSockets
├── Risk Engine
└── GPU Dispatcher
          ↓
      CUDA
          ↓
        RTX 4090

Explain that Go orchestrates work while CUDA executes calculations.

9. Python vs Go vs Rust for GPU Workloads

Compare:

Language	CPU Performance	GPU Integration	Typical Use
Python	Low	Excellent	AI/ML
Go	High	Limited	Services
Rust	Very High	Growing	Systems
C++	Maximum	Native	HPC

Explain that most Python GPU workloads ultimately execute C++/CUDA kernels.

10. Real Trading System Architecture

Design a production-grade option screener:

Market Feed
      ↓
Go Services
      ↓
Kafka
      ↓
GPU Cluster
      ↓
Risk Engine
      ↓
Trade Signals
      ↓
Execution Engine

Discuss:

Scalability
Latency
GPU utilization
Cost considerations

11. Key Takeaways

Summarize:

Goroutines run on CPUs.
GMP's P is not a GPU processor.
GPUs are not replacements for CPUs.
GPUs accelerate mathematical workloads.
Go is excellent for orchestration.
CUDA/Rust/C++ are used for extreme numerical workloads.
Modern trading systems combine CPU concurrency and GPU acceleration.

Using Redis for API Caching in Go (Speed Up Your Backend)

Ahmed Raza Idrisi — Sat, 09 May 2026 13:15:34 +0000

After building APIs in Go, the next big question is:

👉 How do you make them faster?

This is where Redis comes in.

In this post, we’ll:

Connect Go with Redis
Cache API responses
Reduce database load
Improve performance

🧠 What is Redis?

Redis is an in-memory database used for:

Caching
Sessions
Queues
Real-time systems

Think of Redis like:
👉 “Super-fast temporary storage”

Instead of hitting PostgreSQL every time:

First request → DB
Next requests → Redis cache ⚡

⚙️ Install Redis Package

```bash id="gq78f0"
go get github.com/redis/go-redis/v9




---

## 📦 Connect Redis



```go id="lb7m2n"
package main

import (
    "context"
    "github.com/redis/go-redis/v9"
)

var ctx = context.Background()

var rdb = redis.NewClient(&redis.Options{
    Addr: "localhost:6379",
})

🗄️ Example API Response

Normally:

```go id="1h9v4t"
func getUsersFromDB() string {
return "Users from PostgreSQL"
}




But hitting DB repeatedly is expensive.

---

## ⚡ Add Redis Caching



```go id="h4m92g"
func getUsers(w http.ResponseWriter, r *http.Request) {

    cachedData, err := rdb.Get(ctx, "users").Result()

    if err == nil {
        w.Write([]byte("Cache Hit 🚀\n" + cachedData))
        return
    }

    data := getUsersFromDB()

    rdb.Set(ctx, "users", data, time.Minute*5)

    w.Write([]byte("DB Hit 🐘\n" + data))
}

🔥 What’s Happening Here?

First Request

Redis has no data
Fetch from DB
Store in Redis

Next Requests

Redis already has data
Return instantly ⚡

📊 Why Caching Matters

Without cache:

Client → API → Database

With cache:

Client → API → Redis ⚡
             ↓
          Database (less often)

🚀 Benefits of Redis

Faster APIs
Reduced DB load
Better scalability
Improved user experience

⚠️ Important Production Notes

Don’t cache forever.

Always:

Set expiration time
Clear cache after updates
Avoid stale data

🧭 Real-World Usage

Redis is used in:

Authentication systems
Rate limiting
API caching
Queues
Real-time apps

Companies like:

Netflix
Instagram
Twitter

use Redis heavily.

💬 Final Thought

Caching is one of the easiest ways to improve backend performance.

You don’t always need:

Bigger servers
More CPUs

Sometimes…
👉 You just need smarter architecture.

🚀 Coming Next

👉 Rate Limiting in Go API
👉 Background Jobs with Redis
👉 Redis Pub/Sub in Go

Structuring a Go API Like Laravel (Controller, Service, Repository)

Ahmed Raza Idrisi — Mon, 04 May 2026 11:39:24 +0000

If you're coming from Laravel, one thing feels missing in Go:

👉 Structure

By default, Go gives you freedom—but no clear architecture.

So in this post, we’ll structure a Go API like Laravel:

Controller → Handle request
Service → Business logic
Repository → Database

🧠 Why Structure Matters

Without structure:

Code becomes messy quickly
Hard to scale
Difficult to debug

With structure:

Clean separation of concerns
Easier testing
Production-ready codebase

📁 Folder Structure

project/
 ├── main.go
 ├── controller/
 ├── service/
 ├── repository/
 ├── model/

🧱 Model (model/user.go)

```go id="6pn1u5"
package model

type User struct {
ID int json:"id"
Name string json:"name"
}




---

## 🗄️ Repository Layer

Handles database queries



```go id="aq1u8u"
package repository

import (
    "database/sql"
    "yourapp/model"
)

type UserRepository struct {
    DB *sql.DB
}

func (r *UserRepository) GetAll() ([]model.User, error) {
    rows, err := r.DB.Query("SELECT id, name FROM users")
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var users []model.User

    for rows.Next() {
        var user model.User
        rows.Scan(&user.ID, &user.Name)
        users = append(users, user)
    }

    return users, nil
}

⚙️ Service Layer

Handles business logic

```go id="qf1kmz"
package service

import (
"yourapp/model"
"yourapp/repository"
)

type UserService struct {
Repo *repository.UserRepository
}

func (s *UserService) GetUsers() ([]model.User, error) {
return s.Repo.GetAll()
}




---

## 🌐 Controller Layer

Handles HTTP requests



```go id="n8t1rn"
package controller

import (
    "encoding/json"
    "net/http"
    "yourapp/service"
)

type UserController struct {
    Service *service.UserService
}

func (c *UserController) GetUsers(w http.ResponseWriter, r *http.Request) {
    users, err := c.Service.GetUsers()
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(users)
}

🚀 main.go (Wire Everything)

```go id="b4r8f2"
package main

import (
"database/sql"
"log"
"net/http"

_ "github.com/lib/pq"

"yourapp/controller"
"yourapp/repository"
"yourapp/service"

)

func main() {
db, _ := sql.Open("postgres", "your_connection_string")

repo := &repository.UserRepository{DB: db}
service := &service.UserService{Repo: repo}
controller := &controller.UserController{Service: service}

http.HandleFunc("/users", controller.GetUsers)

log.Println("Server running on :8080")
http.ListenAndServe(":8080", nil)

}




---

## 🔥 What You Achieved

* Clean architecture like Laravel
* Separation of concerns
* Scalable Go backend structure

---

## 🧭 When to Use This

Use this structure when:

* Building real APIs
* Working in teams
* Scaling projects

---

## 💬 Final Thought

Go doesn’t force structure…

👉 But professionals create one.

If you combine Go performance with Laravel-style architecture, you get the best of both worlds.

---

## 🚀 Coming Next

👉 Add middleware (logging, auth)
👉 Add validation layer
👉 Dockerize Go + PostgreSQL

---

#golang #backend #architecture #programming #webdev

Structuring a Go API Like Laravel (Controller, Service, Repository)

Ahmed Raza Idrisi — Thu, 30 Apr 2026 19:21:12 +0000

If you're coming from Laravel, one thing feels missing in Go:

👉 Structure

By default, Go gives you freedom—but no clear architecture.

So in this post, we’ll structure a Go API like Laravel:

Controller → Handle request
Service → Business logic
Repository → Database

🧠 Why Structure Matters

Without structure:

Code becomes messy quickly
Hard to scale
Difficult to debug

With structure:

Clean separation of concerns
Easier testing
Production-ready codebase

📁 Folder Structure

project/
 ├── main.go
 ├── controller/
 ├── service/
 ├── repository/
 ├── model/

🧱 Model (model/user.go)

```go id="6pn1u5"
package model

type User struct {
ID int json:"id"
Name string json:"name"
}




---

## 🗄️ Repository Layer

Handles database queries



```go id="aq1u8u"
package repository

import (
    "database/sql"
    "yourapp/model"
)

type UserRepository struct {
    DB *sql.DB
}

func (r *UserRepository) GetAll() ([]model.User, error) {
    rows, err := r.DB.Query("SELECT id, name FROM users")
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var users []model.User

    for rows.Next() {
        var user model.User
        rows.Scan(&user.ID, &user.Name)
        users = append(users, user)
    }

    return users, nil
}

⚙️ Service Layer

Handles business logic

```go id="qf1kmz"
package service

import (
"yourapp/model"
"yourapp/repository"
)

type UserService struct {
Repo *repository.UserRepository
}

func (s *UserService) GetUsers() ([]model.User, error) {
return s.Repo.GetAll()
}




---

## 🌐 Controller Layer

Handles HTTP requests



```go id="n8t1rn"
package controller

import (
    "encoding/json"
    "net/http"
    "yourapp/service"
)

type UserController struct {
    Service *service.UserService
}

func (c *UserController) GetUsers(w http.ResponseWriter, r *http.Request) {
    users, err := c.Service.GetUsers()
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(users)
}

🚀 main.go (Wire Everything)

```go id="b4r8f2"
package main

import (
"database/sql"
"log"
"net/http"

_ "github.com/lib/pq"

"yourapp/controller"
"yourapp/repository"
"yourapp/service"

)

func main() {
db, _ := sql.Open("postgres", "your_connection_string")

repo := &repository.UserRepository{DB: db}
service := &service.UserService{Repo: repo}
controller := &controller.UserController{Service: service}

http.HandleFunc("/users", controller.GetUsers)

log.Println("Server running on :8080")
http.ListenAndServe(":8080", nil)

}




---

## 🔥 What You Achieved

* Clean architecture like Laravel
* Separation of concerns
* Scalable Go backend structure

---

## 🧭 When to Use This

Use this structure when:

* Building real APIs
* Working in teams
* Scaling projects

---

## 💬 Final Thought

Go doesn’t force structure…

👉 But professionals create one.

If you combine Go performance with Laravel-style architecture, you get the best of both worlds.

---

## 🚀 Coming Next

👉 Add middleware (logging, auth)
👉 Add validation layer
👉 Dockerize Go + PostgreSQL

---

#golang #backend #architecture #programming #webdev

🏗️ System Architecture Simplified: From Monolith to Microservices (With Real Insights)

Ahmed Raza Idrisi — Mon, 27 Apr 2026 11:18:50 +0000

When you start building applications, everything feels simple — one codebase, one database, one deployment. But as your app grows, things start breaking in subtle ways: slow performance, deployment risks, tight coupling.

That’s where System Architecture becomes critical.

Let’s break it down in a practical, developer-first way.

🔹 What is System Architecture?

System Architecture defines:

How components interact
How data flows
How scalable and maintainable your system is

Think of it as the blueprint of your application.

🔹 Monolithic Architecture (Where Most of Us Start)

In a monolith:

Everything is in one codebase
One database
Single deployment unit

✅ Pros:

Simple to build and deploy
Easy debugging (initially)
Great for MVPs

❌ Cons:

Hard to scale specific parts
Deployment becomes risky
Tight coupling across modules

Example (Laravel App):

Auth + Payments + Orders + Notifications → all inside one project

🔹 When Monolith Starts Failing

You’ll notice:

Small changes break unrelated features
Deployments take longer
Scaling requires scaling everything
Teams step on each other’s code

This is the point where you rethink architecture.

🔹 Microservices Architecture

Instead of one big app:
👉 You split into independent services

Example:

Auth Service
Payment Service
Order Service
Notification Service

Each service:

Has its own codebase
Can have its own database
Is deployed independently

🔹 Microservices Pros & Cons

✅ Pros:

Independent scaling
Faster deployments
Better fault isolation
Tech flexibility (Go, Node, PHP, etc.)

❌ Cons:

Network complexity
Debugging becomes harder
Requires DevOps maturity
Distributed data challenges

🔹 Real-World Architecture Pattern

A common modern setup:

[ Client (Vue/React) ]
          ↓
     API Gateway
          ↓
 ┌────────┼────────┐
 ↓        ↓        ↓
Auth   Orders   Payments
Svc     Svc       Svc
 ↓        ↓        ↓
 DB       DB       DB

🔹 Key Concepts You Must Know

1. API Gateway

Single entry point
Handles auth, routing, rate limiting

2. Service Communication

REST (simple)
gRPC (fast, efficient)
Message Queues (async processing)

3. Database Strategy

Shared DB ❌ (avoid)
Database per service ✅

4. Caching Layer

Redis for performance boost

5. Queue System

Background jobs (emails, reports)
Tools: Redis queues, Kafka, RabbitMQ

🔹 Monolith vs Microservices (Quick Comparison)

Feature	Monolith	Microservices
Deployment	Single	Independent
Scaling	Full app	Service-level
Complexity	Low	High
Flexibility	Low	High

🔹 What Should YOU Choose?

👉 If you're building:

MVP / Startup → Monolith
Growing SaaS → Modular Monolith
Large-scale system → Microservices

💡 Pro tip:
Don’t jump to microservices too early. Scale your architecture only when needed.

🔹 Final Thoughts

System architecture is not about trends — it’s about trade-offs.

Start simple.
Measure pain points.
Evolve your architecture.

That’s how real systems are built.

🚀 Building a CRUD API in Go with PostgreSQL (Step-by-Step)

Ahmed Raza Idrisi — Mon, 27 Apr 2026 11:09:38 +0000

In the previous post, we built a simple CRUD API in Go using in-memory storage.

Now let’s make it real-world ready by connecting it to a database:

👉 PostgreSQL

⚙️ Step 1: Install PostgreSQL Driver

We’ll use the official driver:

go get github.com/lib/pq

🧱 Step 2: Setup Database Connection

package main

import (
    "database/sql"
    "log"

    _ "github.com/lib/pq"
)

var db *sql.DB

func initDB() {
    connStr := "user=postgres password=postgres dbname=testdb sslmode=disable"

    var err error
    db, err = sql.Open("postgres", connStr)
    if err != nil {
        log.Fatal(err)
    }

    err = db.Ping()
    if err != nil {
        log.Fatal("DB not reachable:", err)
    }

    log.Println("Connected to PostgreSQL ✅")
}

🗄️ Step 3: Create Table

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

🧩 Step 4: Model

type User struct {
    ID   int    `json:"id"`
    Name string `json:"name"`
}

➕ Create User (INSERT)

func createUser(w http.ResponseWriter, r *http.Request) {
    var user User
    json.NewDecoder(r.Body).Decode(&user)

    err := db.QueryRow(
        "INSERT INTO users(name) VALUES($1) RETURNING id",
        user.Name,
    ).Scan(&user.ID)

    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(user)
}

📥 Get Users (SELECT)

func getUsers(w http.ResponseWriter, r *http.Request) {
    rows, err := db.Query("SELECT id, name FROM users")
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }
    defer rows.Close()

    var users []User

    for rows.Next() {
        var user User
        rows.Scan(&user.ID, &user.Name)
        users = append(users, user)
    }

    json.NewEncoder(w).Encode(users)
}

✏️ Update User

func updateUser(w http.ResponseWriter, r *http.Request) {
    idParam := r.URL.Query().Get("id")

    var user User
    json.NewDecoder(r.Body).Decode(&user)

    _, err := db.Exec(
        "UPDATE users SET name=$1 WHERE id=$2",
        user.Name, idParam,
    )

    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode("Updated")
}

❌ Delete User

func deleteUser(w http.ResponseWriter, r *http.Request) {
    idParam := r.URL.Query().Get("id")

    _, err := db.Exec("DELETE FROM users WHERE id=$1", idParam)
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode("Deleted")
}

🌐 Step 5: Main Function

func main() {
    initDB()

    http.HandleFunc("/users", getUsers)
    http.HandleFunc("/create", createUser)
    http.HandleFunc("/update", updateUser)
    http.HandleFunc("/delete", deleteUser)

    log.Println("Server running on :8080")
    http.ListenAndServe(":8080", nil)
}

🧪 Test API

Same as before, but now data is stored in PostgreSQL 🎉

⚠️ Improvements You Should Do Next

This is still beginner-level. To make it production-ready:

Use environment variables for DB config
Add validation
Use a router (Chi / Gorilla Mux)
Structure code (controllers, services, repo)
Add connection pooling tuning

🔥 What You Learned

Connecting Go to PostgreSQL
Executing SQL queries (INSERT, SELECT, UPDATE, DELETE)
Handling real database-backed APIs

🚀 Coming Next

👉 Proper API structure in Go (like Laravel mindset)
👉 Using Docker with Go + PostgreSQL
👉 Adding authentication (JWT)

💬 Final Thought

Now you're no longer just learning Go…

👉 You're building backend systems.

🔥 Arrays vs Slices in Go (Explained in the Simplest Way)

Ahmed Raza Idrisi — Wed, 22 Apr 2026 17:10:21 +0000

If you just started learning Go, one thing will confuse you quickly:

👉 Arrays vs Slices

They look similar… but behave very differently.

Let’s break it down in the simplest way possible 👇

📦 What is an Array?

An array is a fixed-size collection.

numbers := [3]int{1, 2, 3}

Key points:

Size is fixed
Cannot grow or shrink
Rarely used in real-world Go apps

🔄 What is a Slice?

A slice is a dynamic version of an array.

numbers := []int{1, 2, 3}

Key points:

Size is dynamic
Can grow using append
Used almost everywhere in Go

⚡ Adding Data (Only Works with Slice)

numbers := []int{1, 2, 3}

numbers = append(numbers, 4)

Now:

[1, 2, 3, 4]

🧠 Under the Hood (Important Concept)

A slice is:

Pointer to an array
Length
Capacity

Think of it like:
👉 “A flexible view on top of an array”

🔍 Slice Example with Capacity

numbers := make([]int, 2, 5)

fmt.Println(len(numbers)) // 2
fmt.Println(cap(numbers)) // 5

❗ Common Mistake

arr := [3]int{1,2,3}
arr = append(arr, 4) // ❌ ERROR

Why?
👉 Because arrays are fixed size

🔥 Real-World Use Case

When building APIs:

users := []string{}

users = append(users, "Ahmed")
users = append(users, "John")

Dynamic data = slices ✅

🧭 When to Use What?

Feature	Array	Slice
Size	Fixed	Dynamic
Usage	Rare	Common
Flexibility	❌	✅

👉 In 95% of cases → use slice

💬 Final Thought

If you understand slices, you understand how Go manages data internally.

This is a foundational concept—don’t skip it.

🚀 Coming Next

Next post:
👉 Structs in Go (this is where real backend modeling starts)

golang #backend #programming #webdev #devto

🚀 Getting Started with Go (Golang) for Backend Developers

Ahmed Raza Idrisi — Wed, 22 Apr 2026 17:07:57 +0000

If you're coming from PHP, Node.js, or Laravel, learning Go can feel different—but in a good way.

Go is designed for performance, simplicity, and concurrency. Many modern systems use it for building fast APIs and scalable services.

Let’s understand it in a simple way 👇

🧠 What is Go?

Go (or Golang) is a compiled programming language created at Google.

Think of it like:

⚡ Faster than PHP/Node (compiled)
🧼 Cleaner syntax than Java
🔁 Built for concurrency (handling multiple tasks efficiently)

⚙️ Your First Go Program

package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

What’s happening?

package main → entry point
import "fmt" → used for printing
func main() → main function where execution starts

🔤 Variables in Go

name := "Ahmed"
age := 25

No need to write types explicitly (Go infers them).

🔁 Loops (Only ONE loop in Go)

for i := 0; i < 5; i++ {
    fmt.Println(i)
}

Simple and clean.

⚡ Functions

func add(a int, b int) int {
    return a + b
}

🧵 Concurrency (This is where Go shines)

Go uses goroutines (lightweight threads):

go func() {
    fmt.Println("Running in background")
}()

Why this matters:

Handle multiple API requests easily
Build high-performance systems
Perfect for microservices

🌐 Simple API in Go

package main

import (
    "fmt"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello from Go API")
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

Run it and open:
👉 http://localhost:8080

🔥 Why You Should Learn Go

High performance (close to C++)
Simple syntax
Great for backend + APIs
Used by companies like Google, Uber, Netflix

🧭 Coming Next

In upcoming posts, I’ll cover:

Building REST APIs in Go
Connecting Go with PostgreSQL
Using Go with Docker
Concurrency deep dive (goroutines + channels)

💬 Final Thought

If you already know backend development, Go will feel like a power upgrade.

Start small. Stay consistent. Share what you learn.

golang #backend #programming #webdev #devto

🚀 5 Modern PHP Features You Should Start Using Today

Ahmed Raza Idrisi — Wed, 22 Apr 2026 17:03:48 +0000

If you’re still writing PHP like it's 2015, you're missing out on some powerful features that make your code cleaner, safer, and easier to maintain.

In this post, I’ll walk you through 5 modern PHP features in a very simple way — with examples you can actually use in real projects.

1. ✅ Typed Properties (Strict Data Handling)

Before PHP 7.4, you couldn’t define types for class properties.

❌ Old way:

class User {
    public $name;
}

✅ New way:

class User {
    public string $name;
}

Why it matters:

Prevents invalid data
Makes your code predictable
Helps avoid bugs early

2. ✅ Arrow Functions (Shorter Closures)

Arrow functions make your code shorter and cleaner.

❌ Old way:

$numbers = [1, 2, 3];

$squared = array_map(function($n) {
    return $n * $n;
}, $numbers);

✅ New way:

$squared = array_map(fn($n) => $n * $n, [1,2,3]);

Why it matters:

Less boilerplate
More readable functional code

3. ✅ Null Safe Operator (`?->`)

Avoid those annoying null checks.

❌ Old way:

if ($user && $user->profile) {
    echo $user->profile->email;
}

✅ New way:

echo $user?->profile?->email;

Why it matters:

Cleaner code
No more "trying to access property of null" errors

4. ✅ Match Expression (Better than switch)

match is more strict and cleaner than switch.

❌ switch:

switch($status) {
    case 'success':
        $msg = 'Done';
        break;
    case 'error':
        $msg = 'Failed';
        break;
}

✅ match:

$msg = match($status) {
    'success' => 'Done',
    'error' => 'Failed',
    default => 'Unknown'
};

Why it matters:

No break needed
Strict comparison (no type confusion)

5. ✅ Constructor Property Promotion

Less boilerplate when creating classes.

❌ Old way:

class User {
    public string $name;

    public function __construct($name) {
        $this->name = $name;
    }
}

✅ New way:

class User {
    public function __construct(public string $name) {}
}

Why it matters:

Cleaner classes
Less repetitive code

🔥 Final Thoughts

Modern PHP is:

Faster ⚡
Cleaner ✨
Safer 🔒

If you're working with frameworks like Laravel, these features are already being used under the hood — so understanding them will level up your coding skills.

💬 What Next?

If you found this useful, I can share:

Real-world Laravel examples using these features
Performance tips for PHP apps
Clean architecture patterns in PHP

Let me know in the comments 👇

PHP #Laravel #WebDevelopment #Backend #Programming

The Case of the Empty 500: How I Proved the API Failure Wasn't Our Fault

Ahmed Raza Idrisi — Wed, 11 Feb 2026 17:40:56 +0000

We’ve all been there. You make an API call, it fails, and the finger-pointing begins. "It’s the frontend," says the backend team. "It’s your service," says the API provider.

Recently, I faced a debugging challenge where our application was receiving an empty response from an external API. On the surface, it looked like our request was simply vanishing into the void. Here is how I tracked down the culprit: The WAF.

The Problem
Our application was calling an external endpoint. The symptoms were frustratingly vague:

Response Body: Completely empty.

Result: The application logic failed because there was no data to parse.

Internal Consensus: Initial thoughts were that our request payload was malformed or our connection was dropping.

Digging into the Headers
While the response body was empty, the HTTP Status Code and Response Headers told a different story. I noticed two red flags:

Status Code 500: A "500 Internal Server Error" usually implies the server tried to do something and failed. If it were our network, we’d likely see a 404 or a timeout.

Infrastructure Headers: Looking at the network trace, I saw headers related to Cloudflare and specific WAF (Web Application Firewall) signatures.

The "Aha!" Moment
By analyzing the custom headers injected by their WAF, I realized the request wasn't even reaching their application code. Their security layer was intercepting our request and dropping the payload before the server could process it.

Even though the body was empty, the presence of those specific infrastructure headers proved that the hand-off to their network was successful, but their security rules were blocking us.

The Resolution
I presented the logs and the specific WAF headers to the provider's network team. With this evidence, they were able to:

Identify the specific firewall rule that was flagging our IP/payload.

Whitelist our service.

Restore the API functionality.

Key Takeaways for Debugging APIs
Never ignore the headers: The body might be empty, but headers are the "fingerprints" of the servers the request passed through.

Status codes matter: A 500 error is a server-side confession.

Check for Middleware: In modern web dev, you aren't just talking to a server; you're talking to Load Balancers, WAFs, and Proxies.

laravel request life cycle

Ahmed Raza Idrisi — Fri, 26 Sep 2025 15:21:04 +0000

Laravel Request Lifecycle

The Laravel request lifecycle begins when a user sends an HTTP request to the web server (Apache, Nginx). The server forwards the request to the public/index.php file, the application's single entry point. This file loads Composer’s autoloader, performs essential bootstrapping, and constructs a new instance of the Laravel application.

The next step is the HTTP Kernel, which manages the request, response, and middleware stacks. The global middleware stack runs first, acting as filters for every HTTP request. Service providers register core services, and after bootstrapping, the router dispatches the request to a route or controller, executing any route-specific middleware.

Controllers (or route closures) process the request and generate a response—HTML view, JSON, download, or redirect. Before the response is sent to the user's browser, it passes back out through the middleware stack for any post-processing. Finally, the Kernel’s handle() method returns the response for index.php to deliver to the browser.

Middleware's Role in the Lifecycle

Middleware in Laravel act as filters operating before or after the core route/controller logic. They check authentication, log requests, manipulate headers, etc. Middleware can be global (applied to all requests) or route-specific (applied only to selected routes). Middleware can halt, redirect, modify requests, or even process responses before they're sent back to the client.

Creating Custom Middleware

Global Middleware

Generate middleware: php artisan make:middleware CustomGlobalMiddleware.[8]
Add logic in app/Http/Middleware/CustomGlobalMiddleware.php:

  public function handle($request, Closure $next)
  {
      // Custom logic here
      return $next($request);
  }

  protected $middleware = [
      // ... existing middleware,
      \App\Http\Middleware\CustomGlobalMiddleware::class,
  ];

Now the middleware runs for every HTTP request.

Route Middleware

Generate middleware: php artisan make:middleware CustomRouteMiddleware.
Add logic in app/Http/Middleware/CustomRouteMiddleware.php as above.
Register in app/Http/Kernel.php within $routeMiddleware:

  protected $routeMiddleware = [
      'custom' => \App\Http\Middleware\CustomRouteMiddleware::class,
  ];

Apply to route:

  Route::get('/example', function () {
      return 'Example Route';
  })->middleware('custom');

For groups:

  Route::middleware(['custom'])->group(function () {
      Route::get('/a', ...);
      Route::get('/b', ...);
  });

Passing Parameters to Middleware

Parameters can be sent to route middleware by appending them after a colon in the route definition:

Route::get('/post/{id}', 'PostController@show')->middleware('verify.role:admin');

In the middleware class, receive them as extra arguments:

public function handle($request, Closure $next, $role)
{
    // Check for required role
    return $next($request);
}

To access route parameters (like {id}) inside middleware:

$id = $request->route('id'); // Gets route param 'id'
$params = $request->route()->parameters(); // All parameters array

This lets you make your middleware context-aware and dynamic.

Quick Reference Table: Request Lifecycle Steps

Step	Purpose
Web Server	Receives & forwards HTTP request
index.php	Application entry, bootstraps Laravel
Kernel	Handles requests, global middleware
Service Providers	Register services
Router	Routes requests, applies route middleware
Controller/View	Core logic & generates response
Middleware	Filters/Processes requests & responses
Response	Sent back via Kernel & index.php

This sequence gives a robust, hands-on understanding of where middleware intercepts requests, how to build custom ones, and how parameters integrate with the lifecycle—all as essential for mastering Laravel’s request flow and middleware.