DEV Community: Ianstudios

Stop Logging Raw JSON: How I Built a Visual Audit Trail for Filament PHP

Ianstudios — Tue, 03 Feb 2026 02:30:15 +0000

We’ve all been there. You need to track who changed what in your database. You install an audit package, and it works—but every time you need to check the history, you’re staring at a wall of raw JSON in a database manager or a cramped table.

I wanted something better for my Filament projects. I wanted to "Time Travel."

That’s why I built Chronos.

⏳ What is Chronos?
Chronos is a audit trail plugin for Filament V4 / V5 that focuses on one thing: Visibility.

Instead of just logging changes, it provides a beautiful, side-by-side comparison of your data. You can see exactly what changed, when, and by whom, all within a sleek slide-over UI.

🚀 The "Zero-Build" Challenge
One of my main goals was to make Chronos a "plug-and-play" experience.

Usually, when you build custom UI for Filament, you have to deal with Tailwind JIT, custom configurations, and running npm run build. For Chronos, I went a different route. I utilized native Filament classes and CSS variables.

The Result? You install it, and it immediately adopts your panel's primary colors and dark mode settings without touching a single JS file.

✨ Key Features
Visual Diffs: Color-coded highlighting for Created (Green), Updated (Blue), and Deleted (Red) events.

Context Aware: Automatically captures User data, IP addresses, and timestamps.

Polymorphic: It doesn't matter what your model is; if it’s Eloquent, Chronos can track it.

Dark Mode Support: Looks just as good at 2 AM as it does at 10 AM.

🛠️ How it looks in code
Integrating Chronos is intentionally simple.

Add the trait to your Model:

use Ianstudios\Chronos\Concerns\HasChronos;

class Product extends Model {
    use HasChronos;
}

Add the Action to your Filament Resource:

use Ianstudios\Chronos\Actions\ChronosHistoryAction;

// In your Header Actions or Table Actions
ChronosHistoryAction::make()

That’s it. No complicated setup, no overhead.

📦 Try it out!
I’ve just released v1.7.0, which brings improved native styling and better performance for large audit logs.

If you’re building CRMs, ERPs, or any data-sensitive application with Filament, Chronos might just be the "Time Travel" tool you’ve been looking for.

Check out the live demo and documentation here:
👉 https://creator.ianstudios.id

Final Thoughts
Building tools for the Filament ecosystem has been an amazing journey. The community focus on DX (Developer Experience) is what drives me to keep refining Chronos.

How are you currently handling audit logs in your Laravel apps? Let’s chat in the comments! 👇

Stop Hardcoding Your API Integrations: The Agnostic Way with Megamorph

Ianstudios — Wed, 28 Jan 2026 16:03:34 +0000

The "Integration Debt" Nightmare

We’ve all been there. A project starts with one payment gateway. Then, the business decides to add a new shipping courier, a CRM, and three other third-party vendors. Suddenly, your application is crawling with "Spaghetti Code"—thousands of lines of if-else blocks and messy webhook controllers.

This is what I call Integration Debt. You aren't just coding; you are becoming a slave to your vendor's data structure.

Introducing Megamorph: One Bridge to Rule Them All

Megamorph is a Laravel/Filament plugin designed to be the intelligent layer between your application logic and any external service. Instead of writing rigid code for every vendor, Megamorph empowers you to create a new standard: The Agnostic Way.

Build integrations without code. Decouple your application logic from third-party vendor constraints with a powerful, metamorphic transformation layer.

Megamorph empowers developers to create flexible, scalable API integrations for Laravel applications using Filament. Say goodbye to rigid code and hello to configurable, metamorphic mappings that adapt to any vendor's requirements—effortlessly.

💡 Why Choose Megamorph?

In today's fast-paced development landscape, modern applications are frequently hampered by vendor lock-in and hardcoded integration debt. Integrating third-party APIs often involves crafting brittle DTOs (Data Transfer Objects), manual data mappers, and ad-hoc logging for each provider. When vendors update their schemas (e.g., renaming a field from "email" to "user_email") or you need to switch providers, your codebase demands extensive refactoring, leading to downtime and frustration.

Common Pain Points with Standard HTTP Clients

