Forem: Muhabbat Ali

Ansible and GitOps: A Practical Guide

Muhabbat Ali — Tue, 30 Sep 2025 10:41:17 +0000

If you're in the DevOps space, you’ve probably used Ansible. You also can't miss the buzz around GitOps. This often leads to a big question: do you have to choose one over the other? The answer is a clear no. In fact, they work together remarkably well.

Ansible is great at telling systems how to perform a series of tasks. GitOps is a methodology focused on declaring what the end state should look like, using Git as the single source of truth. Combining them lets you manage everything, from your Kubernetes clusters to your legacy virtual machines, all from a single, version-controlled repository.

This post will show you how to blend Ansible’s powerful automation with a modern GitOps workflow.

Why Combine Ansible and GitOps?

Think of it like building a house. GitOps is the architect’s blueprint. It declaratively shows what the finished house should look like—three bedrooms, two bathrooms, a big kitchen. It is the desired state.

Ansible is the experienced construction crew. They have all the tools and skills to actually build the house based on that blueprint. They pour the foundation, frame the walls, and install the plumbing, handling the specific, step-by-step tasks.

While GitOps tools like Argo CD and Flux are excellent for managing Kubernetes resources (the blueprint part), they often can't handle tasks outside the cluster. What about provisioning a database on a VM or configuring a network switch? That’s where your Ansible "construction crew" comes in.

By using them together, you get:

A Single Source of Truth: Your Git repo can now describe the state of your entire infrastructure, not just Kubernetes.
Reuse Your Existing Work: There's no need to throw away all your battle-tested Ansible playbooks and roles.
Full Infrastructure Management: You can manage applications on Kubernetes and traditional systems with the same consistent, auditable workflow.

How to Make It Work

The key is to trigger your Ansible jobs based on changes in your Git repository. There are two common and effective ways to set this up.

1. The Operator Model (The Kubernetes-Native Way)

This is the most integrated approach if you're working heavily within Kubernetes. It involves using a Kubernetes Operator designed to run Ansible jobs. The Ansible Automation Platform (AAP) Operator is a popular choice, but other open-source options are also available.

Here’s the flow:

You commit a change to a YAML file in your Git repository. This file is a CustomResource that describes the Ansible job you want to run.
Your GitOps tool (like Argo CD) sees this change and applies the CustomResource to your cluster.
The Ansible Operator, which is always watching for these specific resources, sees the new object.
The Operator spins up a Pod and runs the Ansible playbook you specified.

Here is what that CustomResource might look like. It’s a simple, declarative request to run a playbook.

# ansible-run.yaml
apiVersion: automation.ansible.com/v1alpha1
kind: AnsibleJob
metadata:
  name: provision-new-vm
spec:
  # The playbook to run from your git repo
  playbook: "playbooks/provision-vm.yml"
  # Extra variables to pass to the playbook
  extra_vars:
    vm_name: "web-server-01"
    vm_size: "t2.micro"

When you commit this file, the GitOps process kicks off, and your VM gets provisioned automatically.

2. The CI/CD Pipeline Model (The Simple and Flexible Way)

If you don't want to run an operator inside Kubernetes, or if you're managing non-Kubernetes resources, a standard CI/CD pipeline is a fantastic choice. It's more straightforward and works with tools you already use, like GitHub Actions or GitLab CI.

The flow is very direct:

You push a change to your Git repository.
The push triggers a CI/CD pipeline (e.g., a GitHub Actions workflow).
The pipeline job checks out the repository.
The job runs the ansible-playbook command to apply the changes to your infrastructure.

Here’s a simple GitHub Actions workflow that runs a playbook on every push to the main branch.

# .github/workflows/ansible.yml
name: Run Ansible Playbook
on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Check out code
      uses: actions/checkout@v3

    - name: Run Ansible playbook
      uses: dawidd6/action-ansible-playbook@v2
      with:
        playbook: site.yml
        # Stored securely in GitHub Secrets
        key: ${{ secrets.SSH_PRIVATE_KEY }}
        inventory: |
          [webservers]
          app1.example.com

This approach is less "Kubernetes-native" but is incredibly effective and easy to set up.

Best Practices to Remember

Keep Playbooks Idempotent: An idempotent playbook can be run over and over, but it will only make changes the first time to reach the desired state. This is absolutely critical for reliable automation.
Manage Secrets Properly: Never, ever commit secrets like API keys or passwords to Git. Use a dedicated tool like HashiCorp Vault, AWS Secrets Manager, or Ansible Vault to manage them securely.
Use Roles for Reusability: Break your playbooks into reusable Ansible Roles. This keeps your code clean, organized, and much easier to maintain as your infrastructure grows.

Conclusion

Ansible and GitOps aren't competitors; they're partners. GitOps defines the "what"—the desired state of your system stored in Git. Ansible provides a powerful "how"—an engine that can make that state a reality across any part of your infrastructure.

By combining them, you get a robust, version-controlled, and automated system for managing everything. You can finally have one workflow to rule them all.

Originally published at https://muhabbat.dev/post/ansible-and-gitops-a-practical-guide/ on September 30, 2025.

7 Core components of Kubernetes every DevOps engineer should know

Muhabbat Ali — Sun, 28 Sep 2025 11:29:37 +0000

Kubernetes can feel complicated when you first start. It’s a powerful system with a lot of moving parts. But once you understand its core components, it all starts to make sense.

Think of Kubernetes like a busy restaurant kitchen. The head chef doesn't cook every meal. Instead, they direct a team of specialists who handle different tasks to get the food out. Kubernetes is the head chef for your applications, and its components are the specialists.

Let's walk through the seven key components that make it all work.

The Control Plane: The Brain of the Operation

The control plane is the management center. It makes all the decisions about the cluster, like scheduling applications and responding to failures. It’s the head chef and management staff of our restaurant.

1. API Server

The API Server is the front desk of the entire operation. Every request to view or change the state of the cluster goes through it. When you use kubectl, you are talking directly to the API Server. It validates and processes requests, then updates the cluster’s state in etcd.

Analogy: It’s the head waiter who takes all orders from customers (you) and communicates them to the kitchen staff (other components).

For example, this simple command asks the API Server for a list of all running pods.

kubectl get pods

2. etcd

etcd is the single source of truth for the entire cluster. It’s a simple, reliable key-value store that holds all configuration data and information about the state of the cluster. Everything from pod details to network configurations is stored here.

Analogy: This is the restaurant's official recipe book and order log. It stores exactly what was ordered and how it should be made. If there's any confusion, everyone checks this book.

3. Scheduler

The Scheduler’s job is to assign new pods to a worker node. It watches the API Server for newly created pods that have no node assigned. Then, based on resource needs, policies, and node availability, it picks the best node for that pod.

Analogy: The scheduler is the person who decides which chef (node) gets which cooking order (pod). It considers factors like how busy each chef is and if they have the right equipment (e.g., a GPU).

4. Controller Manager

The Controller Manager is a daemon that runs several controller processes in the background. Each controller is responsible for a specific part of the cluster. For example, the ReplicaSet controller makes sure the correct number of pods for an application is always running.

Analogy: It’s the kitchen manager who constantly checks if the orders are being made correctly. If a dish is ruined, the manager tells a chef to make a new one to fulfill the order. It works to make the current state match the desired state.

The Worker Nodes: Where the Work Gets Done

Worker nodes are the machines (virtual or physical) that run your applications. They are the kitchen stations where the actual cooking happens. Each worker node contains a few key components.

5. Kubelet

The Kubelet is an agent that runs on every single worker node. It receives instructions from the control plane via the API Server and makes sure the containers described in the pod specifications are running and healthy.

Analogy: The Kubelet is the station chef. It gets its orders and ensures the dish (container) is actually on the stove and cooking as specified in the recipe.

6. Kube Proxy

The Kube Proxy is a network proxy that runs on each node. Its job is to manage network connectivity for pods. It ensures that each pod gets a unique IP address and handles the routing of traffic to the correct pods based on IP addresses and port numbers.

Analogy: It’s the waiter inside the kitchen who knows exactly which dish goes to which service window. It manages all the internal traffic routes to make sure everything gets where it needs to go.

7. Pods

A Pod is the smallest and simplest unit in Kubernetes that you create or deploy. It represents a single instance of your application. A Pod can contain one or more containers, but most commonly, it runs just one. These containers share the same network and storage resources.

Analogy: A Pod is the final dish on a plate. The plate (Pod) holds the main item (your application container) and can also hold side items that support it (sidecar containers).

Here’s a simple YAML file that defines a Pod running a single Nginx container.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

When you apply this configuration, the Scheduler finds a node, and the Kubelet on that node starts the Nginx container.

Conclusion

Kubernetes isn't magic. It's a system with a clear separation of duties. The control plane acts as the brain, making decisions, while worker nodes do the actual work.

