Forem: Quicreatdev

How to build a blazing fast EU VAT Validation Rule in Laravel 🚀

Quicreatdev — Thu, 12 Mar 2026 12:37:50 +0000

If you are building a B2B SaaS or an e-commerce platform in Europe with Laravel, you eventually hit the same wall: EU VAT validation.

To legally apply the reverse charge mechanism (0% VAT), you must ensure your customer's VAT number is valid using the European Commission's VIES system. But integrating directly with the official VIES API is a pain:

It frequently goes down or times out.
It's synchronous and slow, which hurts your checkout conversion rate.
It limits concurrent requests.

Instead of writing complex fallback logic and caching mechanisms from scratch, let's build a clean, robust Laravel Custom Validation Rule using VatFlow, a serverless proxy that caches VIES data for instant responses.

Let's dive in! 🛠️

Prerequisites

A Laravel application (v9, v10, or v11).
A free VatFlow API Key via RapidAPI.

Step 1: Install the SDK

VatFlow provides an official, zero-dependency PHP wrapper that handles auto-retries out of the box. You can check out the source code on GitHub (feel free to drop a ⭐!).

Install it via Composer:

composer require quicreatdev/vatflow-php

Step 2: Configure your API Key

Add your RapidAPI key to your .env file:

VATFLOW_API_KEY=your_rapidapi_key_here

Then, map it in your config/services.php file so Laravel can access it cleanly:

// config/services.php

return [
    // ... other services
    'vatflow' => [
        'key' => env('VATFLOW_API_KEY'),
    ],
];

Step 3: Create the Custom Validation Rule

Laravel makes it incredibly easy to create custom rules. Run this artisan command:

php artisan make:rule ValidEuVat

Now, open the generated file app/Rules/ValidEuVat.php and implement the logic using the VatFlow client. We will configure it to use cached data (up to 7 days old) to guarantee a response time of a few milliseconds during checkout.

<?php

namespace App\Rules;

use Closure;
use Illuminate\Contracts\Validation\ValidationRule;
use VatFlow\VatFlowClient;
use Illuminate\Support\Facades\Log;

class ValidEuVat implements ValidationRule
{
    /**
     * Run the validation rule.
     */
    public function validate(string $attribute, mixed $value, Closure $fail): void
    {
        // 1. Initialize the client with your key
        $apiKey = config('services.vatflow.key');

        if (!$apiKey) {
            $fail('The VatFlow API key is missing.');
            return;
        }

        $client = new VatFlowClient($apiKey);

        // 2. Call the API (max cache age: 7 days, auto-retry: true)
        $response = $client->validate($value, 7, true);

        // 3. Handle network or API errors gracefully
        if (!$response['success']) {
            // We log the error, but we DO NOT fail the validation.
            // It's better to temporarily accept the order and check manually later 
            // rather than losing a customer because the government API is down!
            Log::warning('VAT Validation Service Unavailable: ' . $response['error']);
            return; 
        }

        // 4. Check if the VAT is actually valid
        if (!$response['data']['is_valid']) {
            $fail('The provided EU VAT number is invalid or inactive.');
        }
    }
}

Step 4: Use it in your Controller or Form Request

Now for the beautiful part. You can use your new rule just like any native Laravel rule!

Let's say you have a company registration form:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Rules\ValidEuVat;

class CheckoutController extends Controller
{
    public function store(Request $request)
    {
        $validated = $request->validate([
            'company_name' => ['required', 'string', 'max:255'],
            'vat_number'   => ['required', 'string', new ValidEuVat],
        ]);

        // If the code reaches here, the VAT number is 100% valid!
        // Proceed with user creation and 0% VAT billing...

        return response()->json(['message' => 'Company registered successfully!']);
    }
}

Wrapping up

By moving the VAT validation into a Custom Rule and using a cached proxy like VatFlow, your controllers stay incredibly clean, and your checkout process remains blazing fast—even when the European Commission's servers are struggling.

Bonus tip: The API response also returns the company's official name and address. Since Laravel Validation Rules aren't meant to modify the Request data, if you want to use this data to auto-fill your customer's profile, you can simply call the VatFlowClient directly in your Controller or within a dedicated Action class right after validation!

If you want to try it out, you can get a free API key and check out the documentation on the VatFlow website. You can also find the PHP package directly on Packagist.

Have you ever struggled with the VIES API in your Laravel projects? Let me know in the comments! 👇

I got tired of the official EU VAT API crashing, so I built a Serverless wrapper with Webhooks 🚀

Quicreatdev — Tue, 03 Mar 2026 12:59:24 +0000

Hello DEV community! 👋

If you've ever built a B2B SaaS or an e-commerce checkout in Europe, you know the struggle. By law, you have to validate your customers' VAT numbers to apply the reverse charge mechanism.

The official way to do this is via the European Commission's VIES API. But there are a few huge problems with it:

It frequently crashes or rate-limits you during business hours.
It's incredibly slow.
The biggest issue: It only tells you the status today. If your biggest client goes bankrupt or closes next month, you won't know until the unpaid invoices pile up.

