Forem: Usman Zahid

Architecting for system reliability and scalability demands clean foundational code.

Usman Zahid — Mon, 13 Oct 2025 09:28:29 +0000

Introduction

Building reliable and scalable systems requires a solid foundation. This foundation is not just about choosing the right architecture patterns or cloud services. It is fundamentally about the quality of the code we write. Clean foundational code directly impacts a system's ability to remain stable under load, adapt to growth, and be maintained over its lifecycle.

For developers, understanding this connection is crucial. Investing in clean code practices from the start reduces technical debt, prevents costly outages, and allows for more predictable scaling. It simplifies debugging, feature development, and overall system evolution, which are common challenges in backend development.

The Core of Clean Foundational Code

Clean foundational code is readable, maintainable, testable, and modular. When code embodies these qualities, it inherently supports reliability and scalability.

Defining Clean Code for Reliability and Scalability

Clean code makes it easier to understand system behavior, which reduces the likelihood of introducing bugs during changes. For reliability, this means fewer crashes or unexpected outcomes. For scalability, it means the system can be adapted or broken down into smaller, independently deployable services more easily, without significant refactoring overhead. A well-structured codebase allows teams to work on different parts of the system concurrently with fewer conflicts.

Modularity and Clear Interfaces

Breaking a system into distinct, self-contained modules with well-defined interfaces is critical. Each module should have a single responsibility. For example, in a Laravel application, this means separating business logic into dedicated services, handling data persistence through repositories, and keeping controllers lean.

This separation reduces coupling between components. When one part of the system needs to scale, or an issue arises, changes can be isolated to that module. This prevents cascading failures and simplifies horizontal scaling by making components easier to distribute across different servers or containers.

Predictable Data Flow and State Management

Systems become more reliable when their data flow is predictable. Avoid global mutable state where possible. Use immutable data structures when practical. Ensure clear request and response cycles.

For example, when processing a user request, the data should follow a clear path through validation, business logic, and data persistence. Unintended side effects from shared state or unclear data transformations can lead to difficult-to-diagnose bugs, which impact reliability. Predictable state management also simplifies reasoning about system behavior under high concurrency, a key aspect of scalability.

Robust Error Handling and System Resilience

A reliable system anticipates failures. Clean code includes structured error handling, such as using custom exceptions for different error conditions. It also involves consistent logging of critical errors, warnings, and informational messages. This ensures that when issues occur, they are caught, reported, and can be debugged efficiently.

Beyond basic error handling, foundational code can incorporate resilience patterns. This includes implementing retry mechanisms with exponential backoff for external service calls or database connections, and circuit breakers to prevent system overloads when a dependency is failing. These patterns allow a system to gracefully degrade or recover, maintaining uptime and stability.

Performance Considerations from the Outset

Scalability is directly tied to performance. Foundational code should be written with performance in mind. This does not mean premature optimization, but rather making sensible choices regarding algorithms, data structures, and database interactions.

For instance, understanding and avoiding N+1 query problems in ORMs like Eloquent, by using eager loading, is a basic but critical optimization. Designing efficient database schemas with appropriate indexing also falls into this category. These early considerations prevent bottlenecks that would otherwise become major scaling challenges later on.

The Role of Automated Testing

Automated tests, including unit, integration, and end to end tests, are an integral part of clean foundational code. They provide a safety net, allowing developers to refactor and introduce new features with confidence, knowing that existing functionality remains intact.

This confidence is vital for both reliability and scalability. For reliability, tests catch regressions before they impact production. For scalability, tests enable aggressive refactoring needed to optimize performance or re-architect components for distributed environments, without fear of breaking the system.

Tips and Tricks

Prioritize Readability: Code that is easy to read is easier to understand, debug, and maintain. Use clear variable names, logical structure, and avoid overly clever constructs.
Continuous Refactoring: Schedule regular time to address technical debt. Small, consistent improvements prevent codebases from becoming unmanageable.
Small, Focused Functions: Functions and methods should do one thing and do it well. This makes them easier to test, reason about, and reuse.
Meaningful Naming: Variables, functions, and classes should accurately describe their purpose. This reduces ambiguity and the need for excessive comments.
Regular Code Reviews: Peer reviews help maintain code quality standards, share knowledge, and catch potential issues early.
Don't Over Engineer: Solve the current problem cleanly. Avoid building overly complex abstractions for theoretical future requirements that may never materialize.

Takeaways

Architecting for system reliability and scalability begins with clean foundational code. This is not an optional luxury but a core technical requirement. By focusing on modularity, predictable data flow, robust error handling, performance awareness, and comprehensive automated testing, developers lay the groundwork for systems that can confidently handle growth and maintain stability. Investing in these practices early and consistently leads to more resilient, maintainable, and cost-effective solutions in the long run.

Implement effective API versioning strategies for your evolving services.

Usman Zahid — Mon, 13 Oct 2025 09:27:55 +0000

Implementing effective API versioning strategies is crucial for managing changes to your services over time. It allows you to evolve your APIs, adding new features or making necessary alterations, without immediately breaking existing client applications. This ensures stability for your consumers and reduces operational overhead for your development teams.

Proper versioning is a fundamental practice in backend development, preventing unexpected outages or costly reworks for your users. It enables controlled evolution of your services, ensuring that different client versions can coexist and migrate at their own pace.

API Versioning Strategies

Several common strategies exist for API versioning, each with its own advantages and considerations.

1. URI Path Versioning

This strategy embeds the API version directly into the Uniform Resource Identifier, URI.
Example: GET /v1/products, GET /v2/products

Advantages:

Discoverability: The version is immediately visible in the URL.
Caching: Different versions are treated as distinct resources, simplifying caching.
Simplicity: Easy to implement and understand.

Considerations:

URI Sprawl: Can lead to longer URLs and duplicated routing definitions.
Not Purely RESTful: Some argue that a URI should represent a resource, not a version of that resource.

Example, Laravel Routing:

// routes/api.php
Route::prefix('v1')->group(function () {
    Route::get('/products', [App\Http\Controllers\Api\V1\ProductController::class, 'index']);
});

Route::prefix('v2')->group(function () {
    Route::get('/products', [App\Http\Controllers\Api\V2\ProductController::class, 'index']);
});

2. Query Parameter Versioning

The API version is passed as a query parameter in the request.
Example: GET /products?api-version=1, GET /products?api-version=2

Advantages:

Clean URIs: The base URI for a resource remains consistent.
Flexibility: Clients can easily switch versions by changing a parameter.

Considerations:

Less Discoverable: The version is not part of the primary URI.
Caching Issues: Caching can be more complex if not configured to include query parameters.
Consistency: Requires careful implementation to ensure the parameter is always handled.

Example, Laravel Request Handling:

// App\Http\Controllers\Api\ProductController.php
public function index(Request $request)
{
    $version = $request->query('api-version', '1'); // Default to v1
    if ($version === '2') {
        // Return V2 product data
    }
    // Return V1 product data
}

3. Custom Header Versioning

Clients specify the desired API version using a custom HTTP header.
Example: GET /products with X-API-Version: 1 or Accept-Version: 2

Advantages:

Clean URIs: Keeps the resource URI clean and consistent.
RESTful: Aligns well with REST principles, as the header describes a characteristic of the request.

Considerations:

Less Discoverable: Requires prior knowledge of the custom header.
Browser Testing: Can be more cumbersome to test directly in a browser without specific tools.
Firewall/Proxy Issues: Some proxies or firewalls might strip or modify custom headers.

Example, Laravel Middleware:

// App\Http\Middleware\ApiVersionCheck.php
class ApiVersionCheck
{
    public function handle($request, Closure $next)
    {
        $apiVersion = $request->header('X-API-Version', '1'); // Default to v1
        if ($apiVersion === '2') {
            // Apply logic or route to V2 controllers
            // This could involve setting a global state or rewriting the request.
        }
        return $next($request);
    }
}

4. Content Negotiation Versioning (Accept Header)

This strategy leverages the standard HTTP Accept header to indicate the desired media type, including the API version.
Example: GET /products with Accept: application/vnd.company.v1+json, Accept: application/vnd.company.v2+json

Advantages:

Most RESTful: Uses a standard HTTP mechanism for content negotiation.
Clean URIs: Keeps resource URIs pristine.
Flexibility: Allows for different representations of the same resource.

Considerations:

Complexity: The Accept header format can be complex for clients.
Readability: Less human-readable than URI or query parameter versions.
Browser Testing: Similar to custom headers, direct browser testing is difficult.

Example, Laravel Request Handling:

// App\Http\Controllers\Api\ProductController.php
public function index(Request $request)
{
    if ($request->accepts('application/vnd.company.v2+json')) {
        // Return V2 product data with V2 specific content type
        return response()->json(/* V2 data */)->header('Content-Type', 'application/vnd.company.v2+json');
    }
    // Default to V1 product data with V1 specific content type
    return response()->json(/* V1 data */)->header('Content-Type', 'application/vnd.company.v1+json');
}

When to Version Your API

You should introduce a new API version when making a breaking change. A breaking change is any modification that could cause existing clients to fail or behave unexpectedly if they are not updated.

Examples of breaking changes:

Removing an endpoint or a field from a response.
Changing the data type of a field, for example, from string to integer.
Altering an endpoint's path or HTTP method.
Modifying the required format of a request body.
Changing error response structures or HTTP status codes.
Introducing new mandatory request parameters.

Non-breaking changes, which typically do not require a new version:

Adding new optional fields to a response.
Adding new endpoints.
Adding new HTTP methods to existing endpoints, provided old methods still work.
Adding new optional request parameters.

API Lifecycle and Deprecation

When you introduce a new API version, you will likely need to support the previous version concurrently for a period.

Support Period: Define a clear policy for how long older versions will be supported.
Communication: Clearly communicate new versions, changes, and deprecation timelines to your API consumers well in advance. Provide detailed migration guides.
Sunset Dates: Enforce a firm sunset date for deprecated versions. This encourages migration and reduces the burden of maintaining multiple codebases indefinitely.
Monitoring: Monitor the usage of older API versions. This data helps in making informed decisions about deprecation timelines.

Tips and Tricks

Choose Early: Select a versioning strategy early in your API development lifecycle to avoid rework.
Consistency is Key: Apply your chosen strategy consistently across your entire API.
Default Version: Always provide a default version for requests that do not explicitly specify one. This helps new clients get started without immediate versioning concerns.
Documentation: Maintain comprehensive, versioned API documentation. Tools like OpenAPI/Swagger can help.
Backward Compatibility: Strive for backward compatible changes whenever possible to minimize the need for new versions.
Versioning Granularity: Generally, version the entire API or a major section of it, rather than individual endpoints. This simplifies client-side logic.
Graceful Deprecation: Provide ample warning and a clear migration path when deprecating a version. Consider returning specific deprecation headers, like Sunset or Warning, from the deprecated API.
Infrastructure Support: Ensure your infrastructure, including load balancers, API gateways, and CI/CD pipelines, can handle multiple API versions efficiently.

Takeaways

API versioning is essential for building robust and evolvable services. Choose a strategy that aligns with your project's needs and your team's expertise. Prioritize clear communication with your API consumers, provide thorough documentation, and plan for the eventual deprecation of older versions. Consistent application of your chosen strategy and proactive management of API changes will ensure a stable and reliable experience for all users.

Design your Laravel database schema for optimal query performance.

Usman Zahid — Mon, 08 Sep 2025 19:01:36 +0000

Designing an efficient database schema is fundamental for any scalable Laravel application. A well-structured schema directly translates to faster query execution, reduced server load, and a better user experience. This document outlines practical considerations for building database schemas that perform optimally under various loads.

Neglecting schema design often leads to performance bottlenecks as applications grow. Understanding how your data is stored and accessed is key to preventing these issues before they impact production.

Normalization and Denormalization

Database normalization aims to reduce data redundancy and improve data integrity. It organizes tables to eliminate duplicate data and ensure data dependencies make sense. While this is a good starting point, strict normalization can sometimes lead to excessive table joins, which can slow down read operations.

Denormalization involves intentionally introducing redundancy to improve read performance. For example, if you frequently need a product's name and price when querying order items, you might store these details directly in the order_items table instead of always joining to the products table. This reduces join overhead but requires careful handling to keep redundant data consistent during updates.

Practical approach: Start with a normalized design. Identify specific, read-heavy queries that perform poorly. Consider denormalization for those particular cases, weighing the read performance gain against the increased complexity of data consistency.

Indexing Strategies

Indexes are crucial for speeding up data retrieval. They allow the database to quickly locate rows without scanning the entire table.

