Forem: Adebowale Bello

Building APIs with a Zero Trust Policy: Protecting Your Data Like Your Peace

Adebowale Bello — Fri, 31 Oct 2025 14:20:59 +0000

If you have ever been hurt by someone you trusted completely, you already understand the essence of Zero Trust Policy, you just didn’t know it had a name or is relatable in Api Architecting.

In life, we learn (sometimes the hard way) that trust is something you verify, not something you give blindly. You don’t expect everyone to always do right by you. People have different upbringing, grew up in different environments, have had different experiences and most naturally do things that make life convenient for themselves.

So, what do you do?
You start setting boundaries. You keep your guard up. You make sure no one can hurt you, not because you don’t trust people, but because you trust that anyone is capable of breaking your trust if it benefits them.

That is exactly how I approach API development.

When I build APIs, I build them with a Zero Trust policy not because I am paranoid, but because I have seen what happens when assumptions go unchecked. This mindset has saved me countless hours debugging mysterious data inconsistencies and unexpected system failures.

What Is Zero Trust, Really?

In traditional systems, developers often assume that once a request comes from within the network, it’s safe.
“Oh, it is from another internal service, let it pass.”
That is the same as saying, “They are my friend, they would never do me wrong.”

And then you wake up one morning to realize that someone inside the circle left the door wide open.

Zero Trust flips that assumption on its head. It means:

“Never trust. Always verify.”

Every request, whether it is coming from your frontend app, a third-party integration, or another internal microservice must prove itself worthy of access. Every bit of data must be verified before it is accepted. Every operation must respect strict permissions.

In short, Zero Trust is about respecting boundaries, both in life and in code.

How Zero Trust Shapes API Development

When you apply Zero Trust principles to API design, you’re saying:

I don’t care who you are, show your credentials.
I don’t care where you are calling from, prove your permission.
I don’t care if it “worked yesterday”, validate your data again.

It is not cynicism. It’s discipline.
And this discipline leads to more secure and more consistent systems.

Let’s break it down.

1. Authentication at Every Door

Think of authentication as checking who is knocking.
You would not let someone into your house just because they say, “I live next door.” You would still look through the peephole, right?

APIs should do the same.
Every request, even internal ones must carry valid credentials.
That means:

Using OAuth2, JWTs, or signed API keys.
Verifying tokens for each call, not just trusting the previous one.
Avoiding network-based trust like IP whitelisting. It is the digital version of leaving your spare key under the mat.

In a Zero Trust world, no endpoint is “safe” by default.

2. Authorization: Just Because You are In Does not Mean You Can Do Everything

Imagine giving someone your house key to watch a football game, and then coming home to find they rearranged your furniture.
They were authorized to enter, but not to redesign your life.

That is why authorization matters.

After verifying who someone is, your API must check what they are allowed to do.
Every endpoint should enforce permissions tightly and deliberately.

A viewer role shouldn’t be able to update records.
A report:read scope shouldn’t allow report deletion.
Internal services should use role-based access just like users.

This is what Zero Trust looks like in practice: granular control. Nobody gets blanket permission.

3. Input Validation: Don't Let Dirty Data in Your House

One of the easiest ways to lose control of your system is to trust incoming data.
Zero Trust means every input, even from “trusted” services is a suspect until proven clean.

That means:

Validating payloads against a schema or DTO.
Rejecting malformed requests instead of “fixing” them silently.
Sanitizing strings to prevent injections.

In real life, this is like checking every gift before opening it. This is not because you expect danger, but because you have seen what happens when you don’t.

And here is the benefit: by treating every input with suspicion, you protect your data consistency. Invalid data never enters your database, which means fewer weird bugs and cleaner analytics downstream.

4. Data Verification Between Services

Microservices are like roommates sharing the same fridge.
You can not assume everyone will label their food properly or clean up after themselves.
So, you start setting rules: “Label everything, or it gets thrown out.”

In a distributed system, the same logic applies.
Just because Service A says “this record is valid” doesn’t mean Service B should skip its own checks.
Every boundary between APIs, between queues, between databases must have its own validation gate.