API Server: The front door.
etcd: The source of truth.
Scheduler: The decision-maker for placement.
Controller Manager: The enforcer of the desired state.
Kubelet: The agent on each node.
Kube Proxy: The network router.
Pods: The actual running applications.

By understanding these seven components, you’re no longer just using commands. You’re understanding how the system thinks, which is the key to debugging issues and building reliable applications on Kubernetes.

Originally published at https://muhabbat.dev/post/7-core-components-of-kubernetes-every-devops-engineer-should-know on September 28, 2025.

Reusable React Components With TypeScript: A Step By Step Guide

Muhabbat Ali — Fri, 26 Sep 2025 20:59:14 +0000

If you've written any React, you've probably found yourself copying and pasting a chunk of JSX for a button or a card. It works, but soon you have ten slightly different buttons, and changing one means changing all ten. It’s a pain.

Think of it like LEGOs. You don't create a brand new, unique brick every time you need a 2x4 piece. You just grab one from the box. That's what reusable components are. They are our LEGO bricks for building UIs. And when you add TypeScript, you make sure each brick only connects where it's supposed to.

This guide will show you how to create these simple, reusable components in React with TypeScript. No fluff, just practical steps.

Why Reusability Matters

Writing code that you can reuse is all about being efficient. It follows the DRY (Don't Repeat Yourself) principle. Instead of writing the same button styling and logic in five different places, you write it once in a component and use it everywhere.

The benefits are straightforward:

Easier to Maintain: Need to change the button color? You only have to edit one file.
Consistent UI: Your app looks and feels the same everywhere because you’re using the same core pieces.
Faster Development: You build faster by composing UIs from existing components instead of starting from scratch.

TypeScript adds a layer of safety. It makes sure you pass the right data (props) to your components, catching errors before they even happen.

The Core Idea A Simple Button Component

Let's start with a basic button. The goal is to create a component that can accept different text and handle a click event.

First, we define the "shape" of the data our component expects using a TypeScript type or interface. These are the component's props.

// Button.tsx

import React from 'react';

// Define the props our button will accept
type ButtonProps = {
  text: string;
  onClick: () => void; // A function that takes no arguments and returns nothing
};

export const Button = ({ text, onClick }: ButtonProps) => {
  return (
    <button onClick={onClick} style={{ padding: '10px 20px', cursor: 'pointer' }}>
      {text}
    </button>
  );
};

Here, ButtonProps tells us that our Button component must receive a text (string) and an onClick (function) prop.

Now, we can use it anywhere in our app:

// App.tsx

import { Button } from './Button';

function App() {
  const handleSave = () => {
    console.log('Saved!');
  };

  const handleCancel = () => {
    console.log('Canceled!');
  };

  return (
    <div>
      <Button text="Save Changes" onClick={handleSave} />
      <Button text="Cancel" onClick={handleCancel} />
    </div>
  );
}

We just used the same component to create two different buttons with different text and actions. Simple and clean.

Making Components More Flexible

A good reusable component is flexible. Let's add some common features.

Handling Different Variants

What if you need a primary button for main actions and a secondary one for less important ones? This is like a t-shirt that comes in different colors. We can add a variant prop.

Let's update our ButtonProps to include an optional variant.

// Button.tsx

type ButtonProps = {
  text: string;
  onClick: () => void;
  variant?: 'primary' | 'secondary'; // Optional prop
};

export const Button = ({ text, onClick, variant = 'primary' }: ButtonProps) => {
  const style = {
    padding: '10px 20px',
    cursor: 'pointer',
    backgroundColor: variant === 'primary' ? 'blue' : 'gray',
    color: 'white',
    border: 'none',
  };

  return (
    <button onClick={onClick} style={style}>
      {text}
    </button>
  );
};

We used a TypeScript union type 'primary' | 'secondary' to restrict the possible values for variant. We also set a default value of 'primary' in the component. Now we can easily control the button's appearance.

// Usage in App.tsx
<Button text="Submit" onClick={handleSubmit} variant="primary" />
<Button text="Learn More" onClick={handleLearnMore} variant="secondary" />

Passing Children for Content

Sometimes you need more than just text inside a component. Maybe you want an icon next to the text in a button, or complex content inside a Card. This is what the children prop is for.

Let's build a Card component that can wrap any content.

// Card.tsx

import React from 'react';

type CardProps = {
  children: React.ReactNode; // This special type accepts anything React can render
};

export const Card = ({ children }: CardProps) => {
  const style = {
    padding: '16px',
    border: '1px solid #ddd',
    borderRadius: '8px',
    boxShadow: '0 2px 4px rgba(0,0,0,0.1)',
  };

  return (
    <div style={style}>
      {children}
    </div>
  );
};

The React.ReactNode type is very flexible. Now we can put anything inside our card.

// App.tsx
import { Card } from './Card';

function App() {
  return (
    <Card>
      <h2>Welcome!</h2>
      <p>This is some content inside our reusable card component.</p>
      <Button text="Get Started" onClick={() => {}} />
    </Card>
  );
}

This pattern, called composition, is powerful. You build complex UI by putting simple components inside each other.

Final Tips for Great Reusable Components

Keep them focused. A component should do one thing well. A Button component shouldn't fetch data.
Define clear props. Your props are your component's API. Make them easy to understand with TypeScript.
Avoid specific business logic. A reusable component should be dumb. It just displays what you give it. Pass functions as props to handle logic.
Think about composition. Don't build a massive, all-in-one component. Build small, focused ones and combine them.

Conclusion

Building reusable components isn't a complex architectural decision; it’s a simple habit. It’s about thinking in terms of LEGOs instead of custom-carved parts. By starting with simple components, defining clear props with TypeScript, and focusing on composition, you write code that is cleaner, easier to maintain, and much faster to build with.

Flutter State Management: A Simple Guide to Provider, Riverpod, and Bloc

Muhabbat Ali — Thu, 25 Sep 2025 10:21:50 +0000

When you first start building a Flutter app, managing state feels simple. But as your app grows, passing data between screens can get messy. You end up with code that's hard to read and even harder to debug. This is where state management solutions come in.

Think of it like organizing a shared kitchen. At first, with just one person, you can leave things anywhere. But when more people start using it, you need a system—labels, shelves, designated areas—to keep things from becoming chaotic.

In this post, we'll look at three popular systems for Flutter: Provider, Riverpod, and BLoC. We'll use simple examples to see how they work and help you decide which one is right for your project.

What is State Anyway?

In simple terms, state is just data that can change over time. It’s the value of a counter, whether a user is logged in, or the list of items in a shopping cart. When this data changes, your UI needs to update to reflect it.

Without a proper system, you might find yourself passing data through many layers of widgets that don't even need it, a problem often called "prop drilling." A good state management solution gives you a clean way to access and modify your data from anywhere in your app.

Provider The Simple Starter

Provider is often the first state management tool Flutter developers learn. It’s built on top of Flutter's InheritedWidget but makes it much easier to use.

Imagine Provider as a central notice board in an office. Instead of asking every colleague for a piece of information, you just look at the board. Any widget that needs access to the state can get it directly, as long as it's a descendant of where the state is "provided."

How Provider Works

You create a model class that holds your state, usually with ChangeNotifier. Then you use a ChangeNotifierProvider to make that model available to the widgets below it.

Here’s a simple counter example.

1. Create the Counter Model

import 'package:flutter/material.dart';

class CounterModel extends ChangeNotifier {
  int _count = 0;
  int get count => _count;

  void increment() {
    _count++;
    notifyListeners(); // This tells widgets to rebuild
  }
}

2. Provide the Model
Wrap a widget high up in your tree (like MaterialApp) with ChangeNotifierProvider.

ChangeNotifierProvider(
  create: (context) => CounterModel(),
  child: MyApp(),
),

3. Use the State
Now, any widget within MyApp can access the CounterModel.

// To display the count
Text('Count: ${context.watch<CounterModel>().count}'),

// To call the increment function
ElevatedButton(
  onPressed: () => context.read<CounterModel>().increment(),
  child: Text('Increment'),
)

When to use Provider: It’s great for small to medium apps or when you're just starting. It’s simple to understand and gets the job done.

Riverpod The Modern Upgrade

Riverpod was created by the same author as Provider to fix some of its common issues. The biggest difference is that Riverpod is compile-safe and independent of the widget tree.

This means you get errors at compile time instead of runtime, and you don't need a BuildContext to access your state. It’s like getting information delivered directly to you via a dedicated messenger instead of having to walk to the central notice board.

A Simple Riverpod Example

With Riverpod, you define global "providers" that hold a piece of state.

1. Define a Provider
We'll use a StateNotifierProvider, which is perfect for managing state that can change.

// 1. Create a Notifier class
class CounterNotifier extends StateNotifier<int> {
  CounterNotifier() : super(0); // Initial state is 0
  void increment() => state++;
}

// 2. Create the provider (a global variable)
final counterProvider = StateNotifierProvider<CounterNotifier, int>((ref) {
  return CounterNotifier();
});

2. Set Up Your App
Wrap your entire application in a ProviderScope.

void main() {
  runApp(ProviderScope(child: MyApp()));
}

3. Use the State in a Widget
To use the provider, you change your StatelessWidget to a ConsumerWidget.

class CounterText extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // Rebuilds the widget when the counter changes
    final count = ref.watch(counterProvider);
    return Text('Count: $count');
  }
}