Foreign Keys: Always index foreign key columns. These are heavily used in JOIN operations, and an index drastically improves join performance. Laravel's foreignId()->constrained() helper automatically creates an index.
WHERE clauses: Index columns frequently used in WHERE clauses to filter results.
ORDER BY and GROUP BY: Columns used for sorting or grouping data benefit from indexes.
Composite Indexes: For queries that filter or sort on multiple columns, a composite index (an index on more than one column) can be more efficient than multiple single-column indexes. The order of columns in a composite index matters; place the most discriminative column first.

Caution: Over-indexing can degrade write performance, as every index must be updated on data modification. Indexes also consume disk space. Regularly review your indexes based on query analysis.

Example using Laravel Migrations:

Schema::table('products', function (Blueprint $table) {
    // Automatically indexed by unique constraint
    $table->string('sku')->unique();

    // Single column index
    $table->index('category_id');

    // Composite index for efficient filtering and sorting by status and creation date
    $table->index(['status', 'created_at']);
});

Choosing Appropriate Data Types

Selecting the correct data types for your columns impacts storage efficiency and query performance. Smaller, more precise types generally perform better.

Integers: Use unsignedInteger for IDs where negative values are not possible. For small enumerated values, consider tinyInteger or smallInteger.
Strings: Use varchar with an appropriate maximum length, avoiding excessively large lengths if data is typically shorter. Use text only for truly long strings.
Dates: Use timestamp or datetime for date and time values. Storing dates as strings prevents efficient date-based queries and comparisons.
Booleans: Use boolean or tinyInteger(1) for true/false values.
JSON: The json data type is useful for semi-structured data, but querying nested JSON efficiently might require specific database functions or JSON path indexes, which can be more complex than querying relational columns.

Relationships and Foreign Keys

Defining relationships with foreign key constraints enforces referential integrity. This prevents orphaned records and helps the database optimizer understand the data model, potentially leading to better query plans. Laravel's Eloquent relationships build on these underlying database constraints.

Example:

Schema::table('posts', function (Blueprint $table) {
    $table->foreignId('user_id')
          ->constrained() // Automatically adds a foreign key constraint and an index
          ->onDelete('cascade'); // Example: delete posts if user is deleted
});

Soft Deletes and Archiving

Laravel's soft deletes, which add a deleted_at timestamp column, are convenient for retaining records without physically removing them. However, every query will implicitly add WHERE deleted_at IS NULL, which can impact performance on very large tables if the column is not indexed or if the ratio of deleted to active records is high.

For extremely large datasets with historical data rarely accessed, consider a dedicated archiving strategy. Move old, inactive records to a separate archive table or even cold storage. This keeps your active tables smaller and faster.

Tips and Tricks

Analyze Queries with EXPLAIN: Use EXPLAIN (available in MySQL, PostgreSQL, etc.) to understand how your database executes a query. It reveals which indexes are used, table scan types, and potential bottlenecks.
Monitor Slow Query Logs: Configure your database to log slow queries. Regularly review these logs to identify specific queries that need optimization.
Test with Realistic Data Volumes: Before deploying to production, populate your development or staging environment with data volumes that mimic production. Performance characteristics change significantly with scale.
Prioritize Hot Spots: Focus optimization efforts on tables and queries that are most frequently accessed or cause the most performance issues.
Avoid SELECT *: Only retrieve the columns you genuinely need. Fetching unnecessary data increases network traffic and database processing.
Understand Database-Specific Features: Modern databases offer unique features. For example, PostgreSQL has specific index types like GIN or GIST for text search or JSON B-tree operations.

Takeaways

Start Normalized, Denormalize Judiciously: Begin with a clean, normalized schema and introduce denormalization only for specific, identified performance gains.
Index Strategically: Index foreign keys, columns in WHERE, ORDER BY, and GROUP BY clauses. Avoid over-indexing.
Choose Optimal Data Types: Use the smallest, most appropriate data types to save space and improve query speed.
Enforce Referential Integrity: Use foreign key constraints to maintain data consistency and help the query planner.
Monitor and Iterate: Database schema design is not a one-time task. Continuously monitor query performance and refine your schema as your application evolves.

Design your system to remain robust when external APIs evolve.

Usman Zahid — Sun, 07 Sep 2025 19:00:38 +0000

External APIs are fundamental to modern backend systems, allowing services to communicate and share data. However, these APIs are not static. They evolve, introduce new features, deprecate old ones, or change data structures. Designing your system to anticipate and handle these changes is critical for maintaining stability and reducing unplanned work for your team. A robust design ensures your application remains operational and predictable even when external dependencies shift.

Isolate External API Interactions

Directly calling an external API from multiple parts of your application creates tight coupling. When the API changes, you face a complex search and replace task across your codebase.

Strategy: Implement an isolation layer. Create a dedicated service or repository responsible for all communication with a specific external API. This service translates external API responses into your application's internal data models, shielding the rest of your system from external API specific details.

Example (PHP/Laravel):

// app/Services/ExternalUserService.php
class ExternalUserService
{
    private $httpClient;

    public function __construct(HttpClient $httpClient)
    {
        $this->httpClient = $httpClient; // Guzzle or similar
    }

    public function getUserData(string $userId): array
    {
        try {
            $response = $this->httpClient->get("/users/{$userId}");
            $externalData = json_decode($response->getBody()->getContents(), true);

            // Translate external API format to internal format
            return [
                'id' => $externalData['id'],
                'name' => $externalData['displayName'],
                'email' => $externalData['contactEmail'],
                // Map other relevant fields
            ];
        } catch (Exception $e) {
            // Handle API call errors
            throw new ExternalApiException("Failed to fetch user data.", 0, $e);
        }
    }
}

// In your application, you interact only with ExternalUserService
$userData = app(ExternalUserService::class)->getUserData('some_external_id');

If the external user API changes its displayName field to fullName, you only update ExternalUserService without touching any other part of your application that uses user data.

Implement Robust Error Handling and Fallbacks

External APIs can fail due to various reasons: network issues, rate limits, or internal server errors on their side. Your system must be prepared for these scenarios.

Strategy:

Catch specific exceptions: Distinguish between network errors, client errors (4xx), and server errors (5xx).
Retry mechanisms: Implement exponential backoff for transient errors, but avoid infinite retries.
Circuit breakers: Prevent your system from repeatedly calling a failing API, allowing it to recover and preventing cascading failures.
Default values or cached data: If an API call is non-critical and fails, use sensible default data or a stale cached version to maintain partial functionality.