Zero Trust across services prevents small inconsistencies from spreading into large-scale data corruption.

5. Observability: Trust, but Verify and Log Everything

A Zero Trust system should always be able to answer:

Who called this endpoint?
What data did they send?
Was it valid?
What changed as a result?

Comprehensive logging and tracing are the backbone of verification. They make your APIs auditable and help track data lineage which is a key part of maintaining consistency over time.

When something goes wrong (and it will), you won’t have to guess. You’ll have evidence.

Why Zero Trust Leads to Data Consistency

When you stop making assumptions, your data stops lying to you.

Here is how Zero Trust drives consistency:

Every validation step ensures data correctness.
Every authorization check ensures intentionality.
Every log ensures traceability.
Every boundary enforces accountability.

Instead of building brittle systems that rely on “good behaviour,” you build resilient ones that rely on good rules.

Zero Trust turns your API ecosystem into a well-guarded house, every door locked, every guest accounted for, and every rule enforced.

Final Thoughts: Trust Rules, Not People

Building APIs with Zero Trust isn’t about being skeptical, it’s about being smart.
It’s the digital version of emotional boundaries: you don’t assume everyone will do the right thing, you make sure they can’t do the wrong thing unnoticed.

When every request is verified, every piece of data validated, and every service held accountable, your system becomes both secure and consistent not by luck, but by design.

And just like in life, when you protect your peace (or your data) through boundaries, you create an environment that is safer, cleaner, and much easier to live and build in.

API Access Control in Action: How I Protected My Team’s APIs from Unauthorized Access

Adebowale Bello — Tue, 16 Sep 2025 02:43:23 +0000

In every software project, there are moments where technical expertise is tested not by code complexity, but by human behaviour. On one of my projects, I faced such a moment when a mobile developer on the team went rogue.

He became unprofessional, violated trust, and refused to respect NDA terms or return the mobile app code that consumed our APIs. The bigger risk was not the code itself, but the fact that he still had an active client wired directly to our backend APIs. If left unchecked, he could continue consuming and potentially misusing our services indefinitely.

The team needed a solution, and I was asked to take control of the situation.

My Approach

I decided the best way to handle this was professionally and technically, without confrontation. Instead of chasing the developer, I focused on what I could control: the APIs.

The answer lay in implementing API Access Control, combining two mechanisms:

A kill switch to disable APIs entirely when needed.
Key-based restrictions to ensure only authorized clients could access endpoints.

This gave us immediate leverage and allowed us to continue operating without disruption.

The Middleware I Wrote

I created a custom Laravel middleware called DisableApiAccess that enforced these controls.

1. API Kill Switch

$apiAccess = filter_var(env('API_ACCESS', true), FILTER_VALIDATE_BOOLEAN);

if ($apiAccess === false) {
    if ($request->expectsJson() || $request->is('api/*')) {
        return apiresponser(503, 'API access is temporarily disabled.', null);
    }
    abort(503, 'Service unavailable.');
}

By flipping a single environment variable (API_ACCESS=false), I could immediately shut down all API endpoints with an HTTP 503 response. This was my emergency brake, no redeployments, no code edits, just an instant cut-off.

2. API Key Enforcement

$expectedKey = env('API_ACCESS_KEY');

if (!empty($expectedKey) && ($request->expectsJson() || $request->is('api/*'))) {
    $provided = $request->header('X-API-ACCESS-KEY') ?? $request->header('Api-Access-Key');

    if (empty($provided)) {
        return apiresponser(401, 'API access key missing.', null);
    }

    if (!hash_equals((string) $expectedKey, (string) $provided)) {
        return apiresponser(401, 'Invalid API access key.', null);
    }
}

With an API_ACCESS_KEY configured, every request now required the correct header (X-API-ACCESS-KEY or Api-Access-Key).

Missing header → 401 Unauthorized.
Wrong key → 401 Unauthorized.
Correct key → proceed as normal.

I also used hash_equals() for constant-time comparison to prevent timing attacks.