The Deployment Bottleneck: Even trivial changes, like field renames, necessitate code updates, pull requests, reviews, and deployments—slowing your team down.
The "Black Box" Syndrome: Basic Http::post() calls lack transparency. Without manual logging, debugging production issues becomes a guessing game, wasting hours on root-cause analysis.
Transformation Overload: Controllers and services bloat with vendor-specific logic—formatting dates, computing taxes, or string manipulations—just to match the API's JSON structure.
Vendor Lock-In Trap: Migrating from one provider (e.g., Stripe to PayPal) requires a full rewrite of your integration layer, risking bugs and extended timelines.

Megamorph solves these by introducing a metamorphic layer that treats API integrations as configuration, not code. Send your internal data structures, and let Megamorph dynamically "morph" them to fit any vendor—all managed through an intuitive Filament UI.

🚀 Key Features

Megamorph is designed for real-world scalability, with features that streamline development, operations, and auditing:

Zero-Code Mapping: Visually map your internal data keys to external vendor fields using a drag-and-drop Filament interface—no PHP changes required.
Dynamic Expression Engine: Leverage Symfony Expression Language for advanced transformations, including math operations, string manipulations, conditionals, and more—right within your mappings.
Environment Swapping: Effortlessly switch between sandbox and production credentials via the UI, eliminating the need to edit .env files or manage multiple configs.
Shadow Logs (Full Audit Trail): Gain deep visibility with automatic logging of every request and response, including payloads, headers, and metadata—for effortless debugging and compliance.
Smart Replay: Handle vendor outages gracefully by replaying failed requests with one click, reducing manual intervention and data loss.
Bulk CSV Export: Generate professional reports for finance, audit, or compliance teams with filtered, exportable log data.
Log Retention Policies: Maintain a lean database with automated purge commands, ensuring performance in high-traffic environments.
Polymorphic Linking (v1.1 Roadmap): Directly associate logs with your application's Eloquent models (e.g., User, Order) for contextual insights.

📖 How It Works: Core Concepts

Megamorph operates on a hierarchical structure for clarity and flexibility:

Provider: Represents the third-party service (e.g., "Payment Gateway" like Stripe or "Email Service" like SendGrid).
Endpoint: Defines specific actions within a provider (e.g., "Charge Card" or "Send OTP").
Mapping: Configures transformation rules for each endpoint, including key mappings, expressions, and authentication.

Feature Comparison: Megamorph vs. Standard Laravel HTTP

Feature	Standard Laravel HTTP	Megamorph Bridge
Field Mapping	Hardcoded in PHP	Configured via UI
Logic/Formulas	Inside Controllers	In Metamorphic Layer
Logging	Manual / Third-party	Native "Shadow Logs"
Field Changes	Requires Deployment	Instant via Dashboard
Switching Vendors	Heavy Refactoring	Swap Provider in UI
Audit & Replay	Custom Implementation	Built-in Smart Replay & Exports

This table highlights how Megamorph reduces technical debt and accelerates iterations.

Ready to Elevate Your Architecture?

Megamorph isn't just a plugin; it's a new mindset for building future-proof systems. Stop chasing API documentation and start controlling it.

🔗 Explore the Demo & Documentation: https://creator.ianstudios.id

About the Project
Megamorph is part of a premium ecosystem developed by Ianstudios

The Art of Unification: How I Built 'TapTable' to Kill Controller Bloat in Laravel

Ianstudios — Wed, 21 Jan 2026 14:19:05 +0000

We’ve all written that Controller method.

You know the one I'm talking about. It starts innocent enough:

return view('products.index', [
    'products' => Product::paginate(10)
]);

But then the requirements start pouring in from the product manager:

"Can we search by SKU?"
"We need a filter for 'Out of Stock'."
"Can we sort by Date Created?"
"We need a bulk delete button."
"Oh, and export to Excel, please."

Suddenly, your concise Controller method has exploded into 100 lines of if ($request->has(...)) statements, messy query builder logic, and a view file cluttered with spaghetti loops.

I decided to stop this madness. I wanted a solution that felt like magic. A solution that unified all these disjointed components into a single, fluent PHP object.

Meet TapTable.

Here is the story of the headache I endured building it, and why "gluing" components together is harder than it looks.

The Challenge: The "Glue" Problem
Building a Data Table library isn't just about rendering HTML <tr> tags. The real challenge is State Management and Component Unification.