// In another widget, for the button
class IncrementButton extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return ElevatedButton(
      onPressed: () {
        // Get the notifier and call the increment method
        ref.read(counterProvider.notifier).increment();
      },
      child: Text('Increment'),
    );
  }
}

When to use Riverpod: It’s an excellent choice for new projects of any size. It’s more scalable and less error-prone than Provider.

BLoC The Predictable Powerhouse

BLoC (Business Logic Component) is a design pattern that separates your app's business logic from the UI. It's more structured and a bit more complex than Provider or Riverpod.

Think of BLoC as a strict assembly line. A request (an Event) goes in one end. It's processed according to a set of rules. A result (a State) comes out the other end. This flow is unidirectional and very predictable, which makes it great for testing and managing complex logic.

The BLoC Flow

UI sends an Event: A button press, text input, etc.
BLoC receives the Event: It processes the event and its logic.
BLoC emits a new State: The BLoC updates its state.
UI rebuilds: The UI listens for state changes and rebuilds itself accordingly.

BLoC Counter Example

Using the flutter_bloc package simplifies this pattern.

1. Define Events and States

// Events
abstract class CounterEvent {}
class IncrementEvent extends CounterEvent {}

// States (just an int for this simple case)
// For more complex features, this would be a class.

2. Create the BLoC

import 'package:bloc/bloc.dart';

class CounterBloc extends Bloc<CounterEvent, int> {
  CounterBloc() : super(0) { // Initial state is 0
    on<IncrementEvent>((event, emit) {
      emit(state + 1);
    });
  }
}

3. Provide and Use the BLoC

// Provide the BLoC at the top of the tree
BlocProvider(
  create: (context) => CounterBloc(),
  child: CounterPage(),
),

// Use BlocBuilder to listen to state changes and rebuild the UI
BlocBuilder<CounterBloc, int>(
  builder: (context, count) {
    return Text('Count: $count');
  },
),

// Add an event to the BLoC
ElevatedButton(
  onPressed: () => context.read<CounterBloc>().add(IncrementEvent()),
  child: Text('Increment'),
)

When to use BLoC: BLoC shines in large, complex applications where state logic is intricate and testability is a top priority. It has a steeper learning curve but provides a very robust structure.

So, Which One Should You Choose?

There is no single "best" solution. It depends on your project.

Provider: Use it for smaller apps or if you're a beginner. It's simple and effective.
Riverpod: A great default for most new projects. It’s powerful, flexible, and fixes the main drawbacks of Provider.
BLoC: Choose it for large-scale applications where you need a strict architecture and predictable state changes.

The most important thing is to pick a solution and use it consistently. Start simple, and don’t be afraid to try a different approach as your app and your skills grow.

Originally published at https://muhabbat.dev/post/flutter-state-management-guide-provider-riverpod-bloc on September 25, 2025.

The Complete Guide to API Versioning for Developers

Muhabbat Ali — Wed, 24 Sep 2025 14:20:34 +0000

The Complete Guide to API Versioning for Developers

You just shipped a brilliant API update. The code is cleaner, more efficient, and adds a powerful new feature. But a few hours later, the support channels are on fire. An important client's application is crashing because you renamed a field in a JSON response.

This scenario is a developer's nightmare, and it's precisely the problem API versioning solves. It's the contract between you and your API's consumers that says, "I will not break your application without warning."

Think of it like a video game update. When a developer releases a major patch that changes game mechanics, they don't force everyone to update immediately. Players can often choose to play on an older version. API versioning gives your users that same control, allowing them to upgrade when they are ready. This guide covers everything you need to know to handle API evolution gracefully.

Why API Versioning is Non-Negotiable

Software is never truly "done." We constantly refactor, add features, and fix bugs. These changes fall into two categories:

Non-breaking changes: These are safe additions. A new, optional field in a response or a completely new endpoint won't break existing clients. They can simply ignore the new stuff.

// V1 Response
{
  "id": 123,
  "username": "alex"
}

// V1.1 Response (Non-breaking)
{
  "id": 123,
  "username": "alex",
  "email": "alex@example.com" // New optional field
}

Breaking changes: These are modifications that will likely cause errors in client applications that haven't been updated.
- Changing a field's data type (e.g., an integer to a string).
- Renaming or removing a field.
- Adding a new required field to a request.
- Changing the authentication mechanism.
```
// V1 Response
{
  "id": 123,
  "user": {
    "firstName": "Alex",
    "lastName": "Williams"
  }
}

// V2 Response (Breaking Change)
{
  "id": 123,
  "fullName": "Alex Williams" // 'user' object removed and fields combined
}
```

Versioning is our strategy for introducing breaking changes without disrupting service for existing users. It’s a core part of building a stable and trustworthy API.

Four Key API Versioning Strategies

Let's explore the most common methods for implementing versioning, each with its own trade-offs.

1. URI Path Versioning

This is the most popular and straightforward approach. The version number is placed directly in the URL.

It’s like a bookstore organizing its editions on different shelves. The first edition is on the v1 shelf, and the second edition is on the v2 shelf. It's explicit and easy to find.

https://api.example.com/v1/users/123
https://api.example.com/v2/users/123

Pros:
- Extremely simple and obvious for API consumers.
- Easy to test different versions directly in a browser or cURL.
Cons:
- It clutters the URI. Purists argue that a URI should represent a resource, and its version is just a representation of that resource.

2. Query Parameter Versioning

This method involves passing the version number as a query parameter in the URL.

Think of it like using a filter on a shopping website. The page URL is the same, but adding ?color=blue changes the content you see.

curl "https://api.example.com/users/123?version=1"
curl "https://api.example.com/users/123?api_version=2"

Pros:
- Simple to implement and use.
- Doesn't "pollute" the URI path structure.
Cons:
- Can be less clean than URI pathing, as query parameters are often used for filtering and pagination. It can be easy to forget to include the version parameter.

3. Custom Header Versioning

Here, the client specifies the desired API version in a custom HTTP header. The URI remains clean and version-agnostic.

This is like going to a coffee shop where the main menu is the default, but you can request an "off-menu" item by giving the barista a special code (the header).

curl "https://api.example.com/users/123" \
  -H "X-API-Version: 2"

Your server code reads this header to route the request to the correct version's logic.

Pros:
- Keeps URIs clean and focused on the resource.
- Avoids cluttering the URI path or query string.
Cons:
- Less discoverable. You can't see the version just by looking at the URL.
- Requires specialized tools like Postman or cURL for testing; not as simple as pasting a URL into a browser.

4. Media Type Versioning (Content Negotiation)

This is the most technically "correct" RESTful approach. The version is included in the Accept header as part of a custom media type.

This is like asking a library for a book (the resource) but specifying you want the application/vnd.shakespeare.v1+text version (a specific edition and format).

curl "https://api.example.com/users/123" \
  -H "Accept: application/vnd.example.v1+json"

Pros:
- Leverages built-in HTTP mechanisms for content negotiation.
- Allows for versioning individual resources, not just the entire API.
Cons:
- The most complex and least intuitive method for many developers.
- The syntax is clunky and less user-friendly.

Best Practices Beyond the Strategy

Choosing a method is just the first step. A complete versioning plan includes:

Have a Default Version: What happens if a client makes a request without specifying a version? A good practice is to default to your earliest stable version (e.g., v1) rather than the latest one. This prevents you from accidentally breaking older clients when you release a new version.
Establish a Deprecation Policy: You can't support old versions forever. Create a clear policy for sunsetting old versions. Communicate this timeline clearly to your users (e.g., "v1 will be deprecated in 6 months and fully decommissioned in 12 months").
Communicate Clearly: Use a public changelog, developer emails, and API documentation to announce new versions, list breaking changes, and provide migration guides.

Organize Your Code: Manage versions cleanly in your codebase. A common pattern in many web frameworks is to organize controllers or handlers by version.

/api/
├── v1/
│   ├── userController.js
│   └── productController.js
└── v2/
    ├── userController.js
    └── productController.js

Conclusion: Which Strategy is Right for You?

There's no single "best" strategy; the right choice depends on your API's audience and goals.

For public APIs, URI Path Versioning is often the winner. It's explicit, easy to document, and simple for developers to use and test.
For internal APIs, where the client and server teams are in close communication, Header Versioning is a great choice for maintaining clean URIs.