3. Normal Flow

return $next($request);

If the request passed both checks, it continued safely to the controller. If not, it was blocked at the middleware layer, long before touching business logic or the database.

The Flow Diagram

Here is how the request flow looked after I put the middleware in place:

 ┌─────────────────────────┐
 │  Incoming API Request   │
 └─────────────┬───────────┘
               │
               ▼
     ┌──────────────────┐
     │  Middleware:     │
     │ DisableApiAccess │
     └─────────┬────────┘
               │
     Is API_ACCESS=false?
          │        │
        YES        NO
        │          │
        ▼          ▼
 ┌────────────┐   Check if API_ACCESS_KEY is set
 │ Return 503 │          │
 │ Service     │          │
 │ Unavailable │          ▼
 └────────────┘   Key Required?
                      │
                ┌─────┴─────┐
                │           │
             NO │           │ YES
                │           ▼
                ▼     Validate Header
         Allow Request   │
                         ▼
             ┌─────────────────────┐
             │ Valid Key?          │
             └─────┬───────────────┘
                   │
            ┌──────┴───────┐
            │              │
          YES              NO
            │              │
            ▼              ▼
  ┌────────────────┐   ┌──────────────┐
  │ Proceed to     │   │ Return 401   │
  │ Controller     │   │ Unauthorized │
  └────────────────┘   └──────────────┘

The Result

By putting this in place, I was able to:

Revoke access immediately for the rogue developer, without touching his app or escalating the conflict.
Secure the backend APIs so that only trusted clients with the right key could access them.
Give the team confidence that we were still in control of the system, regardless of what happened with the mobile code.

The developer still had his app, but without valid API access, it was useless.

Why This Was Important

What I implemented aligned with industry best practices:

🔒 Zero Trust Principles – Never assume a client is trustworthy just because it was once authorized.
⚡ Operational Control – The kill switch provided instant response capability in case of emergencies.
🛡️ Defense in Depth – Unauthorized requests were stopped at the middleware layer, before causing harm.
📈 Professional Conflict Resolution – I avoided unnecessary escalation, kept the team’s integrity intact, and let the system enforce the rules.

Lessons Learned

APIs must be treated as critical assets. Anyone with client access can become a risk.
Revocation paths are non-negotiable. It is not enough to grant access; you must always have a way to revoke it.
Leadership often means quiet technical decisions. Instead of drama, I solved the issue with clean code and precise safeguards.

Final Thoughts

In the end, I did not just block a rogue developer, I safeguarded the project and gave my team a way forward.

This experience reinforced something I now apply in every system I design: control must be baked into the architecture, not assumed through trust.

When asked to protect the team and the project, I did it not with confrontation, but with a simple, robust solution: API Access Control.

But this is just one approach. If you were in my shoes, what other strategies would you have considered to keep the APIs safe without escalating the conflict? I would love to hear your thoughts. Please share them in the comments so we can learn from each other’s perspectives.

From Intern to Technical Lead: Navigating the Steep Climb

Adebowale Bello — Tue, 11 Mar 2025 11:06:14 +0000

The journey from an intern to a technical team lead is anything but linear. It is a steep, demanding climb filled with sharp learning curves, moments of doubt, and the relentless pulse of professional expectations. My transition, which began with an eagerness to learn, evolved into a role where I became the go-to person for answers, the face of accountability, and the bridge between stakeholders and cross-functional teams. However, this journey would not have been possible without the incredible support of my team and the growth-driven culture of my company.

The Steep Learning Curve

As an intern, my primary focus was absorbing knowledge, understanding codebases, debugging issues, and taking on small tasks to prove my competence. Every line of code was an opportunity to learn, and every mistake was a stepping stone toward growth. But the learning curve only grew steeper as I took on more responsibility. It was no longer just about writing functional code; it was about writing scalable, maintainable, and efficient solutions that aligned with business goals.

The Pulse: Keeping Up with the Pace