Versioning External APIs

Many external APIs offer versioning, like /v1/users or /v2/users. This is the primary way API providers manage changes.

Strategy:

Explicitly specify versions: Always target a specific API version in your requests. Avoid letting the API default to its latest version, which could change unexpectedly.
Plan for upgrades: When a new version of an external API is released, assess the impact. If significant changes are introduced, develop a new client for that version within your isolation layer, and gradually migrate your application's usage.
Dual-client approach: During migration, your isolation layer might temporarily support both old and new API versions, allowing for a phased rollout.

Monitoring and Alerting

Detecting issues quickly is paramount for maintaining robustness.

Strategy:

Log API requests and responses: Include request details, response status codes, and execution times.
Set up alerts: Monitor API call success rates, latency, and specific error codes. Trigger alerts for prolonged periods of errors or performance degradation.
External status pages: Subscribe to status pages provided by your external API vendors to receive notifications about their outages or planned maintenance.

Automated Testing

Unit and integration tests are essential for confirming your API clients work as expected.

Strategy:

Mock external API responses: For unit tests, mock the external API service to ensure your internal logic processes different responses correctly.
Contract testing: If feasible, use contract testing (e.g., Pact) to define and verify the expected contract between your service and the external API. This can catch breaking changes early.
Integration tests: Run specific integration tests against a test or staging environment of the external API, if available. This verifies end-to-end connectivity and data mapping.

Communication and Documentation

Stay informed about upcoming changes from your external API providers.

Strategy:

Read API documentation: Regularly review the documentation for any update announcements or deprecation notices.
Subscribe to newsletters/forums: Many API providers use these channels to communicate important changes.
Establish contact: If you are a high-volume user, consider establishing a direct communication channel with the API provider's support or engineering team.

Tips and Tricks

Don't over-engineer for every possible change immediately. Focus on isolating the calls and handling common failure modes. Add complexity for specific known risks or after encountering issues.
Be explicit about data contracts. When designing your internal data models, be clear about which fields are expected from the external API and which are optional.
Consider a dedicated API gateway for complex scenarios. If you integrate with many external APIs or need to apply common policies (rate limiting, authentication, transformation), an API gateway can centralize this logic.
Avoid deep nesting in API calls. Try to make your calls as flat as possible. Complex chained calls to an external API increase the surface area for failure and make error handling harder.
Use idempotent operations where possible. For write operations, design your requests to be idempotent. This means making the same request multiple times has the same effect as making it once, which simplifies retry logic.

Takeaways

Robust integration with evolving external APIs hinges on proactive design and monitoring. Isolate external interactions behind a dedicated service, implement comprehensive error handling with retries and circuit breakers, and explicitly manage API versions. Combine these technical strategies with thorough monitoring, automated testing, and active communication with API providers to ensure your system remains stable and adaptable.

Manage your n8n workflows and API directly from PHP

Usman Zahid — Sun, 07 Sep 2025 17:07:16 +0000

Managing your n8n workflows and API directly from PHP allows developers to integrate automation into their applications more efficiently. Using a lightweight PHP SDK, you can connect to your n8n instance and start managing workflows, webhooks, variables, and more, all from PHP code. This reduces friction between your application and n8n and makes automation a first-class part of your backend.

Benefits

The SDK makes it easy to manage your n8n instance from PHP. Your application can now be aware of n8n, call it programmatically, and perform many automation tasks that were previously manual or required switching contexts. It enhances n8n workflows, increases possibilities beyond just workflows, and allows your projects to leverage automation more deeply. n8n itself is already powerful, but this SDK expands what you can do with it in a PHP environment.

Getting Started

Connecting to an n8n instance is straightforward:

use UsmanZahid\N8n\N8nClient;

N8nClient::connect(
    'https://your-n8n-instance.com',
    'your-api-key'
);

Pagination and handling large datasets are simplified and handled automatically by the SDK, so you can focus on building your automation logic without worrying about API intricacies.

What It Brings to PHP Developers

Easy connection to n8n from any PHP application
Programmatic management of workflows, users, variables, and projects
Expanded automation possibilities beyond what n8n provides out of the box
Integration into existing backend systems, Laravel apps, or DevOps pipelines

With this SDK, your PHP applications can fully interact with n8n, enabling deeper automation and smarter workflows.

Links

GitHub Repository
Packagist

Conclusion

This PHP SDK simplifies connecting to n8n, managing workflows, and extending automation possibilities directly from your PHP code. It makes n8n integration more practical and opens up new ways to enhance workflows and applications.

Understanding core cloud infrastructure concepts.

Usman Zahid — Fri, 05 Sep 2025 07:25:02 +0000

Hey there, ever felt like cloud computing is this big, mystical beast full of complex terms? You are not alone. I remember when we first started migrating some of our core Laravel applications to AWS, it felt like learning a whole new language just to get a server up and running. But trust me, once you grasp a few fundamental concepts, it clicks. It is not magic, it is just well-organized infrastructure, and understanding these basics really makes you a more capable, confident engineer. It helps you design better systems, troubleshoot faster, and even talk to your DevOps team without that blank stare.

Think of it like building a house. You do not need to be an architect, but knowing what a foundation is, how walls work, and what a roof does helps you understand why your house stands up, or why it might leak. The cloud is similar, a digital house for your applications.

What is the Cloud, Really?

At its heart, the cloud is just a fancy way of saying "someone else's computer" or, more accurately, "someone else's massive data center full of computers." Instead of buying and maintaining physical hardware yourself, you rent access to their resources over the internet. This rental model gives you incredible flexibility and scalability, but you still need to know how to use those rented tools effectively.

Your Core Cloud Building Blocks

Let us break down the main parts you will likely encounter.

1. Compute Power: Your Digital Engines

This is where your code actually runs.

Virtual Machines (VMs) or Instances: Imagine a server. Now, imagine a software version of that server. That is a VM. You choose its size, operating system, and then deploy your applications onto it. For a Laravel application, this might be an EC2 instance on AWS or a Virtual Machine on Azure. You install PHP, Nginx, Composer, and your code, just like a physical server.
Containers: Think of containers, like Docker, as a much lighter, self-contained package for your application and everything it needs to run. They share the operating system of the host, making them faster to start and more efficient. Services like AWS ECS or Kubernetes manage these containers at scale. When a junior developer asked me once, "Why Docker?", I simply said, "It means your app runs the same on my laptop, on the test server, and in production, no 'but it worked on my machine' excuses."