I wanted a modern, fast, and proactive solution. So, I built VatFlow.

🛠 What I built

VatFlow is a REST API hosted on RapidAPI that acts as a smart shield and monitor for B2B company data.

Here is what makes it different:

⚡️ Smart Caching: I built a DynamoDB caching layer. If you request a VAT number that was recently checked, it returns in milliseconds. No more VIES downtime impacting your checkout flow.
🔔 Real-time Webhooks: This is the feature I'm the most proud of. You can subscribe to a VAT number. Every night, my serverless cron job checks the company's status. If they close down or change their address, your server gets a POST request instantly.
🇫🇷 Deep Enrichment (France): For French companies, the API automatically enriches the VIES data with financial data (revenue, net income) and executives' names using local Open Data.

🏗 The Tech Stack (100% Serverless)

I wanted this to be infinitely scalable and cost-effective, so I went all-in on AWS Serverless:

API Gateway & AWS Lambda (Node.js) for the endpoints.
DynamoDB for the lightning-fast caching and storing webhook subscriptions.
DynamoDB Streams & EventBridge to detect changes in the data and automatically trigger the webhook dispatcher.

💻 Developer Experience First

I know how annoying it is to integrate a new API. So alongside the launch, I published two official, zero-dependency wrappers with built-in auto-retry mechanisms (because network glitches happen).

For Node.js (npm):

npm install vatflow

const VatFlowClient = require('vatflow');
const client = new VatFlowClient('YOUR_RAPIDAPI_KEY');

// Validate a VAT number in one line
const result = await client.validate('FR14652014051');
console.log(result.data.name);

For PHP (Composer):

composer require quicreatdev/vatflow-php

🎁 Try it out!

I've published the API on RapidAPI with a Free Tier so you can test it without putting down a credit card.

👉 Check out VatFlow on RapidAPI here

I would absolutely love to hear your feedback on the architecture, the DX, or the RapidAPI integration. Have you ever struggled with the VIES API before? Let me know in the comments! 👇

How I turned Google Sheets into a Blazing-Fast REST API using AWS Serverless

Quicreatdev — Sun, 22 Feb 2026 16:14:21 +0000

Introduction
We’ve all been there: you need a quick backend for a prototype, an internal tool, or a NoCode project. Setting up PostgreSQL or MongoDB feels like overkill, so you think, "I'll just use Google Sheets as a database!"

It sounds great until you hit the reality of the Google Sheets API:

It’s slow (often 1-2 seconds per request).
Rate limits are strict (around 60 requests per user per minute).
No native query language (filtering data is a pain).

I wanted the simplicity of Google Sheets but the performance and security of a real backend. So, I built SheetToJSON, a serverless wrapper that solves these exact issues.

Here is a deep dive into the architecture and how I built it using AWS.

The Architecture Stack
To keep costs low and performance high, I went 100% Serverless:

Routing: AWS HTTP API Gateway
Compute: AWS Lambda (Node.js ARM64)
Caching: Amazon S3
Security & Auth: Amazon DynamoDB
Monetization & Gateway: RapidAPI

Challenge 1: Beating the Rate Limits and Latency
The biggest bottleneck of the Google Sheets API is the response time. To fix this, I implemented an aggressive caching strategy using Amazon S3.

When a user makes a GET request (e.g., fetching a list of products), the Lambda function first checks an S3 bucket for a cached .json version of that sheet.

Cache Hit: Data is returned in milliseconds.
Cache Miss: Lambda fetches data from Google Sheets, saves the raw JSON to S3 (with a 5-minute TTL), and returns the response.

But what about stale data? I implemented a Write-Through Cache. Whenever a user makes a POST, PATCH, or DELETE request through my API, the Lambda function updates Google Sheets and immediately rewrites the local S3 cache.
Result: Lightning-fast GET requests without sacrificing data freshness.

Challenge 2: Smart Querying (No Database Engine)
Google Sheets doesn't have a SQL engine. If a user wants to find all products where the price is greater than $50, they usually have to download the whole sheet and filter it on the client side.

I built a custom query engine directly in the Lambda function. When reading from the S3 cache, the API intercepts query parameters and processes them in-memory:

// Example: GET /v1/SPREADSHEET_ID/Products?price=gt:50&sort=price:desc

// The API engine automatically parses "gt:" (greater than), "lt:" (less than), 
// and "lk:" (like/contains) before returning the paginated payload.

This turns a dumb spreadsheet into a queryable NoSQL database.

Challenge 3: Multi-Tenant Security (Preventing IDOR)
If you are building a SaaS, security is your #1 priority. Because my API uses a single Google Service Account to read sheets, what prevents User A from guessing User B’s Spreadsheet ID and reading their data?

To prevent this Insecure Direct Object Reference (IDOR), I added a mandatory /register step backed by DynamoDB.
Before using the API, a user must register their sheet. The API links their X-RapidAPI-User ID to the spreadsheetId in DynamoDB.

Now, every CRUD request does a lightning-fast (~15ms) lookup in DynamoDB. If the user ID making the request doesn't match the owner ID of the sheet, the API throws a 403 Forbidden. Zero data leakage.