Ultimately, API versioning is about building a predictable and reliable platform. By planning for change from the beginning, you build trust with your users and empower them to innovate on your platform without fear. The most important step is to choose a strategy, document it, and apply it consistently.

Originally published at https://muhabbat.dev/post/the-complete-guide-to-api-versioning-for-developers/ on September 24, 2025.

Build a Real-Time Chat App with Flutter and Supabase

Muhabbat Ali — Tue, 23 Sep 2025 10:00:24 +0000

Real-time chat is a core feature in many modern applications, from social media to customer support. Building one from scratch can seem complex, but with the right tools, it’s more accessible than you think. In this tutorial, we’ll build a complete chat application using Flutter for the cross-platform frontend and Supabase for a powerful, scalable backend.

We will walk through setting up your project, creating the user interface, and implementing real-time messaging with Supabase’s powerful PostgreSQL database and Realtime API, with detailed code explanations along the way.

Why Flutter and Supabase?

Before we dive in, let’s quickly talk about this tech stack. Flutter allows us to build beautiful, natively compiled applications for mobile, web, and desktop from a single codebase. Supabase is an open-source Firebase alternative that provides a suite of backend tools, including a database, authentication, and real-time subscriptions, making it incredibly easy to get started.

Together, they create a powerful combination for building a feature-rich chat app efficiently.

Setting Up the Supabase Backend

The first step is to configure our backend. Supabase makes this process simple.

1. Create a Supabase Project

If you don't have an account, head over to supabase.com and sign up. Once you're in, create a new project. Give it a name, generate a secure database password, and choose a region. Your project will be ready in a couple of minutes.

2. Create the `messages` Table

Next, we need a table to store our chat messages.

Navigate to the Table Editor in your Supabase dashboard.
Click Create a new table.
Name the table messages.
Disable Row Level Security (RLS) for now to make development easier. We can enable it later for production.
Add the following columns:

* `id`: `int8` (primary key, generated automatically).

* `created_at`: `timestamptz` (default value `now()`).

* `content`: `text`.

* `user_id`: `uuid` (to link messages to users, assuming you use Supabase Auth).

3. Enable Realtime

Supabase Realtime listens for database changes and broadcasts them to connected clients. To enable it for our messages table:

Go to Database > Replication.
Find your messages table and enable it for replication.

That’s it for the backend setup. Now let's move to the Flutter app.

Building the Flutter Chat App

With the backend ready, we can start building the frontend.

1. Project Setup and Dependencies

Create a new Flutter project and add the Supabase dependency to your pubspec.yaml file.

dependencies:
  flutter:
    sdk: flutter
  supabase_flutter: ^2.5.0 # Check for the latest version

Run flutter pub get to install the package. Next, initialize Supabase in your main.dart file. You can find your Project URL and anon key in your Supabase project's API Settings.

// main.dart
import 'package:flutter/material.dart';
import 'package:supabase_flutter/supabase_flutter.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized(); // Required for async main

  await Supabase.initialize(
    url: 'YOUR_SUPABASE_URL',
    anonKey: 'YOUR_SUPABASE_ANON_KEY',
  );
  runApp(MyApp());
}

final supabase = Supabase.instance.client;

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Chat App',
      home: ChatPage(), // We will create this next
    );
  }
}

2. Building the Chat Page

Let's create a new file, chat_page.dart, and build our UI. We'll use a StatefulWidget to manage the message stream and the text input controller.

The core of our real-time functionality is the StreamBuilder. This widget listens to a stream of data and rebuilds its UI whenever new data arrives.

// chat_page.dart
import 'package:flutter/material.dart';
import 'package:supabase_flutter/supabase_flutter.dart';

class ChatPage extends StatefulWidget {
  @override
  _ChatPageState createState() => _ChatPageState();
}

class _ChatPageState extends State<ChatPage> {
  final _textController = TextEditingController();
  final _messagesStream = Supabase.instance.client
      .from('messages')
      .stream(primaryKey: ['id']).order('created_at');

  @override
  void dispose() {
    _textController.dispose();
    super.dispose();
  }