The transition to leadership wasn’t simply about mastering technical concepts. It required understanding the pulse of the team, the product, and the company. Deadlines became more than just dates; they were commitments I had to ensure were met. Every decision carried weight, impacting performance, user experience, and business outcomes. The pace was relentless, but adapting quickly became second nature.

The Strength of a Great Team

No leader thrives alone. I have been fortunate to work alongside a talented, dedicated team that makes the challenges of leadership easier to navigate. Their collaboration, expertise, and ability to rise to challenges have been instrumental in our collective success. From brainstorming solutions to supporting each other in high-pressure situations, my teammates have been a pillar of strength in this journey.

And of course, one of the most amusing parts of this journey has been seeing distant colleagues stumble upon my profile on Teams. The moment they realize that Adebowale Bello (Backend Intern) is actually leading a technical team instead of fetching coffee always gives me a bit of joy. It’s the little things!

Becoming the Face of Accountability

One of the most jarring shifts was realizing that as a lead, I wasn’t just responsible for my work; I was accountable for my team’s performance. If a project failed, if an integration broke, or if a stakeholder had concerns, I was the first point of contact. This required cultivating a strong problem-solving mindset and not just identifying issues but proactively addressing them before they escalated. Owning both successes and failures became part of the role.

Always Having (or Finding) the Answers

Technical leadership doesn’t mean knowing everything; it means knowing how to find answers. Whether it’s debugging a complex issue, optimizing system performance, or justifying a technical decision to stakeholders, I had to be prepared. This required staying updated on industry trends, constantly improving my problem-solving approach, and ensuring my team had the right resources to succeed.

Managing Pressure and Expectations

Pressure is inevitable. Juggling deadlines, ensuring the team’s efficiency, and balancing technical and managerial responsibilities required mental resilience. Managing and aligning with leadership’s expectations was just as crucial as managing and ensuring my team had clarity and support. Setting realistic expectations, communicating effectively, and prioritizing tasks helped in keeping the chaos under control.

A Culture That Encourages Growth

Beyond my team, the company’s commitment to fostering a culture of continuous learning and innovation has been a key driver in my growth. The environment has encouraged experimentation, provided access to learning resources, and offered opportunities to take on challenging projects that pushed me out of my comfort zone. Having an organization that values professional development has made the transition into leadership smoother and more rewarding.

Stakeholder and Cross-Functional Collaboration

As a technical lead, my role extended beyond my immediate team. Engaging with product managers, designers, and business executives became routine. Translating technical complexities into digestible information for non-technical stakeholders was a skill I had to hone. Understanding business needs and aligning technical solutions with them was key to driving impact.

Conclusion

The journey from an intern to a technical lead has been transformative. The growth has been immense, not just in technical proficiency but in leadership, communication, and decision-making. It’s a role that demands continuous learning, resilience, and adaptability. While the challenges are many, the fulfillment of leading a team, driving impact, and shaping solutions that matter makes it all worthwhile.

And the learning continues! I strive every day to bring my A-game, improve my skills, and encourage those around me to do the same. For anyone navigating a similar path, embrace the steepness of the climb, it’s where growth happens. And never underestimate the power of a great team and a company that champions growth.

Introduction to ElasticSearch in Laravel

Adebowale Bello — Tue, 16 Jul 2024 23:19:28 +0000

Introduction

Elasticsearch is a tool that helps you search and analyze large amounts of information very quickly. Imagine it as a super-fast librarian who can find exactly what you need from a huge collection of books in just a few seconds. When used with Laravel, Elasticsearch makes it easy to add advanced search features to your projects. This article will explain how to integrate Elasticsearch with Laravel, its advantages, disadvantages, and provide some examples of how to use it.

Think of Elasticsearch as a search engine for websites and apps, similar to how Google works for the internet. Here’s a simple comparison:

Google Search: Helps you find web pages, images, videos, etc from the entire internet quickly.
Elasticsearch: Helps you find specific information from your website or app's data quickly.

Just like Google can instantly give you results for any search query, Elasticsearch can do the same for the data in your website or app. It’s incredibly fast and can handle a lot of data at once, making it ideal for large websites or applications with lots of information.