The Result: Developer Experience First
I wanted the integration to be as seamless as possible, so I published zero-dependency, official SDKs for both Node.js and PHP.

Here is what it looks like in Node (fully typed with TypeScript!):

import { SheetToJSON } from 'sheettojson-api';

const db = new SheetToJSON('YOUR_RAPIDAPI_KEY');

const response = await db.get('SPREADSHEET_ID', 'Products', {
    limit: 10,
    price: 'gt:50'
});

console.log(response.data);

Try it out!
Building this was an amazing journey into AWS Serverless architecture. If you are building a NoCode tool, a quick prototype, or need an instant backend, I'd love for you to try it.

I'm currently looking for feedback on the caching system and the query engine. Let me know what you think in the comments! 👇

Stop Running Puppeteer on Your Main Server: The Serverless Approach to Screenshots

Quicreatdev — Mon, 16 Feb 2026 12:39:40 +0000

Introduction

We've all been there. You're building a side project—maybe a link preview generator, an SEO tool, or a dashboard—and you think: "I just need to take a quick screenshot of this URL."

So you npm install puppeteer, write 10 lines of code, and it works locally. Great!

Then you deploy it to production (Docker, Ubuntu, or Heroku), and hell breaks loose.

The fonts are broken (rectangles instead of text).
The memory usage spikes to 2GB and crashes your server.
The target website shows a giant "Accept Cookies" banner covering the content.
Half the images are missing because of lazy-loading.

I spent the last month fighting these battles while building a screenshot microservice. Here is what I learned about doing it the hard way, and why I eventually turned it into a dedicated API.

The Trap: "It works on my machine"

Basic Puppeteer is deceptive. Here is the code everyone starts with:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');
  await page.screenshot({ path: 'example.png' });
  await browser.close();
})();

This works fine for example.com. But try running this against a modern Single Page Application (SPA) or a news site, and you will hit three major walls.

Wall #1: The Lazy Loading Problem

Modern web performance relies on lazy loading. Images only load when they enter the viewport. If you take a screenshot immediately after page.goto, you get a page full of placeholders.

The Fix: You need to simulate a user scrolling down, or wait for network activity to settle.

// Waiting for networkidle0 is reliable but SLOW (can take 10s+)
await page.goto(url, { waitUntil: 'networkidle0' });

Wall #2: The "Cookie Banner" Apocalypse

In 2026, the web is 50% content and 50% GDPR popups. A screenshot tool that captures the cookie banner is useless.

The Fix: You have to inject CSS or JS to nuke these elements before the shutter clicks.

await page.addStyleTag({
  content: '#onetrust-banner-sdk, .cookie-popup { display: none !important; }'
});

But maintaining a list of selectors for every site on the internet? Impossible.

Wall #3: Server Costs & Zombie Processes

Chromium is heavy. Running it in a standard container requires significant RAM. If your script crashes before browser.close() is called, you are left with "zombie" Chrome processes eating up your CPU until the server dies.

The Solution: Going Serverless (AWS Lambda)

To solve the crashing and scaling issues, I moved the architecture to AWS Lambda. This ensures that:

Each screenshot gets a fresh, isolated environment.
If it crashes, it doesn't take down my main server.
I only pay when a screenshot is taken.

However, getting Puppeteer on Lambda is tricky (binary sizes, font packages). I used puppeteer-core and @sparticuz/chromium to keep the package size under the 50MB limit.

Introducing FlashCapture

After refining this architecture to handle ad-blocking, dark mode, and full-page stitching automatically, I realized this was too valuable to keep as a messy internal script.

So, I wrapped it into a clean, public API called FlashCapture.

It handles all the edge cases I mentioned above:

✅ Smart Ad-Blocker: Automatically hides banners and trackers.
✅ Async Processing: No HTTP timeouts on large pages.
✅ Lazy Loading Support: We handle the wait logic.

Trying it out

If you are tired of maintaining your own Puppeteer instance, you can use the API directly via RapidAPI. There is a free tier for developers.

Here is how simple it is compared to the 50 lines of Puppeteer code:

const axios = require('axios');

const options = {
  method: 'POST',
  url: 'https://flashcapture.p.rapidapi.com/capture',
  headers: {
    'content-type': 'application/json',
    'X-RapidAPI-Key': 'YOUR_API_KEY',
    'X-RapidAPI-Host': 'flashcapture.p.rapidapi.com'
  },
  data: {
    url: 'https://www.reddit.com',
    options: {
      fullPage: true,
      darkMode: true, // Automagically renders in dark mode
      width: 1920
    }
  }
};

try {
    const response = await axios.request(options);
    console.log("Job ID:", response.data.id);
    // Then just poll the /status endpoint to get your image!
} catch (error) {
    console.error(error);
}

Conclusion

If you are building a production app, think twice before running a headless browser on your primary web server. It's a resource hog that introduces security risks and stability issues.

Whether you build your own microservice on AWS Lambda (like I did initially) or use a managed API like FlashCapture, decoupling this heavy task is the best architectural decision you can make.

👉 Check out FlashCapture on RapidAPI here

Happy coding! 🚀