2. Storage: Where Your Stuff Lives

Your application needs places to keep data.

Databases (Managed): You need a database for your Laravel app, right? Instead of setting up and maintaining MySQL or PostgreSQL yourself on a VM, cloud providers offer managed database services, like Amazon RDS or Azure SQL Database. They handle backups, scaling, and patching. This is a huge time saver. I once spent a whole weekend debugging a self-hosted database replication issue. Never again, I swore. Managed databases simplify your life.
Object Storage: This is for big files, like user uploads, images, videos, or backups. Services like Amazon S3 are perfect for this. They are extremely durable, scalable, and cheap. You would not store these on your web server directly, because those servers are meant to be temporary and stateless.

3. Networking: Connecting the Dots

How do your different cloud components talk to each other, and how do users access your app?

Virtual Private Cloud (VPC): This is your own private, isolated network area within the cloud. You define its boundaries, IP ranges, and rules. It is like having your own dedicated office building within a huge corporate campus.
Subnets: Within your VPC, you create subnets. These are smaller segments of your network, often used to separate public-facing resources (like web servers) from private resources (like databases).
Security Groups: These act as virtual firewalls for your instances. You define rules that control inbound and outbound traffic. For example, you might allow HTTP and HTTPS traffic to your web servers, but only allow your web servers to connect to your database. This is a crucial security layer, a mistake here can leave your services wide open.

4. Identity and Access Management (IAM): Who Gets the Keys?

This system controls who can do what within your cloud account.

Users and Roles: You create users for individual people and roles for applications or services. Each user or role is granted specific permissions. For example, a developer might have permissions to deploy code but not to delete core infrastructure.
Policies: These are documents that define what actions a user or role can perform on what resources. The "principle of least privilege" is key here, only give the minimum necessary permissions. I remember a time when a new intern was given admin access "just to make things easy." It was not easy when they accidentally deleted a critical S3 bucket. Lesson learned, always use least privilege.

5. Scaling: Growing with Demand

The cloud's superpower is its ability to grow or shrink based on demand.

Load Balancers: If you have multiple web servers, a load balancer distributes incoming traffic evenly across them. If one server goes down, it stops sending traffic to it. It is like a traffic cop directing cars efficiently.
Auto-Scaling Groups: These automatically add or remove compute instances based on metrics like CPU usage or network traffic. If your Laravel app suddenly gets a huge surge of users, an auto-scaling group can automatically launch more web servers to handle the load, and then shut them down when traffic drops, saving you money.

Tips and Tricks from the Trenches

Start Small, Learn by Doing: Do not try to build a massive, complex architecture on day one. Start with a single VM, deploy a simple Laravel app, and then gradually add a managed database, object storage, and basic networking.
Cost Management is Crucial: Cloud costs can sneak up on you. Always keep an eye on your billing dashboard and set up cost alerts. A runaway instance can be a painful surprise at the end of the month.
Security First, Always: Cloud security is a shared responsibility. While the provider secures the underlying infrastructure, you are responsible for securing your applications, data, and configurations. Think carefully about those security group rules and IAM policies.
Automation is Your Best Friend: Manual tasks are boring and error-prone. Learn tools like Terraform or CloudFormation to define your infrastructure as code. This makes your deployments consistent and repeatable.
Know Your Provider's Lingo: Each cloud provider, AWS, Azure, GCP, has its own names for similar services. Spend some time understanding their specific terms.

Takeaways

Understanding these core cloud concepts is not just theoretical knowledge, it is practical power. It lets you confidently design, deploy, and manage your applications in a scalable, secure, and cost-effective way. You will find yourself debugging issues faster, making better architectural decisions, and generally feeling much more in control of your digital kingdom. So, roll up your sleeves, pick a cloud provider, and start tinkering. There is no better teacher than hands-on experience, and you will be amazed at how quickly you go from confused to confident.

Breaking Down the Hate for PHP

Usman Zahid — Tue, 02 Sep 2025 12:23:44 +0000

PHP has long been a polarizing language in web development. For decades, it has faced criticism from developers for various reasons, many of which are well-documented in discussions and articles online. Some of the main points of frustration historically include:

Inconsistent language design: PHP evolved rapidly and organically, leading to functions with inconsistent naming conventions, parameter orders, and behavior. This made learning and maintaining code challenging.
Security concerns: Older PHP codebases often suffered from vulnerabilities like SQL injection, XSS, and CSRF, largely due to improper defaults and the prevalence of copy-pasted examples online.
Legacy code and technical debt: Because PHP has been around for so long, many projects are burdened by years of spaghetti code, making them difficult to refactor or modernize.
Overexposure of “bad examples”: Many public tutorials and early projects promoted poor coding practices, creating a reputation that PHP is inherently messy or unsafe.

These criticisms are valid in the historical context. PHP’s early days were chaotic, and many developers were frustrated by the need to manage too much low-level boilerplate code. It often felt like developers were fighting the language as much as they were writing applications.

However, the story of PHP today is very different. Modern PHP frameworks like Laravel, Symfony, and CakePHP provide structure, enforce best practices, and reduce boilerplate, making it easier to write clean, maintainable, and secure code. Features like type declarations, namespaces, improved error handling, and Composer-based package management have brought PHP closer to modern development standards.

The persistence of PHP in powering millions of websites—including some of the world’s largest platforms—shows that despite its reputation, it remains a practical and effective tool when used with modern conventions. What used to be a chaotic ecosystem of scripts and ad-hoc coding has evolved into a robust environment with frameworks, dependency management, testing tools, and a large, supportive community.

In short, the hate for PHP is often rooted in its past, not its present. While older projects may still suffer from bad design or outdated practices, new PHP systems are increasingly structured, maintainable, and secure. Understanding this evolution helps contextualize both the criticism and the ongoing value of PHP in modern web development.

Must read articles about this for further information:

— Usman Zahid

Service Responses | From Chaos to Clean APIs

Usman Zahid — Tue, 02 Sep 2025 12:15:59 +0000

I used to build backend services the “quick way.” Every function returned something different: sometimes arrays, sometimes strings, sometimes just a boolean. Clients never knew what to expect. Debugging? Nightmare. Error handling? Confusing.

Then I realized I needed structure. That’s when I built a ServiceResponse class. Now, every response is predictable, consistent, and fully traceable.

Here’s what it looks like:

<?php

namespace Usmanzahid\ServiceResponse;