Technical Definition of Elasticsearch

Elasticsearch is a distributed, RESTful search and analytics engine capable of addressing a growing number of use cases. As an open-source search engine, it is built on Apache Lucene and is known for its powerful and flexible search capabilities. Integrating Elasticsearch with Laravel, allows developers to implement advanced search functionalities efficiently.

Advantages of Using Elasticsearch with Laravel

High Performance: Elasticsearch is optimized for full-text search and performs complex queries in milliseconds.
Scalability: It can scale horizontally, handling large volumes of data by distributing them across multiple nodes.
Real-time Data: Provides near real-time search and analytics, which is crucial for applications needing up-to-date information.
Flexible Querying: Supports a wide range of search capabilities, including fuzzy search, keyword matching, and complex boolean queries.
Community and Documentation: As a widely-used tool, Elasticsearch has comprehensive documentation and a large community for support.

Disadvantages of Using Elasticsearch with Laravel

Complexity: Setting up and configuring Elasticsearch can be complex compared to traditional SQL databases.
Resource Intensive: It requires significant memory and CPU resources, especially for large-scale applications.
Data Consistency: Elasticsearch may not always guarantee immediate consistency, which could be an issue for some applications.
Learning Curve: Requires a learning curve for developers unfamiliar with its querying language and configuration.

Applications of Elasticsearch in Laravel

E-commerce Platforms: For product search and filtering.
Content Management Systems: To enable powerful content search and indexing.
Real-time Analytics: For analyzing logs, metrics, and monitoring data in real-time.
Social Networks: To implement search functionalities for users, posts, and other entities.
Enterprise Search: For indexing and searching across internal documents and databases.

Integrating Elasticsearch with Laravel

To integrate Elasticsearch with Laravel, we use Laravel Scout, a driver-based library for adding full-text search to Eloquent models, and the Elasticsearch driver for Laravel Scout.

Step 1: Install Elasticsearch

First, install Elasticsearch on your local machine or server. Follow the installation instructions from the Elasticsearch website.

Step 2: Install Laravel Scout and Elasticsearch Driver

Run the following commands to install Laravel Scout and the Elasticsearch driver:

composer require laravel/scout
composer require babenkoivan/scout-elasticsearch-driver

Step 3: Configure Laravel Scout

Publish the Scout configuration file and set the driver to Elasticsearch:

php artisan vendor:publish --provider="Laravel\Scout\ScoutServiceProvider"

Update the .env file:

SCOUT_DRIVER=elastic

Configure Elasticsearch in config/scout.php:

'driver' => env('SCOUT_DRIVER', 'algolia'),

'elasticsearch' => [
    'index' => env('ELASTICSEARCH_INDEX', 'your_index_name'),
    'hosts' => [
        env('ELASTICSEARCH_HOST', 'http://localhost'),
    ],
],

Step 4: Add Searchable Trait to Models

To make a model searchable, add the Searchable trait to the model class. For example:

use Laravel\Scout\Searchable;

class Post extends Model
{
    use Searchable;

    public function toSearchableArray()
    {
        return $this->toArray();
    }
}

Step 5: Index Data

Index your existing data using the scout:import command:

php artisan scout:import "App\\Models\\Post"

Step 6: Perform Search Queries

Use the search method to perform search queries on your model:

$posts = Post::search('example search term')->get();

Sample Usage

Here’s a simple search implementation in Laravel:

Search Form (Blade Template)

<form action="{{ route('posts.search') }}" method="GET">
    <input type="text" name="query" placeholder="Search posts...">
    <button type="submit">Search</button>
</form>

Controller Action

use App\Models\Post;

public function search(Request $request)
{
    $query = $request->query;
    $posts = Post::search($query)->get();

    return view('posts.search_results', compact('posts'));
}

Search Results Blade Template

@if($posts->isEmpty())
    <p>No posts found.</p>
@else
    <ul>
        @foreach($posts as $post)
            <li>{{ $post->title }}</li>
        @endforeach
    </ul>
@endif