  Future<void> _sendMessage() async {
    final content = _textController.text.trim();
    if (content.isEmpty) {
      return;
    }
    _textController.clear();

    // For this example, we assume a user is signed in.
    // Replace with your actual user management logic.
    final userId = Supabase.instance.client.auth.currentUser?.id;
    if (userId == null) {
        ScaffoldMessenger.of(context).showSnackBar(const SnackBar(
            content: Text('You must be logged in to send a message.'),
        ));
        return;
    }

    await Supabase.instance.client.from('messages').insert({
      'content': content,
      'user_id': userId,
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Real-Time Chat')),
      body: Column(
        children: [
          Expanded(
            child: StreamBuilder<List<Map<String, dynamic>>>(
              stream: _messagesStream,
              builder: (context, snapshot) {
                if (snapshot.hasError) {
                  return Center(child: Text('Error: ${snapshot.error}'));
                }
                if (!snapshot.hasData) {
                  return const Center(child: CircularProgressIndicator());
                }

                final messages = snapshot.data!;
                return ListView.builder(
                  reverse: true, // Show newest messages at the bottom
                  itemCount: messages.length,
                  itemBuilder: (context, index) {
                    final message = messages[index];
                    return ListTile(
                      title: Text(message['content']),
                      subtitle: Text(message['created_at']),
                    );
                  },
                );
              },
            ),
          ),
          _MessageComposer(), // The input field
        ],
      ),
    );
  }

  // A helper widget for the message input field
  Widget _MessageComposer() {
    return Container(
      padding: const EdgeInsets.symmetric(horizontal: 8.0),
      child: Row(
        children: [
          Expanded(
            child: TextField(
              controller: _textController,
              decoration: InputDecoration(
                hintText: 'Enter your message...',
                border: OutlineInputBorder(
                  borderRadius: BorderRadius.circular(20),
                ),
              ),
            ),
          ),
          IconButton(
            icon: const Icon(Icons.send),
            onPressed: _sendMessage,
          ),
        ],
      ),
    );
  }
}

3. Understanding the Code

Let's break down the key parts of our ChatPage widget.

The Message Stream

final _messagesStream = Supabase.instance.client
    .from('messages')
    .stream(primaryKey: ['id']).order('created_at');

Supabase.instance.client.from('messages'): This targets our messages table in the Supabase database.
.stream(primaryKey: ['id']): This is the magic function. It creates a WebSocket connection to Supabase and listens for any changes (inserts, updates, deletes) in the messages table. The primaryKey is required for Supabase to efficiently track changes.
.order('created_at'): We sort the messages by their creation timestamp to ensure they are displayed in the correct order.

The `StreamBuilder` Widget

The StreamBuilder connects our UI to the _messagesStream.

StreamBuilder<List<Map<String, dynamic>>>(
  stream: _messagesStream,
  builder: (context, snapshot) {
    // ... handle loading, error, and data states
  }
)

stream: We pass our _messagesStream here.
builder: This function is called every time a new event arrives on the stream. The snapshot object contains the latest data.
State Handling: We check snapshot.hasData to see if we have messages. If not, we show a loading indicator. If there's an error, we display it.
Displaying Data: When data is available (snapshot.data!), we use a ListView.builder to efficiently render the list of messages.

Sending a Message

The _sendMessage function handles the logic for sending a new message.

Future<void> _sendMessage() async {
  final content = _textController.text.trim();
  if (content.isEmpty) {
    return; // Don't send empty messages
  }
  _textController.clear();

  // Get current user's ID
  final userId = Supabase.instance.client.auth.currentUser?.id;

  // Insert the new message into the database
  await Supabase.instance.client.from('messages').insert({
    'content': content,
    'user_id': userId,
  });
}

We get the text from our _textController.
We perform a database insert operation on the messages table.
Once the new row is inserted, Supabase's Realtime feature automatically detects this change and broadcasts it to all connected clients.
Our StreamBuilder receives the new data and instantly rebuilds the UI to show the new message. No manual state management (setState) is needed for the message list!

Conclusion

We've successfully built a functional, real-time chat application using Flutter and Supabase. We went from setting up a Supabase project and database table to building a complete Flutter UI that sends and receives messages in real-time. The magic lies in Supabase's stream functionality and Flutter's StreamBuilder widget, which together handle all the complexity of real-time data synchronization.

This is just the beginning. You can expand this project by implementing a full authentication flow with Supabase Auth, adding user profiles, displaying usernames next to messages, and enabling Row Level Security for a production-ready application. The combination of Flutter and Supabase provides a powerful and efficient foundation for building modern, scalable apps.

Originally published at https://muhabbat.dev/post/build-a-real-time-chat-app-with-flutter-and-supabase/ on September 17, 2025.

Unlock PostgreSQL Performance: A Practical Tuning Guide

Muhabbat Ali — Tue, 23 Sep 2025 09:53:27 +0000

Is your application slowing down? Often, the bottleneck isn't the code but a poorly tuned PostgreSQL database. PostgreSQL is an incredibly powerful and reliable database, but its default configuration is designed for broad compatibility, not peak performance. To get the most out of it, you need to tailor it to your specific workload.

This guide moves beyond the basics and gives you practical, advanced techniques to diagnose issues and boost your database speed. We’ll cover everything from smart indexing to essential maintenance routines that keep your database running smoothly.

Understanding the Core of PostgreSQL Performance

Before we dive into specific tips, it’s helpful to know what’s happening under the hood. PostgreSQL performance largely depends on how efficiently it can find and process data. Three key areas govern this:

Query Planner: This is the brain of your database. When you run a query, the planner evaluates different ways to execute it and chooses the one it estimates will be the fastest. Your job is to give it the right information and tools (like indexes) to make the best choice.
Memory Management: PostgreSQL uses memory to cache data and execute operations like sorting and joining. Properly configured memory settings ensure that frequently accessed data is served from fast RAM instead of slow disks.
Database Maintenance: Over time, databases can become fragmented or have outdated statistics. Regular maintenance keeps everything organized and ensures the query planner has accurate information.

Essential Tuning Techniques You Can Implement Today

Let's get into the actionable steps. These techniques will provide the biggest improvements in your PostgreSQL performance.

Master Your Indexing Strategy

Indexes are the single most effective tool for speeding up read queries. But simply adding an index to every column is a bad idea, as it slows down write operations (INSERT, UPDATE, DELETE). The key is to be strategic.

Use EXPLAIN to find slow queries: Identify queries that perform a Sequential Scan on a large table. This is often a sign that you need an index.
Go beyond the B-Tree: The default B-tree index is great for equality and range queries (=, <, >). But PostgreSQL offers more specialized index types:
- GIN (Generalized Inverted Index): Ideal for indexing array elements or full-text search.
- GiST (Generalized Search Tree): Useful for indexing geometric data and full-text search.
- Partial Indexes: This is a powerful feature. A partial index only covers a subset of rows in a table, defined by a WHERE clause. This results in smaller, faster indexes. For example, if you frequently query for active users, you can create an index just for them: CREATE INDEX idx_users_active ON users (id) WHERE status = 'active';

Analyze and Optimize Your Queries with EXPLAIN

You can't fix what you can't measure. The EXPLAIN command is your window into the query planner. It shows you exactly how PostgreSQL intends to execute your query.

To get even more detail, use EXPLAIN ANALYZE. This command actually runs the query and gives you the real execution time and row counts.

How to read the output:

Look for Sequential Scans on large tables. This means PostgreSQL is reading the entire table to find the data it needs. An Index Scan is usually much faster.
Check the cost. This is the planner's estimate of how much work the query will take. Your goal is to reduce this number.
Pay attention to the rows estimate versus the actual rows returned by ANALYZE. A large difference suggests the database statistics are out of date.

Configure Your Memory Settings Wisely

Tuning PostgreSQL's memory settings can dramatically reduce disk I/O. You'll make these changes in your postgresql.conf file.

shared_buffers: This is the most important memory setting. It defines how much memory PostgreSQL can use for its data cache. A good starting point is 25% of your system's RAM. Don't set it too high, as you need to leave memory for the operating system and other processes.
work_mem: This setting controls the memory used for sorting, hashing, and merging. If your queries involve complex sorts or joins that spill to disk, increasing work_mem can help. But be careful; this memory can be allocated per operation, so a high value with many concurrent connections can quickly exhaust your RAM.
maintenance_work_mem: This is the memory used for maintenance tasks like VACUUM and CREATE INDEX. Setting this higher can significantly speed up these operations.

Don't Forget Database Maintenance

A well-oiled machine needs regular upkeep. For PostgreSQL, this means running VACUUM and ANALYZE.

VACUUM: Recovers space occupied by dead rows (rows that were updated or deleted). The autovacuum daemon handles this automatically, but you may need to tune its settings for heavily updated tables.
ANALYZE: Collects statistics about the data distribution in your tables. The query planner uses these statistics to make smart decisions. Out-of-date stats can lead to poor query plans.
Table Bloat: If tables are constantly updated and deleted, they can become "bloated" with empty space. While regular VACUUM helps, you might occasionally need to run VACUUM FULL to reclaim all the space. Warning: VACUUM FULL locks the table, so run it during a maintenance window.

Conclusion

PostgreSQL performance tuning isn't a one-time fix; it's an ongoing process of monitoring and refining. By focusing on the core pillars of indexing, query analysis, memory configuration, and regular maintenance, you can transform a slow database into a highly responsive one.

Start by identifying your slowest queries with tools like pg_stat_statements, use EXPLAIN to understand their behavior, and apply the techniques in this guide. Your users, and your servers, will thank you for it.

Originally published at https://muhabbat.dev/post/unlock-postgresql-performance-a-practical-tuning-guide/ on September 18, 2025.

Mastering Flutter BLoC A Practical Guide

Muhabbat Ali — Tue, 23 Sep 2025 09:49:22 +0000

State management is a critical part of any Flutter application. As your app grows, managing how data flows can get complicated. This is where a solid architectural pattern comes in, and for many Flutter developers, BLoC is the answer.

The BLoC (Business Logic Component) pattern helps separate your app's business logic from its UI, leading to code that is easier to test, maintain, and scale. But just knowing about BLoC isn’t enough. Using it effectively is what makes the difference. This guide will walk you through a practical, code-heavy example to help you master the Flutter BLoC pattern.

What is BLoC and Why Use It

At its core, the BLoC pattern is a way to handle state in an application. It works by taking events from the UI, processing them in the business logic layer, and emitting new states back to the UI. The UI then rebuilds itself based on the new state.

The main benefits of using BLoC are:

Separation of Concerns: Your UI code only cares about rendering states and dispatching events. Your business logic is contained entirely within the BLoC, making it independent of the UI.
Testability: With business logic isolated, you can write unit tests for your BLoCs without needing to render any UI components.
Scalability: As your app grows, BLoC provides a clear and predictable way to manage state, preventing your codebase from becoming a tangled mess.

A Complete BLoC Example: Authentication Flow

Let's build a simple authentication feature to see how all the pieces of BLoC fit together. We'll cover defining events and states, implementing the BLoC, and connecting it to the UI.

Step 1: Defining States

First, we define the possible states our authentication feature can be in. A good approach is to use an abstract base class.

import 'package:equatable/equatable.dart';

abstract class AuthState extends Equatable {
  const AuthState();

  @override
  List<Object> get props => [];
}

// The initial state, before any user interaction
class AuthInitial extends AuthState {}

// The state when authentication is in progress
class AuthLoading extends AuthState {}

// The state when the user is successfully authenticated
class AuthSuccess extends AuthState {
  final String userToken; // Example data
  const AuthSuccess({required this.userToken});

  @override
  List<Object> get props => [userToken];
}

// The state when authentication fails
class AuthFailure extends AuthState {
  final String error;
  const AuthFailure({required this.error});

  @override
  List<Object> get props => [error];
}

Step 2: Defining Events

Next, we define the events that the UI can send to the BLoC to trigger state changes.

import 'package:equatable/equatable.dart';

abstract class AuthEvent extends Equatable {
  const AuthEvent();

  @override
  List<Object> get props => [];
}

// Event triggered when the user tries to log in
class AuthLoginRequested extends AuthEvent {
  final String email;
  final String password;

  const AuthLoginRequested({required this.email, required this.password});

  @override
  List<Object> get props => [email, password];
}

// Event triggered when the user logs out
class AuthLogoutRequested extends AuthEvent {}

Step 3: Implementing the BLoC

Now we create the AuthBloc itself. It will listen for AuthEvents and emit AuthStates in response. This is where your business logic lives.

import 'package:flutter_bloc/flutter_bloc.dart';
// Import your event and state files

class AuthBloc extends Bloc<AuthEvent, AuthState> {
  // You would typically inject a repository or service here
  // final AuthRepository authRepository;

  AuthBloc() : super(AuthInitial()) {
    on<AuthLoginRequested>(_onLoginRequested);
    on<AuthLogoutRequested>(_onLogoutRequested);
  }

  Future<void> _onLoginRequested(
    AuthLoginRequested event,
    Emitter<AuthState> emit,
  ) async {
    emit(AuthLoading());
    try {
      // Simulate a network call
      await Future.delayed(const Duration(seconds: 2));

      if (event.email == 'test@test.com' && event.password == 'password') {
        const token = 'fake-jwt-token';
        emit(const AuthSuccess(userToken: token));
      } else {
        throw 'Invalid credentials';
      }
    } catch (e) {
      emit(AuthFailure(error: e.toString()));
    }
  }