class ServiceResponse {
    private ?string $message = null;
    private bool $success = true;
    private mixed $data = null;
    private array $errors = [];
    private ?self $previous = null;

    public function withMessage(string $message): self {
        $this->message = $message;
        return $this;
    }

    public function withSuccess(bool $success): self {
        $this->success = $success;
        return $this;
    }

    public function withError(string $key, string $message): self {
        $this->errors[$key][] = $message;
        return $this;
    }

    public function withErrors(array $errors): self {
        foreach ($errors as $key => $messages) {
            foreach ((array) $messages as $message) {
                $this->withError($key, $message);
            }
        }
        return $this;
    }

    public function withData(mixed $data): self {
        $this->data = $data;
        return $this;
    }

    public function withPrevious(self $previous): self {
        $this->previous = $previous;
        return $this;
    }

    public function getMessage(): ?string {
        return $this->message;
    }

    public function wasSuccessful(): bool {
        return $this->success===true;
    }

    public function wasNotSuccessful(): bool {
        return !$this->wasSuccessful();
    }

    public function getErrors(): array {
        return $this->errors;
    }

    public function getAllErrors(): array {
        $all = $this->errors;
        $prev = $this->previous;
        while ($prev) {
            $all = array_merge_recursive($prev->getErrors(), $all);
            $prev = $prev->previous;
        }
        return $all;
    }

    public function getData(): mixed {
        return $this->data;
    }

    public function getRootCause(): self {
        $origin = $this;
        while ($origin->previous!==null) {
            $origin = $origin->previous;
        }
        return $origin;
    }

    public function toArray(): array {
        return [
            'success' => $this->wasSuccessful(),
            'message' => $this->message,
            'data' => $this->data,
            'errors' => $this->getAllErrors(),
        ];
    }
}

Why It Changed Everything

1. Consistency

Every response now has the same shape: success, message, data, errors. No surprises.

2. Chained Methods

Build responses step by step with fluent syntax. For example:

return (new ServiceResponse())
    ->withSuccess(false)
    ->withMessage('Something went wrong')
    ->withError('email', 'Invalid email address');

3. Error Aggregation

Multiple errors? Nested errors? Fully traceable. I finally know why something failed, not just that it did.

4. Flexible Data

Any payload can be returned—strings, objects, arrays—while keeping the response structure intact.

5. Root Cause Tracking

If an error bubbles up through multiple layers, the original source is always available. Debugging becomes easier, and logs actually make sense.

The Takeaway

What started as a small class to standardize API responses turned into a tool that made my backend predictable, debuggable, and professional. No more random return types. No more guessing. Now every request and response has full context, and handling errors feels natural.

— Usman Zahid

You don’t need dual boot anymore; Windows can do Linux now.

Usman Zahid — Tue, 02 Sep 2025 12:06:05 +0000

No, I’m not talking about virtual machines.

A little story: I used to keep a dual-boot setup, Windows for comfort and gaming, Linux for stability and backend development. Juggling the two was a pain: rebooting every time, managing file systems, and keeping environments in sync.

Then I discovered Windows Subsystem for Linux (WSL). With WSL, Windows can run a full Linux environment natively. That means you get the stability and tooling of Linux without leaving Windows.

How It Works

Enable WSL: On Windows 10 or 11, you can enable WSL from PowerShell:

   wsl --install

This installs the default Linux distribution (Ubuntu) automatically.

Choose Your Distribution: You can pick Ubuntu, Debian, Fedora, or others from the Microsoft Store.
Run Linux Natively: Open a terminal and you’re in a Linux shell. You can:
- Run Bash scripts
- Install packages with apt or yum
- Start servers and backend services
- Access your Windows files seamlessly
- Integration: Linux commands and tools can work alongside Windows apps. Use VS Code, Docker, or databases from either environment.

Why It’s Great

Linux stability: Manage servers, scripts, and development tools reliably.
Windows familiarity: Continue using your favorite apps and workflows.
No reboot needed: Switch seamlessly between environments.

For backend developers, WSL is a game-changer. You can build, test, and deploy in Linux while staying in the comfort of Windows. Dual boot is no longer necessary.

— Usman Zahid

Will your system break after 2038?

Usman Zahid — Tue, 02 Sep 2025 11:54:35 +0000

If your software uses timestamps, you need to know about the Year 2038 problem.

On 19 January 2038 at 03:14:07 UTC, many systems will hit a hard limit. Why?

Most Unix-like systems store time as the number of seconds since 1 January 1970 (the Unix epoch), using a signed 32-bit integer. The maximum value that fits in that space is 2,147,483,647. One second later, it overflows into a negative number and time resets to 13 December 1901.

In short, your system may think it has traveled back in time.

Where this matters:

Databases storing timestamps in 32-bit fields
Embedded systems and legacy devices
Old operating systems or runtimes that still rely on 32-bit time representations

How to prepare:

Use 64-bit time representations (time_t on modern systems)
Update legacy databases to store timestamps in larger integer or datetime types
Audit your code and dependencies for time functions
Test your applications with future dates to see how they behave

Takeaway

The Year 2038 bug isn’t science fiction, it’s a real limitation baked into older systems.

If you’re still storing timestamps in 32-bit integers, the clock is ticking.

— Usman Zahid

Why Financial Calculations Go Wrong, and How to Get Them Right

Usman Zahid — Tue, 06 May 2025 18:13:59 +0000

When building systems that handle money, there’s no room for approximation. A minor rounding error or a misplaced use of floating-point arithmetic can lead to inconsistencies, broken user trust, or even financial loss. Despite the importance, many systems today still rely on flawed approaches, usually stemming from a lack of clarity around how decimal precision, rounding, and accumulation behave in real-world software environments.

In this article, we’ll discuss the common problems in financial calculations, walk through best practices for dealing with them, and introduce a pragmatic solution that simplifies implementation without compromising on correctness.

The Real-World Challenges of Financial Computation

1. Precision Loss Due to Floating-Point Arithmetic

Languages like PHP provide floats and doubles for numerical operations, but these are binary representations that can’t accurately express decimal fractions like 0.1, 0.015, or 0.005. These imprecisions surface as rounding bugs, broken assertions, or mismatched totals.

Example:

var_dump(0.1 + 0.2); // float(0.30000000000000004)

This might seem harmless in isolation, but it becomes critical in systems handling totals, invoices, or taxes.

2. Rounding at the Wrong Place in the Pipeline