Conclusion

Integrating Elasticsearch with Laravel provides powerful and flexible search capabilities that enhance the functionality of any application. Despite the complexity and resource requirements, the benefits of high performance, scalability, and real-time data handling make Elasticsearch a valuable tool for developers. By following the steps outlined above, you can efficiently implement Elasticsearch in your Laravel projects, providing users with a robust search experience.

Comprehensive Guide to Using Observers in Laravel

Adebowale Bello — Sat, 25 May 2024 16:42:45 +0000

Introduction

Laravel Observers are a powerful feature that allows you to hook into the lifecycle events of your Eloquent models. By using observers, you can listen for various events that are fired by the model, such as when a model is created, updated, or deleted, and then execute specific logic in response to those events. This helps in keeping your code clean and maintaining the single responsibility principle.

Lifecycle Events

Observers can listen to the following model events:

retrieved
creating
created
updating
updated
saving
saved
deleting
deleted
restoring
restored

In this article, I will show a quick use case of sending user authentication credentials to a new user upon profiling. We will create a user model observer that sends an email to the new user when admin creates his profile on the system.

Creating an Observer

To create an observer, you can use the make:observer Artisan command. For example, to create an observer for the User model, you would run:

php artisan make:observer UserObserver --model=User

This command will generate a new observer class in the app/Observers directory.

Registering an Observer

To register the observer, you need to add it to the boot method of one of your service providers, typically the AppServiceProvider. For example:

use App\Models\User;
use App\Observers\UserObserver;

/**
 * Bootstrap any application services.
 *
 * @return void
 */
public function boot()
{
    User::observe(UserObserver::class);
}

Creating the UserCredentials notification class

Create a notification class to send the email if it doesn't already exist:

php artisan make:notification UserCredentials

Update the UserCredentials notification:


namespace App\Notifications;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Notifications\Messages\MailMessage;
use Illuminate\Notifications\Notification;

class UserCredentials extends Notification
{
    use Queueable;

    protected $username;
    protected $password;

    /**
     * Create a new notification instance.
     *
     * @param string $username
     * @param string $password
     * @return void
     */
    public function __construct($username, $password)
    {
        $this->username = $username;
        $this->password = $password;
    }

    /**
     * Get the notification's delivery channels.
     *
     * @param mixed $notifiable
     * @return array
     */
    public function via($notifiable)
    {
        return ['mail'];
    }

    /**
     * Get the mail representation of the notification.
     *
     * @param mixed $notifiable
     * @return \Illuminate\Notifications\Messages\MailMessage
     */
    public function toMail($notifiable)
    {
        return (new MailMessage)
                    ->greeting('Hello!')
                    ->line('Your account has been created.')
                    ->line('Username: ' . $this->username)
                    ->line('Password: ' . $this->password)
                    ->line('Thank you for using our application!');
    }

    /**
     * Get the array representation of the notification.
     *
     * @param mixed $notifiable
     * @return array
     */
    public function toArray($notifiable)
    {
        return [
            //
        ];
    }
}

Sample Observer

Here's an example of a UserObserver that listens for the created events:

namespace App\Observers;

use App\Models\User;
use App\Notifications\UserCredentials;
use Illuminate\Support\Facades\Log;

class UserObserver
{
    /**
     * Handle the User "created" event.
     *
     * @param  \App\Models\User  $user
     * @return void
     */
    public function created(User $user)
    {
        $plainPassword = $user->password;
        $user->notify(new UserCredentials($user->email, $plainPassword));

     /** Ensure the password is hashed if the create method 
      *  had saved plain text from the controller
      */

        $user->password = Hash::make($plainPassword);

    }
    // Other events can be handled similarly...
}

Using the Observer

Once the observer is registered, it will automatically listen for the specified events on the model. For example, whenever a User model is created, the corresponding methods in the UserObserver will be executed, thereby sending the login credential to the created user.

Benefits of Using Observers