  Future<void> _onLogoutRequested(
    AuthLogoutRequested event,
    Emitter<AuthState> emit,
  ) async {
    // Clear user session, etc.
    emit(AuthInitial());
  }
}

Step 4: Connecting BLoC to the UI

To use our AuthBloc, we first need to provide it to our widget tree using BlocProvider. This is often done at the root of your app or the top of the relevant feature screen.

// main.dart or a similar entry point
runApp(
  BlocProvider(
    create: (context) => AuthBloc(),
    child: const MyApp(),
  ),
);

Now, within our UI, we can use BlocBuilder to listen for state changes and rebuild widgets, and BlocListener for one-time actions like navigation or showing a snackbar. A great widget that combines both is BlocConsumer.

Let's see it in a login page:

class LoginPage extends StatelessWidget {
  const LoginPage({super.key});

  @override
  Widget build(BuildContext context) {
    final emailController = TextEditingController();
    final passwordController = TextEditingController();

    return Scaffold(
      appBar: AppBar(title: const Text('Login')),
      body: BlocConsumer<AuthBloc, AuthState>(
        listener: (context, state) {
          // Listener for side-effects
          if (state is AuthFailure) {
            ScaffoldMessenger.of(context)
              ..hideCurrentSnackBar()
              ..showSnackBar(
                SnackBar(content: Text(state.error)),
              );
          } else if (state is AuthSuccess) {
            // Navigate to home screen on success
            Navigator.of(context).pushReplacementNamed('/home');
          }
        },
        builder: (context, state) {
          // Builder for rebuilding UI
          if (state is AuthLoading) {
            return const Center(child: CircularProgressIndicator());
          }

          return Padding(
            padding: const EdgeInsets.all(16.0),
            child: Column(
              mainAxisAlignment: MainAxisAlignment.center,
              children: [
                TextField(
                  controller: emailController,
                  decoration: const InputDecoration(labelText: 'Email'),
                ),
                TextField(
                  controller: passwordController,
                  obscureText: true,
                  decoration: const InputDecoration(labelText: 'Password'),
                ),
                const SizedBox(height: 20),
                ElevatedButton(
                  onPressed: () {
                    // Add the login event to the BLoC
                    context.read<AuthBloc>().add(
                          AuthLoginRequested(
                            email: emailController.text,
                            password: passwordController.text,
                          ),
                        );
                  },
                  child: const Text('Login'),
                ),
              ],
            ),
          );
        },
      ),
    );
  }
}

This example shows the full loop:

The UI dispatches an AuthLoginRequested event when the button is pressed.
The AuthBloc receives the event, emits an AuthLoading state.
The BlocConsumer rebuilds the UI to show a loading indicator.
The BLoC finishes its logic and emits either AuthSuccess or AuthFailure.
The BlocConsumer's listener triggers a navigation or a snackbar, and the builder updates the UI if needed.

Conclusion

The BLoC pattern can seem complex, but breaking it down into events, states, and the BLoC itself makes it manageable. By creating a clear, unidirectional flow of data, you can build applications that are robust, testable, and easy to scale.

The key takeaway is to let events drive your logic and states drive your UI. By fully embracing this separation, you'll be well on your way to mastering state management in your Flutter projects and writing cleaner, more maintainable code.

Originally published at https://muhabbat.dev on September 19, 2025.

A Developer's Guide to Cloud Computing

Muhabbat Ali — Tue, 23 Sep 2025 09:44:46 +0000

Remember the days of FTPing files to a shared hosting server? Or waiting weeks for IT to provision a new physical server for your project? As developers, we've come a long way. The force behind this massive shift in how we build, deploy, and scale applications is cloud computing.

If you still think of "the cloud" as just someone else's computer, you're missing the bigger picture. The cloud isn't just about hosting; it's a powerful toolkit that provides on-demand infrastructure, managed services, and powerful APIs that have become essential for modern software development. This guide breaks down what cloud computing really means for you, the developer.

What is Cloud Computing from a Coder's Perspective

At its core, cloud computing is about abstracting infrastructure. Instead of dealing with physical servers, networking hardware, and storage arrays, you interact with these resources through APIs. Need a new Linux instance? A few lines of code or a single CLI command can spin one up in seconds. Need a scalable database? You can provision one without ever touching a server rack.

This paradigm shift allows developers to:

Focus on code, not hardware: Let cloud providers like AWS, Azure, and GCP manage the physical infrastructure, so you can focus on building features.
Automate everything: Treat your infrastructure as code (IaC) using tools like Terraform or AWS CloudFormation to create reproducible and version-controlled environments.
Pay for what you use: Move from large capital expenditures (buying servers) to operational expenses (paying for compute time), making it easier to experiment and scale.

The Cloud Service Models A Developer's Breakdown

The old "pizza-as-a-service" analogy is fine for beginners, but for developers, it’s more useful to think about the service models in terms of control and responsibility.

Infrastructure as a Service (IaaS)

IaaS gives you the raw ingredients of cloud infrastructure: virtual machines, storage, and networking. You have maximum control over the operating system, runtime, and application configuration.

What it is: You're renting virtual servers (like Amazon EC2 or Azure VMs). You're responsible for installing software, managing security patches, and configuring the environment.
When to use it:
- When you need fine-grained control over the environment.
- For lifting and shifting legacy applications to the cloud.
- When you have very specific OS or software requirements that a PaaS doesn't support.

Platform as a Service (PaaS)

PaaS abstracts away the underlying OS and infrastructure management, providing a platform for you to deploy and manage applications. This is where many developers find the sweet spot between control and convenience.

What it is: You bring your code, and the platform handles the rest—deployment, load balancing, scaling, and OS updates. Think git push heroku main.
When to use it:
- For rapid development and deployment of web apps and APIs.
- When you want to focus entirely on application code and not on server management.
- Ideal for building cloud-native applications.
Examples: Heroku, AWS Elastic Beanstalk, Google App Engine.

Software as a Service (SaaS) and APIs

While end-users see SaaS as ready-to-use software (like Gmail or Slack), developers see SaaS as a collection of powerful, third-party APIs they can integrate into their applications.

What it is for developers: Instead of building complex features from scratch, you use a specialized service via its API.
When to use it:
- Payments: Integrate with Stripe instead of building a PCI-compliant payment gateway.
- Authentication: Use Auth0 or Okta instead of rolling your own user management system.
- Communications: Leverage Twilio for SMS and voice capabilities.

Why the Cloud is a Game Changer for Development

Adopting the cloud is about more than just cost savings; it fundamentally improves the entire software development lifecycle.

Accelerated Development: Spin up databases, message queues, and full environments in minutes. No more waiting for hardware.
Effortless Scalability: Is your app featured on a major blog? Auto-scaling groups can automatically add more server instances to handle the load and scale back down when traffic subsides.
The Power of Managed Services: Offload tedious operational tasks. Use Amazon RDS or Azure SQL Database to get a fully managed, patched, and backed-up database without ever needing to SSH into a server.
Enabling DevOps and CI/CD: The cloud is the foundation of modern DevOps. Services like AWS CodePipeline, Azure DevOps, and GitHub Actions leverage cloud infrastructure to automate building, testing, and deploying your code.

Key Cloud Technologies Every Developer Should Know

To be effective in a cloud environment, you need to be familiar with a few core concepts that have become industry standards.

1. Containers (Docker & Kubernetes)

Containers solve the classic "it works on my machine" problem. Docker packages your application and all its dependencies into a single, isolated container. Kubernetes then takes over, allowing you to run and manage these containers at scale across a cluster of machines.

2. Serverless Computing (FaaS)

Serverless, or Functions-as-a-Service (FaaS), takes abstraction a step further. You upload your code as individual functions (AWS Lambda, Google Cloud Functions, Azure Functions), and the cloud provider handles everything about executing it. You don't manage any servers, and you only pay for the milliseconds your code is actually running. It's perfect for event-driven architectures and APIs.

3. Infrastructure as Code (IaC)

IaC is the practice of managing and provisioning your infrastructure using code and configuration files. Tools like Terraform and AWS CloudFormation allow you to define your entire cloud stack—servers, databases, networks—in version-controlled files. This makes your infrastructure predictable, repeatable, and easy to tear down or replicate.

Your Next Steps in the Cloud

Cloud computing is no longer optional for developers; it’s a core competency. It provides a powerful set of tools that enable you to build more resilient, scalable, and innovative applications faster than ever before.

If you're just getting started, the best way to learn is by doing. All major providers (AWS, Azure, and GCP) offer generous free tiers. Pick one, think of a small project, and try deploying it using a PaaS solution or a serverless function. Your journey to becoming a cloud-native developer starts today.

Originally published at https://muhabbat.dev/post/a-developers-guide-to-cloud-computing/ on September 21, 2025.

Unlocking Claude: A Developer's Guide to Effective AI Prompting

Muhabbat Ali — Tue, 23 Sep 2025 09:32:19 +0000

You ask your AI assistant, Claude, to write a simple function. It gives you something that looks right but breaks on the first edge case. Or you ask it to explain a complex topic, and you get a generic, textbook answer. Sound familiar?

Many developers treat AI tools like a search engine, firing off simple questions and hoping for the best. But Claude is a powerful collaborator, not just a snippet generator. The difference between a frustrating experience and a productive one comes down to a single skill: how you write your prompts.

This guide will show you how to move from basic questions to expert-level prompts that get you the code, explanations, and architectural insights you actually need.

Why Your Claude Prompts Aren't Working

From a code perspective, the logic is simple: the output of a system is only as good as its input. This is especially true for AI. If a prompt is unclear or lacks critical details, Claude has to make assumptions. These assumptions often lead to generic code, incorrect logic, or incomplete solutions. Most ineffective prompts stem from a few common mistakes:

Vague Requests: Asking Claude to "write a login function" is too broad. It has no information about the language, framework, database, or authentication method you're using.
Lack of Context: Without seeing your existing code, database schema, or project requirements, the AI is just guessing. It can't know you prefer functional components in React or that your API needs to follow a specific JSON structure.
No Defined Output: You want code, but do you also want comments? Unit tests? An explanation of how it works? If you don't specify the desired output, you'll get a default response that might not be what you need.

The Core Principles of Effective Prompting for Developers

To get expert-level results, you need to think like a senior developer giving instructions to a junior pair programmer. Be clear, be specific, and provide all the necessary information upfront.

1. Provide Rich Context

Context is the most critical element of a good prompt. The more relevant details you provide, the more tailored and accurate Claude’s response will be. Always include the "what, why, and how" in your request.

Before:

"Write a Python function to fetch user data."

After:

"I'm using Python with the FastAPI framework and a PostgreSQL database with SQLAlchemy. Here is my SQLAlchemy model for the User table:
class User(Base):
   __tablename__ = 'users'
   id = Column(Integer, primary_key=True)
   username = Column(String, unique=True)
   email = Column(String, unique=True)
Write an asynchronous FastAPI path operation function to fetch a user by their ID. It should handle the case where the user is not found by raising a 404 HTTPException and return the user data."

The second prompt gives Claude the tech stack, existing code, and specific error handling requirements, leading to a much more useful and integrated solution.

2. Assign a Persona

Tell Claude who it should be. Assigning a role frames the conversation and influences the tone, style, and depth of the response. This helps it adopt the correct mindset for the task.

"Act as a senior software architect specializing in microservices..." for system design questions.
"You are a cybersecurity expert. Review the following Python code for potential security vulnerabilities like SQL injection or XSS."
"Behave as a patient tutor. Explain the concept of closures in JavaScript to someone who only knows object-oriented programming."

3. Define the Output Structure

Don't leave the format to chance. Tell Claude exactly how you want the information presented. This is especially useful for generating structured data, documentation, or test cases.

"Provide the output as a JSON object with the keys status, data, and error."
"Explain the pros and cons of using WebSockets versus server-sent events in a Markdown table."
"Generate the function and then add a separate block with three unit tests for it using the pytest framework."

4. Iterate and Refine

Your first prompt is the start of a conversation, not the end. Use follow-up questions to refine the output until it’s perfect.

"That’s a good start. Can you add JSDoc comments to the function?"
"Now refactor that code to make it more readable."
"What are the performance implications of this approach?"

Advanced Prompting Techniques

Once you've mastered the basics, you can use Claude for much more than just writing small functions.

Using Claude for System Design

Feed Claude a set of requirements and ask for architectural suggestions. It's a fantastic brainstorming partner for exploring different approaches before you commit to one.

Example Prompt:

"I need to design a scalable notification system for a social media app. Key requirements are real-time delivery, support for push and email notifications, and the ability to handle millions of users. Suggest a high-level architecture using AWS services and explain the role of each component (e.g., SQS, Lambda, SNS)."

Code Debugging and Refactoring

Instead of staring at a bug for an hour, paste the problematic code into Claude and ask for help. Provide the error message and any relevant context for the best results.

Example Prompt:

"Here is a piece of JavaScript that is supposed to filter an array of objects, but it's returning an empty array.
// [code snippet]
The error I'm seeing is TypeError: cannot read properties of undefined. Can you identify the bug and suggest a fix?"

Conclusion

Claude isn't here to replace developers; it's a tool to augment our skills. By moving away from simple, search-like queries and adopting a more deliberate, context-rich approach to prompting, you can transform your AI assistant from a simple code generator into a true development partner.

The key is to treat it like a technical conversation. Provide context, define your expectations, and iterate. Start applying these principles today, and you'll quickly see the difference in the quality and relevance of the results.

Can React Context Really Replace Redux or Zustand

Muhabbat Ali — Mon, 22 Sep 2025 22:00:00 +0000

As a developer, you’ve probably asked this question. With every new React project, we face the big decision: how should we manage state? For a long time, Redux was the default answer. Then came Context API, built right into React, and many wondered if we even needed external libraries anymore.

The short answer is: no, Context does not replace Redux or Zustand.

But the long answer is more interesting. They solve different problems. Thinking of it as a competition is the wrong way to look at it. Instead, let's figure out which tool is right for which job. This post will break it down with simple examples.

The Problem Prop Drilling

Before we compare tools, let's remember the problem we're trying to solve. In a React app, you often need to pass data from a top-level component to a deeply nested one. Passing that data through every single component in between is called "prop drilling."

Imagine you’re in a large office and you need to give a message to someone at the far end. Prop drilling is like telling the person next to you, who tells the person next to them, and so on, until the message finally arrives. It’s inefficient and annoying.

function App() {
  const user = { name: "Alex" };
  return <HomePage user={user} />;
}

function HomePage({ user }) {
  return <Header user={user} />;
}

function Header({ user }) {
  return <UserInfo user={user} />;
}

function UserInfo({ user }) {
  return <span>Hello, {user.name}</span>;
}

Here, HomePage and Header don't need the user object, but they have to pass it along. That’s prop drilling.

What is React Context

React Context is the built-in solution to prop drilling. It creates a central place to store data that can be accessed by any component in its tree, without passing props down manually.

Think of Context as a public announcement system in that same office. You make an announcement, and anyone who needs to hear it can listen in directly.

Here’s how you’d solve the prop drilling problem with Context:

import { createContext, useContext } from 'react';

// 1. Create the context
const UserContext = createContext(null);

function App() {
  const user = { name: "Alex" };
  // 2. Provide the value to the component tree
  return (
    <UserContext.Provider value={user}>
      <HomePage />
    </UserContext.Provider>
  );
}

function UserInfo() {
  // 3. Consume the value directly where it's needed
  const user = useContext(UserContext);
  return <span>Hello, {user.name}</span>;
}

// HomePage and Header no longer need to know about the user prop!
function HomePage() {
  return <Header />;
}
function Header() {
  return <UserInfo />;
}

It’s clean and simple. So why would we need anything else?

The Big Catch with Context Performance

Context has one major drawback. When the value in the Context Provider changes, every single component that consumes that context re-renders.

This is fine for data that doesn't change often, like a theme (dark/light mode) or user authentication status. But what if your context holds a large object with multiple values, and only one of them changes?

const AppStateContext = createContext({ cartCount: 0, userProfile: {} });

// Both components use the same context
function CartIcon() {
  const { cartCount } = useContext(AppStateContext);
  console.log("CartIcon re-rendered");
  return <div>Cart: {cartCount}</div>;
}

function UserProfile() {
  const { userProfile } = useContext(AppStateContext);
  console.log("UserProfile re-rendered");
  return <div>{userProfile.name}</div>;
}

If you update cartCount, both CartIcon and UserProfile will re-render, even though UserProfile doesn't care about the cart. In a large application, this causes serious performance issues.

Enter Redux and Zustand

This performance issue is the primary problem that libraries like Redux and Zustand solve. They are specialized state management tools designed to handle complex, frequently-changing state efficiently.

If Context is a public announcement system, Redux and Zustand are like targeted walkie-talkies. You can send a message to a specific person (or component) without bothering everyone else.

They achieve this through selectors. A selector lets a component subscribe to only the specific pieces of state it needs. If that specific piece of state changes, only that component re-renders.

Here’s a quick example using Zustand, which is known for its simplicity:

import create from 'zustand';

// 1. Create a "store" to hold your state
const useStore = create((set) => ({
  cartCount: 0,
  userProfile: { name: 'Alex' },
  incrementCart: () => set((state) => ({ cartCount: state.cartCount + 1 })),
}));

// 2. Components select only the state they need
function CartIcon() {
  const cartCount = useStore((state) => state.cartCount);
  console.log("CartIcon re-rendered");
  return <div>Cart: {cartCount}</div>;
}

function UserProfile() {
  const userProfile = useStore((state) => state.userProfile);
  console.log("UserProfile re-rendered");
  return <div>{userProfile.name}</div>;
}

Now, if you call incrementCart(), only CartIcon will re-render. UserProfile remains untouched because its selected state (userProfile) didn't change. This is a huge performance win.

So When Should You Use Which

Let's make it simple.

Use React Context when:

You are solving prop drilling for low-frequency updates.
The state is simple (e.g., theme, user info, language).
You're building a small to medium-sized app and want to avoid adding more libraries.

Use Redux or Zustand when:

You have a complex global state that changes often (e.g., items in a shopping cart, the state of a multi-step form, data from a real-time connection).
Performance is critical, and you need to prevent unnecessary re-renders.
You need powerful developer tools for debugging, like the Redux DevTools.
Your application is large and many different components rely on the same state.

Conclusion It's Not a Replacement

React Context is a fantastic tool for solving prop drilling, but it is not a state management library. It’s a dependency injection mechanism.

Libraries like Redux and Zustand are true state management solutions. They are built to handle the complexity and performance demands of large applications.

So, the next time you start a project, don't ask "Context or Redux?". Instead, ask "What kind of state am I managing?". Start with what React gives you. If your app grows and you feel the performance pain of Context, then reach for a dedicated tool like Zustand or Redux. Choose the right tool for the job.

Originally published at https://muhabbat.dev/post/can-react-context-really-replace-redux-zustand/ on September 21, 2025.

TypeScript Generics A Practical Guide to Reusable Code

Muhabbat Ali — Mon, 22 Sep 2025 16:09:14 +0000

TypeScript Generics A Practical Guide to Reusable Code

As a developer, you've probably faced this problem: you write a perfectly good function that works with numbers, but then you need the exact same logic for strings. Or arrays. So what do you do? You could copy and paste the function and change the types, but that leads to duplicate code. Or you could use the any type, but that throws away all the type safety that makes TypeScript great.

There’s a much better way. It’s called generics.

Generics are a core feature of TypeScript that lets you write functions, classes, and interfaces that are flexible and reusable, all without sacrificing type safety. This guide explains what generics are, why they are so useful, and how you can start using them with practical examples.

Why Are Generics So Useful?

Before diving into the code, it’s important to understand why generics are worth learning. They offer three huge benefits.

1. Write Reusable Code

The most immediate benefit is code reuse. Instead of writing a separate function for every data type, you can write one generic function that works for all of them. This means less code to write, less code to test, and less code to maintain.

2. Enforce Type Safety

Generics provide the flexibility of the any type without the risk. When you use any, you tell the TypeScript compiler to look the other way. With generics, you create a variable for types, so the compiler knows exactly what type you're working with at any given moment. This means you still get excellent autocompletion and error checking.

3. Create Flexible Components

Generics allow you to build components that can adapt to different data types. This is incredibly powerful for creating libraries, data structures, or utility functions that need to work in a variety of situations.

How Generics Work A Simple Example

The best way to understand generics is to see them in action. Let’s create a simple function called getFirstElement that takes an array and returns its first element.

Without generics, we might be forced to write multiple versions:

function getFirstString(arr: string[]): string {
  return arr[0];
}

function getFirstNumber(arr: number[]): number {
  return arr[0];
}

This is repetitive. Let's make it generic. We'll use a type variable, commonly named T, as a placeholder for the type.

function getFirstElement<T>(arr: T[]): T {
  return arr[0];
}

Let's break that down:

<T> right after the function name declares T as our generic type variable.
arr: T[] means the function accepts an array where all elements are of type T.
: T at the end means the function will return a value of type T.

Now we have one function that works for any type, and it’s completely type-safe.

const numbers = [1, 2, 3];
const firstNumber = getFirstElement(numbers); // Type is inferred as number

const strings = ["a", "b", "c"];
const firstString = getFirstElement(strings); // Type is inferred as string

TypeScript is smart enough to infer the type of T based on the argument we pass. We can also be explicit if we want to:

const firstStringExplicit = getFirstElement<string>(["a", "b", "c"]);

Useful Examples of Generics

Generics aren’t just for simple functions. They are incredibly useful for defining more complex structures like interfaces and classes.

Example 1 Generic Interfaces for API Responses

When working with APIs, the shape of the response is often consistent, but the data inside changes. A generic interface is perfect for this.

interface APIResponse<T> {
  success: boolean;
  data: T;
  error?: string;
}

interface User {
  id: number;
  name: string;
}

interface Product {
  id: string;
  price: number;
}

const userResponse: APIResponse<User> = {
  success: true,
  data: { id: 1, name: "John Doe" },
};

const productResponse: APIResponse<Product> = {
  success: true,
  data: { id: "abc-123", price: 99.99 },
};

Here, APIResponse<T> can be reused for any type of data payload, keeping our code consistent and type-safe.

Example 2 Generic Classes for Data Structures

Generics are also great for creating data structures that can hold any type of data. Let's build a simple Stack class.

class Stack<T> {
  private items: T[] = [];