It’s common to see developers rounding values too early, or multiple times across a transaction. Rounding during intermediate steps introduces a cumulative error that compounds as calculations grow in scale.

A classic case:

0.015 + 0.015 = 0.030 (correct)

Rounded early:
0.015 → 0.02
0.015 → 0.02
0.02 + 0.02 = 0.04 // Incorrect sum

Rounded late:
0.015 + 0.015 = 0.030 

0.015 → 0.02
0.015 → 0.02
0.02 + 0.02 = 0.03 // Does not make sense

To the system, the math is valid. To the user, it's a mismatch.

3. Accumulation of Rounding Errors Over Multiple Records

In bulk operations, like invoice line-items, financial reports, or payouts, subtle discrepancies add up. If rounding isn't consistent and deterministic, discrepancies between the sum of parts and the total are inevitable.

Engineering Principles to Avoid These Issues

Use strings, not floats.

All monetary values should be stored and manipulated as strings. This allows for exact decimal representation and prevents hidden float errors.

Delay rounding until the final step.

Never round during intermediate calculations. Perform all operations with full precision, and apply rounding only at the point of display or storage, based on system-defined rules.

Define precision constraints per currency.

Hard-code expected precision per currency. For USD, enforce two decimal places. For cryptocurrencies or niche systems, precision may vary. The point is to keep it consistent and system-wide, not decided at the time of calculation.

Avoid implicit business logic.

The core of your system should be predictable. If rounding behavior, tax models, or precision rules are not consistent across the board, no amount of tooling will fix the results.

Available Solutions

BCMath (Manual Control)
Using PHP’s BCMath extension, you can write precision-safe operations. But it’s verbose and low-level, you must manually handle rounding, scaling, and precision on every step.
usmanzahid/money-utils (Utility-Focused Abstraction)
This is a minimalist utility package built on top of BCMath. It simplifies financial calculations by enforcing best practices out of the box, letting you write correct, precise, and reliable financial logic without worrying about the underlying implementation details.

Why Use `usmanzahid/money-utils`

Define precision once using uz_set_precision(), and the system ensures consistency across all operations.
Perform addition, subtraction, multiplication, and division with predictable, correct results.
Handle tax, discounts, and percentage operations with clean and readable function calls.
No need to manually round, library handles rounding based on your defined precision, only when necessary.
Ensures results are correct for both calculation and display, regardless of how complex your logic becomes.

Example Usage

require 'vendor/autoload.php';

use function Usmanzahid\MoneyUtils\{
    uz_set_precision,
    uz_add,
    uz_percent_of,
    uz_tax,
    uz_discount,
    uz_split
};

uz_set_precision(2);

uz_add('10.12', '2.34');                  // "12.46"
uz_percent_of('200', '10');               // "20.00"

uz_tax('100.00', 'percentage', '10%');    
// ['amount' => '100.00', 'tax' => '10.00', 'after_tax' => '110.00']

uz_discount('100.00', 'fixed', '7.00');   
// ['amount' => '100.00', 'discount' => '7.00', 'after_discount' => '93.00']

uz_split('10.00', 3);                     
// ["3.34", "3.33", "3.33"]

All operations respect your defined precision, apply correct rounding rules, and reduce the risk of downstream discrepancies.

Instllation
Check out the package at: https://packagist.org/packages/usmanzahid/money-utils

composer require usmanzahid/money-utils

Final Thoughts

Money is not like other data. A mismatch of a cent or two is often enough to break user trust or raise compliance issues. Building financial software requires precision, consistency, and engineering discipline. The tools you choose must support those goals, not make them harder to reach.

usmanzahid/money-utils is designed for developers who want precise and maintainable financial logic without reinventing the wheel. It simplifies implementation while enforcing correctness, and it’s suited for real-world systems that can't afford to be imprecise.

For systems requiring more advanced features like multi-currency modeling or object-based monetary abstractions, the Money pattern (as described by Martin Fowler) is a common approach. Libraries like brick/money implement that pattern. However, in many practical cases, especially when working within a single currency or needing minimal configuration, such solutions may introduce unnecessary complexity.

If your priority is clean, predictable, and easy-to-maintain financial logic in PHP, money-utils provides a balanced and efficient path forward.

Creating Custom Classes in Laravel Without Custom Commands

Usman Zahid — Sun, 27 Apr 2025 13:15:46 +0000

As a Laravel developer, I often encounter repetitive tasks that slow down development and add unnecessary complexity. One such challenge is creating custom class types, such as Services, Repositories, or Data Transfer Objects (DTOs).

While Laravel’s Artisan commands are excellent for generating standard components like models or controllers, they don’t natively support custom class types. This leads to a common problem: manually creating Artisan commands for each class type, which is time, consuming and difficult to maintain.

In this post, I’ll share my experience with this issue and introduce a practical solution, the usmanzahid/laravel-custom-make package, that streamlines the process with minimal configuration.

The Challenge: Managing Custom Artisan Commands

In many Laravel projects, I need to create custom classes to keep my code organized and maintainable. For example, I might use a Service class for business logic, a Repository for data access, or a DTO for structured data transfer. Without built-in Artisan commands for these, I initially resorted to creating custom commands, such as make:service or make:repository.

While this approach worked, it was far from ideal. Each command required its own class and a stub file for the template. For a single class type, this might take an hour to set up.

As the project grew, I found myself maintaining multiple commands, each with its own logic and stub files. Updating a stub meant editing the corresponding command’s code, and debugging issues across several commands became a hassle.

This repetitive boilerplate felt inefficient and distracted me from focusing on the actual application logic.

I needed a solution that would allow me to define custom class types quickly, without the overhead of creating and managing individual Artisan commands. That’s when I created the usmanzahid/laravel-custom-make package, which elegantly solves this problem.

The laravel-custom-make package provides a lightweight and efficient way to generate custom class types in Laravel. Instead of writing a new Artisan command for each class type, you can define your custom types in a single configuration file, specify their output paths and stub templates, and let the package handle the rest. With just two lines of configuration per class type, you can create a new generator, making it a seamless addition to Laravel’s ecosystem.

This package is particularly valuable because it eliminates the need for repetitive command creation while maintaining flexibility. It’s compatible with Laravel 10, 11, or 12 and requires PHP 8.0 or higher, ensuring broad applicability.

Usage Guide: Setting Up laravel-custom-make

Below, I’ll walk through the steps to install and configure the package, demonstrating how to create custom class types efficiently.