Separation of Concerns: Observers help in keeping the model and business logic separate. This makes the codebase cleaner and more maintainable.
Code Reusability: By using observers, you can reuse the same logic across multiple parts of your application without duplicating code.
Centralized Logic: Observers allow you to centralize event-based logic in one place, making it easier to manage and update.
Enhanced Readability: With observers, your models are free from additional responsibilities, making them easier to read and understand.
Easy Testing: Observers can be tested independently of the models, which simplifies the testing process.

Conclusion

Laravel Observers provide a structured and efficient way to handle model events. By leveraging observers, you can keep your codebase clean, maintainable, and adhere to best practices like the single responsibility principle. They are a valuable tool in any Laravel developer's arsenal, promoting better organization and modularization of code.

Unleashing the Power of Method Chaining in PHP

Adebowale Bello — Tue, 16 Jan 2024 11:22:07 +0000

In programming, readability and efficiency are essential. Method chaining is a sophisticated feature that gives your code a hint of both. Imagine writing one neat line of code that could handle a series of operations on an object. That is how method chaining works its magic.

What is Method Chaining?

Method chaining is a technique that allows you to call multiple methods on an object in a single statement. This not only streamlines your code but also enhances its readability. In PHP, method chaining is made possible by designing methods to return the object itself ($this), enabling subsequent calls.

The Basics

Let's dive into a simple example. Consider a Calculator class:

class Calculator
{
    private $result;

    public function setValue($value)
    {
        $this->result = $value;
        return $this;
    }

    public function add($value)
    {
        $this->result += $value;
        return $this;
    }

    public function multiply($value)
    {
        $this->result *= $value;
        return $this;
    }

    public function getResult()
    {
        return $this->result;
    }
}

// Usage example:
$calculator = new Calculator();
$result = $calculator->setValue(5)->add(3)->multiply(2)->getResult();

In this example, each method returns $this, allowing us to chain subsequent methods. The result is a clear and concise sequence of operations.

Benefits of Method Chaining

1. Conciseness:

By combining several lines of code into one, method chaining makes your code more readable and concise.

2. Readability:

The linear structure of method chaining improves code readability. Each method call builds upon the previous one, creating a smooth flow.

3. Fluent Interfaces:

Using method chaining helps to create interfaces that are fluid. Your code has a natural language feel to it because it reads like a phrase.

4. Less Temporary Variables:

With method chaining, you often don't need temporary variables to store intermediate results, reducing clutter in your code.

Practical Use Cases

1. Configuration:

Method chaining is commonly used in configuration settings. You can set multiple options in a single statement, providing a clear configuration process.

$config = new Configuration();
$config->setOption1('value1')->setOption2('value2')->setOption3('value3');

2. Query Builders:

Database query builders frequently leverage method chaining. Each method call adds a new condition or operation to the query.

$query = new QueryBuilder();
$query->select('column1', 'column2')->from('table')->where('condition')->orderBy('column1', 'ASC');

3. Fluent APIs:

Fluent APIs use method chaining to create expressive and readable interfaces. This is common in libraries and frameworks.

$user = new User();
$user->setName('John')->setAge(25)->setEmail('john@example.com')->save();

Pitfalls to Avoid

While method chaining is a powerful tool, it's essential to use it judiciously:

1. Overuse:

Avoid chaining too many methods in a single line. Balance conciseness with readability.

2. Complexity:

Be cautious with method chaining in complex logic. Ensure that each method call is clear and doesn't introduce confusion.

Conclusion

One useful approach that can greatly enhance the readability and conciseness of your PHP code is method chaining. You may write cleaner, more maintainable code by utilizing this elegant feature to design interfaces that are more expressive and fluid.

In your next PHP project, consider incorporating method chaining where appropriate. As you unlock the potential of this technique, your code will become not just functional, but a joy to read and maintain.

Happy coding!

"Laravel: Real-time Application Data Issue Export Directly To A Slack Channel"

Adebowale Bello — Sat, 14 Oct 2023 00:43:03 +0000

User interaction is vital for an application's success. With more users, chances of use case issues arises, thereby creating bad data in your application's db. Addressing these in real-time is crucial. Imagine if your app could proactively report defects or bad data to the team before clients notice.