  push(element: T): void {
    this.items.push(element);
  }

  pop(): T | undefined {
    return this.items.pop();
  }
}

const numberStack = new Stack<number>();
numberStack.push(10);
numberStack.push(20);
console.log(numberStack.pop()); // 20

const stringStack = new Stack<string>();
stringStack.push("hello");
stringStack.push("world");
console.log(stringStack.pop()); // "world"

This Stack class works seamlessly with numbers, strings, or any other type we want.

Conclusion

Generics are a fundamental tool in TypeScript for writing clean, reusable, and robust code. By allowing you to create components that work over a variety of types without sacrificing type safety, they help you build more powerful and maintainable applications.

If you’re not already using generics, start looking for opportunities in your code. The next time you find yourself writing duplicate logic for different types, it's the perfect time to write a generic instead.

Originally published at muhabbat.dev on September 1, 2025.

Forem: Muhabbat Ali

Ansible and GitOps: A Practical Guide

Why Combine Ansible and GitOps?

How to Make It Work

1. The Operator Model (The Kubernetes-Native Way)

2. The CI/CD Pipeline Model (The Simple and Flexible Way)

Best Practices to Remember

Conclusion

7 Core components of Kubernetes every DevOps engineer should know

The Control Plane: The Brain of the Operation

1. API Server

2. etcd

3. Scheduler

4. Controller Manager

The Worker Nodes: Where the Work Gets Done

5. Kubelet

6. Kube Proxy

7. Pods

Conclusion

Reusable React Components With TypeScript: A Step By Step Guide

Why Reusability Matters

The Core Idea A Simple Button Component

Making Components More Flexible

Handling Different Variants

Passing Children for Content

Final Tips for Great Reusable Components

Conclusion

Flutter State Management: A Simple Guide to Provider, Riverpod, and Bloc

What is State Anyway?

Provider The Simple Starter

How Provider Works

Riverpod The Modern Upgrade

A Simple Riverpod Example

BLoC The Predictable Powerhouse

The BLoC Flow

BLoC Counter Example

So, Which One Should You Choose?

The Complete Guide to API Versioning for Developers

The Complete Guide to API Versioning for Developers

Why API Versioning is Non-Negotiable

Four Key API Versioning Strategies

1. URI Path Versioning

2. Query Parameter Versioning

3. Custom Header Versioning

4. Media Type Versioning (Content Negotiation)

Best Practices Beyond the Strategy

Conclusion: Which Strategy is Right for You?

Build a Real-Time Chat App with Flutter and Supabase

Why Flutter and Supabase?

Setting Up the Supabase Backend

1. Create a Supabase Project

2. Create the messages Table

3. Enable Realtime

Building the Flutter Chat App

1. Project Setup and Dependencies

2. Building the Chat Page

3. Understanding the Code

The Message Stream

The StreamBuilder Widget

Sending a Message

Conclusion

Unlock PostgreSQL Performance: A Practical Tuning Guide

Understanding the Core of PostgreSQL Performance

Essential Tuning Techniques You Can Implement Today

Master Your Indexing Strategy

Analyze and Optimize Your Queries with EXPLAIN

Configure Your Memory Settings Wisely

Don't Forget Database Maintenance

Conclusion

Mastering Flutter BLoC A Practical Guide

What is BLoC and Why Use It

A Complete BLoC Example: Authentication Flow

Step 1: Defining States

Step 2: Defining Events

Step 3: Implementing the BLoC

Step 4: Connecting BLoC to the UI

Conclusion

A Developer's Guide to Cloud Computing

What is Cloud Computing from a Coder's Perspective

The Cloud Service Models A Developer's Breakdown

2. Create the `messages` Table

The `StreamBuilder` Widget