Step 1: Install the Package

Begin by installing the package via Composer:

composer require usmanzahid/laravel-custom-make

This command adds the package to your Laravel project, along with its dependencies.

Step 2: Publish Configuration and Stubs

Next, publish the package’s configuration file and stub templates:

php artisan vendor:publish --provider="Usmanzahid\LaravelCustomMake\LaravelCustomMakeProvider"

php artisan vendor:publish --tag=config
php artisan vendor:publish --tag=stubs

This creates a config/laravel_custom_maker.php file and a stubs/ directory in your project’s root. The configuration file defines your custom class types, while the stubs directory contains the templates for generated classes.

Step 3: Configure Custom Class Types

Open the config/laravel_custom_maker.php file. Here, you’ll define each custom class type by specifying its output path and stub file. For example, to configure Service and DTO class types:

return [
    'service' => [
        'path' => app_path('Services'),
        'stub' => base_path('stubs/service.stub'),
    ],
    'dto' => [
        'path' => app_path('DTOs'),
        'stub' => base_path('stubs/dto.stub'),
    ],
];

Each class type requires only two settings: path (where the generated file will be saved) and stub (the template file to use). This simplicity makes it easy to add new class types as needed.

Step 4: Create Stub Templates

Navigate to the stubs/ directory, where you can create or modify stub files. For a Service class, create a service.stub:

<?php

namespace App\Services;

class {{ class }}
{
    public function __construct()
    {
        // Initialize service
    }

    // Define service methods
}

For a DTO class, create a dto.stub:

<?php

namespace App\DTOs;

class {{ class }}
{
    // Define DTO properties
}

The {{ class }} placeholder is automatically replaced with the class name provided during generation. Additional placeholders, such as {{ namespace }}, can be used for more complex templates.

Step 5: Generate Custom Classes

With the configuration and stubs in place, you can generate classes using the make:custom Artisan command. For example, to create an AuthService class:

php artisan make:custom service AuthService

This generates app/Services/AuthService.php based on the service.stub:

<?php

namespace App\Services;

class AuthService
{
    public function __construct()
    {
        // Initialize service
    }

    // Define service methods
}

Similarly, to create a UserDTO:

php artisan make:custom dto UserDTO

This produces app/DTOs/UserDTO.php:

<?php

namespace App\DTOs;

class UserDTO
{
    // Define DTO properties
}

The process is straightforward and eliminates the need for custom command classes.

Step 6: Extend and Customize

To add a new class type, such as a Repository, update the configuration:

'repository' => [
    'path' => app_path('Repositories'),
    'stub' => base_path('stubs/repository.stub'),
],

Create a repository.stub, and you can generate Repository classes using the same make:custom command. The package supports unlimited class types, and stubs can be customized with additional placeholders or logic as needed.

Benefits of laravel-custom-make

The laravel-custom-make package addresses the pain points of custom class generation by offering:

Efficiency: Define new class types with minimal configuration, avoiding the need for custom Artisan commands.
Flexibility: Customize stub templates to match your project’s conventions.
Maintainability: Centralize class type definitions in a single configuration file, simplifying updates.

Seamless Integration: Works naturally within Laravel’s Artisan ecosystem.

This package has significantly reduced the time I spend on boilerplate code, allowing me to focus on developing core application features.

Conclusion

For Laravel developers seeking a streamlined approach to generating custom class types, the usmanzahid/laravel-custom-make package is an invaluable tool. By replacing repetitive command creation with a simple configuration-based system, it saves time and reduces maintenance overhead. I encourage you to explore the package, experiment with custom stubs, and integrate it into your workflow.

You can find more details and contribute to the package on GitHub or install it via Packagist. If you have questions or insights about custom class generation in Laravel, feel free to share them in the comments—I’d love to hear your thoughts.

Thank you for reading, and happy coding!

Forem: Usman Zahid

Architecting for system reliability and scalability demands clean foundational code.

Introduction

The Core of Clean Foundational Code

Defining Clean Code for Reliability and Scalability

Modularity and Clear Interfaces

Predictable Data Flow and State Management

Robust Error Handling and System Resilience

Performance Considerations from the Outset

The Role of Automated Testing

Tips and Tricks

Takeaways

Implement effective API versioning strategies for your evolving services.

API Versioning Strategies

1. URI Path Versioning

2. Query Parameter Versioning

3. Custom Header Versioning

4. Content Negotiation Versioning (Accept Header)

When to Version Your API

API Lifecycle and Deprecation

Tips and Tricks

Takeaways

Design your Laravel database schema for optimal query performance.

Normalization and Denormalization

Indexing Strategies

Choosing Appropriate Data Types

Relationships and Foreign Keys

Soft Deletes and Archiving

Tips and Tricks

Takeaways

Design your system to remain robust when external APIs evolve.

Isolate External API Interactions

Implement Robust Error Handling and Fallbacks

Versioning External APIs

Monitoring and Alerting

Automated Testing

Communication and Documentation

Tips and Tricks

Takeaways

Manage your n8n workflows and API directly from PHP

Benefits

Getting Started

Links

Understanding core cloud infrastructure concepts.

What is the Cloud, Really?

Your Core Cloud Building Blocks

1. Compute Power: Your Digital Engines

2. Storage: Where Your Stuff Lives

3. Networking: Connecting the Dots

4. Identity and Access Management (IAM): Who Gets the Keys?

5. Scaling: Growing with Demand

Tips and Tricks from the Trenches

Takeaways

Breaking Down the Hate for PHP

Service Responses | From Chaos to Clean APIs

Why It Changed Everything

The Takeaway

You don’t need dual boot anymore; Windows can do Linux now.

How It Works

Why It’s Great

Will your system break after 2038?

Where this matters:

How to prepare:

Takeaway

Why Financial Calculations Go Wrong, and How to Get Them Right

The Real-World Challenges of Financial Computation

1. Precision Loss Due to Floating-Point Arithmetic

2. Rounding at the Wrong Place in the Pipeline

3. Accumulation of Rounding Errors Over Multiple Records

Engineering Principles to Avoid These Issues

Use strings, not floats.

Delay rounding until the final step.

Define precision constraints per currency.

Avoid implicit business logic.

Available Solutions

Why Use usmanzahid/money-utils

Example Usage

Final Thoughts

Creating Custom Classes in Laravel Without Custom Commands

The Challenge: Managing Custom Artisan Commands

Why Use `usmanzahid/money-utils`