In this article, I'll show you how to integrate direct reporting to Slack via a Slack app, streamlining the process.

In this article, I will cover;

Creating A Slack App
Creating sample command that handles recognising failed payments with reference to a simple E-commerce payment system

Creating a slack app
To get started, go to Slack and click on the "Create New App" button. Then, select the first option as shown in the image below.

Enter the application name, choose a workspace, and then press the "Create App" button to save the form.

After creating our app, choose the "Incoming Webhooks" option and toggle it on the next screen.

Navigate to the bottom of the page and select "Add New Webhook to Workspace." Then, on the following screen, pick a channel and click "Allow."

Slack will generate a webhook URL. Copy it and paste it into your app's .env file as shown below.

FAILED_PAYMENT_SLACK_WEBHOOK_URL=https://hooks.slack.com/services/xxxxxxxxxx

Creating sample command

In Laravel, commands are custom, reusable scripts that perform specific tasks within the application. They can be executed via the command line interface (CLI) and are useful for automating tasks, such as database migrations, scheduled jobs, and custom operations.

In Laravel, custom commands are typically stored in the app/Console/Commands directory. You can create a new command using the Artisan CLI or by manually creating a new PHP file in that directory.

Here's an example of a basic command:

Creating a Command

You can create a command using Artisan. Open your terminal and run:

php artisan make:command ExportFailedPayments
This will generate a new command file named ExportFailedPayments.php in the app/Console/Commands directory.

Sample Command Code

Open the generated ExportFailedPayments.php file and you'll find something like this:

use Illuminate\Console\Command;
use Illuminate\Support\Facades\Http;
use Illuminate\Support\Facades\Storage;

class ExportFailedPayments extends Command
{
    protected $signature = 'export:failed-payments';
    protected $description = 'Export failed payments to CSV and send to server';

    public function handle()
    {
        // Generate CSV data (replace this with your actual logic)
        $csvData = [
            ['order_id', 'payment_id', 'status'],
            [1, 101, 'failed'],
            [2, 102, 'failed'],
            // Add more rows as needed
        ];

        $csvFilePath = storage_path('app/failed_payments.csv');
        $file = fopen($csvFilePath, 'w');

        foreach ($csvData as $row) {
            fputcsv($file, $row);
        }

        fclose($file);

        $message = "Daily Failed Payment Report:\n
        File: <" . file_get_contents($csvFilePath) . "|Download CSV>";

        $data = [
            'text' => $message,
        ];

        Http::post(env('FAILED_PAYMENT_SLACK_WEBHOOK_URL'), $data); // Replace with your actual slack webhook url.


        // Clean up: Delete the local CSV file
        unlink($csvFilePath);
    }
}

Using the Command

You can now execute this command in the terminal using its signature:

php artisan export:failed-payments

This will trigger the handle method, and any logic you place there will be executed.

Remember, this is a basic example. Commands can perform a wide range of tasks, from database operations to complex data processing. But we are only referencing a failed payment export instance in this article.

In E-commerce, it is important to reconcile failed payment as early as possible, so in this article, I will show you how to create a cron job that schedules this command above to run as often as you want it to.

To schedule this command to run at e.g (5pm every day), you'll need to add an entry to your Laravel scheduler. Open the App\Console\Kernel.php file and add the following code to the $commands array:

protected $commands = [
    // ... other commands ...
    Commands\ExportFailedPayments::class,
];

Next, in the schedule method of the same file, add the following line to schedule the command:

protected function schedule(Schedule $schedule)
{
    // ... other scheduled tasks ...

    $schedule->command('export:failed-payments')
             ->dailyAt('17:00'); // This will run the command at 5:00 PM
}

Now, your ExportFailedPayments command will be scheduled to run at 5:00 PM every day. Make sure your server is correctly configured to handle Laravel's scheduled tasks (using cron or task scheduler depending on your server environment).

Below, you'll find an example of the report based on the focus of this article.

I hope this was helpful. Thanks for dropping by!