When you separate "Columns", "Filters", and "Actions" into different classes or arrays, they stop talking to each other.

The Export button needs to know the current Search state (to export only filtered results).

The Bulk Action needs to know which Checkboxes are selected across pages.

The Sort Link needs to preserve the Filter parameters in the URL query string.

Trying to glue these pieces together manually usually results in a messy API. My goal for TapTable was to make the Developer Experience (DX) seamless.

The Architecture of Unification
To solve this, I had to treat TapTable not just as a View Renderer, but as a State Container.

Instead of passing variables to a View manually, I built a fluent wrapper that captures the entire lifecycle of the table.

1. The Syntax Goal
I wanted the code to read like English. No configuration arrays, no separate config files. Just fluent method chaining.

Here is what the final result looks like:

// The Goal: Clean, Unified, Expressive
return TapTable::make(Product::query())
    ->columns([
        Column::make('name')->sortable()->searchable(),
        Column::make('price')->formatMoney(),
        Column::make('status')->badge(),
    ])
    ->filters([
        SelectFilter::make('category_id', Category::all()),
        DateFilter::make('created_at'),
    ])
    ->actions([
        BulkAction::make('delete')->danger(),
        Action::make('edit')->route('products.edit'),
    ])
    ->exportable()
    ->render();

2. Handling the "Under the Hood" Complexity
The hardest part was making the components intelligent.

For example, when you define Column::make('name')->searchable(), TapTable doesn't just render a search input. It acts as a middleware between the request and the response.

I had to build an internal Pipeline System:

Hydrate: Read the Request (URL params).
Apply Filters: Loop through defined filters and apply where clauses.
Apply Search: Loop through "searchable" columns and apply orWhere logic dynamically.
Apply Sort: Check for sort_by params.
Execute: Run the query (or trigger the Export download if requested).
Render: Pass the final collection to the View.

All of this happens inside the ->render() method. The developer never sees the messy logic.

The "Bulk Action" Nightmare
The tricky part of unification is interaction. Bulk Actions are the worst offenders.

In a standard setup, you usually have a

wrapping the table. But what if you have filters inside that form? What if the pagination links are outside?

I solved this by ensuring TapTable acts as the single source of truth. When a user checks a box, it doesn't just toggle a DOM element; it updates the library's internal state.

When "Delete" is clicked, the library knows exactly which IDs to process, without the developer having to write a manual foreach loop in the controller.

Why "TapTable"?
Because I wanted something that felt "Tappable". Mobile-friendly, fast, and interactive.

Most data table libraries are heavy. They load jQuery, DataTables.js, and tons of CSS. TapTable is designed to be lightweight and PHP-native. It leverages the power of Laravel to do the heavy lifting on the server, sending only pure HTML/Alpine.js to the client.

Conclusion
Building TapTable taught me that the hardest part of software engineering isn't writing complex logic—it's hiding complex logic behind a simple interface.

Unifying Columns, Filters, Queries, and UI into one cohesive package was a struggle, but seeing a 100-line Controller refactored into 10 lines of TapTable code made it all worth it.

If you are tired of wrestling with manual pagination and filtering, maybe it's time to unify your stack.

I'm currently using this in production for my SaaS project, PagoraPOS, and it has saved me hundreds of hours.

Have you built your own abstraction for tables? Or do you stick to standard Blade views? Let me know in the comments!

Solved: Direct Thermal Printing from a Web App without the Print Dialog (PHP/Laravel)

Ianstudios — Wed, 21 Jan 2026 13:58:43 +0000

Building a Point of Sale (POS) system on the web comes with one massive headache: Printing.

If you've ever built a web-based invoicing app, you know the drill. You call window.print(), the browser opens a print dialog, the user has to select the printer, maybe adjust margins, and finally click "Print".

For a busy retail cashier, that 5-second delay per transaction is unacceptable.

I recently built PagoraPOS, a TALL stack (Tailwind, Alpine, Laravel, Livewire) POS system. My goal was to make it feel like a native desktop app. That meant the printing had to be instant, silent, and pixel-perfect on thermal paper.

Here is how I solved the "Web-to-Thermal-Printer" challenge using PHP, bypassing the browser dialog entirely.

The Problem with window.print()
Standard browser printing relies on CSS. While you can style a page to look like a receipt (width: 80mm), you hit limitations fast:

The Solution: Raw ESC/POS Commands
Thermal printers (Epson, Star, Xprinter) speak a raw language called ESC/POS. Instead of sending an HTML image, you send hex commands.

For example, sending x1B\x40 initializes the printer. Sending x1D\x56\x42\x00 cuts the paper.

In the PHP ecosystem, the hero library for this is mike42/escpos-php.

> Step 1: The Setup
First, I installed the library in my Laravel project:

composer require mike42/escpos-php

> Step 2: Generating the Receipt on the Backend
Instead of rendering a Blade view, I created a Service Class responsible for generating the print commands.

Here is a simplified version of my PrinterService:

use Mike42\Escpos\Printer;
use Mike42\Escpos\PrintConnectors\NetworkPrintConnector;
use Mike42\Escpos\CapabilityProfile;

class ThermalPrintService
{
    public function printReceipt($transaction)
    {
        // 1. Connect to the printer (e.g., Network Printer on LAN)
        // In a real app, this IP comes from the database settings
        $connector = new NetworkPrintConnector("192.168.1.87", 9100);

        // 2. Load profiles (optimizes for specific brands like Epson/Star)
        $profile = CapabilityProfile::load("default");

        // 3. Initialize Printer
        $printer = new Printer($connector, $profile);

        try {
            // --- HEADER ---
            $printer->setJustification(Printer::JUSTIFY_CENTER);
            $printer->selectPrintMode(Printer::MODE_DOUBLE_WIDTH | Printer::MODE_BOLD);
            $printer->text("PAGORA STORE\n");
            $printer->selectPrintMode(); // Reset
            $printer->text("123 Laravel Blvd, Code City\n");
            $printer->feed();

            // --- ITEMS ---
            $printer->setJustification(Printer::JUSTIFY_LEFT);
            $printer->text("--------------------------------\n");

            foreach ($transaction->items as $item) {
                // Helper to pad text for alignment
                $line = $this->formatRow($item->name, $item->qty . 'x ' . $item->price);
                $printer->text($line . "\n");
            }

            $printer->text("--------------------------------\n");

            // --- TOTAL ---
            $printer->setJustification(Printer::JUSTIFY_RIGHT);
            $printer->setEmphasis(true);
            $printer->text("TOTAL: $" . $transaction->total . "\n");
            $printer->setEmphasis(false);
            $printer->feed(2);

            // --- HARDWARE ACTIONS ---
            $printer->cut(); // Cut the paper
            $printer->pulse(); // Open the Cash Drawer (Kick)

        } finally {
            $printer->close();
        }
    }

    private function formatRow($left, $right, $width = 32)
    {
        // Simple logic to create "Product Name ...... $10.00" layout
        $len = $width - strlen($right);
        return str_pad(substr($left, 0, $len), $len) . $right;
    }
}

> Step 3: Bridging the Server and the Printer
This is where it gets tricky. PHP runs on the server, but the printer is in the client's shop.

In PagoraPOS, I handle this in two ways depending on the deployment:

Scenario A: Self-Hosted / Local Server If the client runs the app on a local server (e.g., a Mini PC in the store), PHP can talk directly to the printer's IP address (like the code above). It's lightning fast.

Scenario B: Cloud Server (SaaS) If the app is hosted on the cloud (AWS/DigitalOcean), PHP cannot reach 192.168.1.x. To solve this, instead of executing the print command in PHP, I generate the Raw Base64 Data of the ESC/POS commands and return it to the frontend (Alpine.js).

The frontend then sends this raw data to a small "Print Proxy" agent running on the cashier's computer (or uses a library like QZ Tray) to forward the data to the USB/Network printer.

Why this approach wins

Speed: No rendering HTML, no waiting for Chrome.
Control: I can trigger the Cash Drawer automatically when a cash payment is made.
Consistency: The receipt looks exactly the same regardless of the browser or OS.

Conclusion
Building a POS in Laravel has been an interesting journey. While frameworks like Filament V3 are amazing for the UI, diving into low-level hardware communication like ESC/POS is what makes the application feel "professional" for end-users.

If you are building a retail app, I highly recommend ditching the browser print dialog. Your users will thank you.

I'm currently refining this system in my project PagoraPOS. If you have questions about handling raw printing or the TALL stack structure for POS, drop a comment below!