标签：#serverless

At Twio we picked pg-boss for our job queue, ran into trouble when we went serverless, looked at Pub/Sub, and ended up on Google Cloud Tasks. This is what each queue got right, what it got wrong for our workload, and the rule we landed on for choosing between them. The workload Twio is an AI SaaS for loan brokers. The piece that needs a job queue is email processing: download an email, parse the body and attachments, OCR, classify with an LLM, write structured data, and index for RAG. One email with five attachments easily becomes 30+ background jobs. A batch upload becomes hundreds. Why pg-boss worked — until it didn't Our database was Postgres on Neon, so pg-boss was the obvious starting point. No extra infrastructure, and one feature we genuinely loved: transactional enqueue . Because jobs live in the same database as business data, you can create a job in the same transaction as the row that triggered it. No dual-write problem, no "DB succeeded but the queue API failed" inconsistency. It also gave us retries, delayed jobs, dead-letter queues, dedup keys, and full SQL visibility into stuck or failed jobs. For a Postgres-first app on always-on infra, it's an excellent tool. Then we moved heavy processing to Cloud Run, and the cracks showed up. pg-boss polls. Neon suspends. They want opposite things. pg-boss runs a query roughly every 1–2 seconds to look for the next job, plus maintenance queries. Neon autosuspends compute when nothing touches the database. If the queue is polling every second, Neon's idle timer never expires — you pay for always-on compute even when the queue is empty. Worse, when Neon did manage to suspend, the next poll had to wake it. That wake-up takes hundreds of ms to a few seconds, and queries that triggered it would fail with Connection terminated , ECONNRESET , or timeouts. Pooled connections made it worse: the pool kept sockets that the server had already closed during suspend, and the next polling cycle picked one up and broke. This isn

I recently read Jérémie Rodon's excellent article On-Demand Archives on S3 , where he describes an elegant Rust solution for zipping 3,000 × 5MB files from S3 within a single Lambda function. His approach is impressive: streaming a ZIP archive through a custom Rotating Slab Buffer, saturating bandwidth with concurrent downloads, all within 512MB of RAM. The result: 3 minutes 35 seconds . I thought it was a good challenge to reach better performance. His article ends with an open invitation: "do you think you can do better with your favorite language?" Well, my favorite language is not Rust nor Go nor.. however, I'm fluent in serverless ;) so I took a different angle entirely. A Different Approach: Why Not Parallelize the Problem? Jérémie's constraint was a single Lambda. That's elegant, but it means you're bound by one machine's network bandwidth (~600 Mbps). No matter how perfect your streaming is, physics wins: 15GB at 600 Mbps ≈ 200 seconds minimum. My question was: what if we break that single-machine bottleneck? The key insight is that ZIP files in STORE mode (no compression) have deterministic byte offsets . Each entry is exactly 50 + len(filename) + filesize bytes (local header + ZIP64 extra field + data). If you know all filenames and sizes upfront, you can pre-calculate exactly where every file will land in the final archive, before downloading a single byte. This means independent workers can each build their portion of the zip in parallel, and S3's multipart upload lets them write their chunks independently (parts can be uploaded in any order by different processes sharing the same upload ID). Architecture Planner Lambda → Step Functions Distributed Map → N Worker Lambdas → Finalizer Lambda │ │ │ │ │ │ CreateMultipartUpload │ │ │ UploadPart (parallel) │ CompleteMultipartUpload ▼ ▼ ▼ ▼ ▼ S3 Output Bucket Planner : Lists all source files, computes zip byte offsets, initiates multipart upload, divides work into balanced batches (equal data volume per worker)

I used to deploy Node.js apps on EC2 and manage servers like it was my second job. Port configs. PM2 restarts. Nginx rewrites. SSL renewals. Then I ran my first AWS Lambda function. 80% of that work is gone. Here's what Lambda actually does that nobody explains clearly: → You write a function → AWS runs it ONLY when triggered → You pay for milliseconds of execution → It scales from 1 to 1,000,000 requests without you touching anything As a full-stack developer in Bahrain, preparing for my AWS Developer Associate exam, this is the shift that changes how you think about backend architecture. Not "how do I manage a server" but "what should happen when this event fires." That mental model switch took me a week to fully get. I'm documenting everything as I study. Drop a 🔥 if you want me to share my Lambda notes weekly.

I Built pretext-pdf: Serverless PDFs Without Chromium I got frustrated with PDF generation in Node.js. Every tool had trade-offs, and none of them felt right. The Problem Every time I needed to generate PDFs programmatically, I hit the same walls: Puppeteer — Renders HTML to PDF beautifully, but takes 500ms-2s per page. Way too slow for batch operations. wkhtmltopdf — Old, fragile, breaks in production, dependency hell. pdfmake — Good for simple invoices, falls apart with complex layouts. All of them — Overkill if you're not rendering HTML. And here's the kicker: I didn't need to render HTML. I had structured data (invoices, reports, certificates) that I needed to turn into PDFs programmatically . The Solution I built pretext-pdf — a JSON-based PDF generation library. Instead of: javascript // ❌ Puppeteer: render HTML const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.setContent(html); const pdf = await page.pdf(); // 1000ms+ You do: // ✅ pretext-pdf: define structure const doc = { sections: [ { type: 'heading', text: 'Invoice' }, { type: 'table', rows: [...] } ] }; const pdf = await renderPDF(doc); // 40-100ms No Chromium. No external dependencies. Pure Node.js. Why This Matters If you're building: ✅ Invoice generation systems ✅ Dynamic reports for your SaaS ✅ AI agents that create PDFs (Claude, Cursor, Windsurf) ✅ Certificate systems ✅ Multi-language documents ...pretext-pdf is built for you. Today: v2.0.14 Launch I just shipped a major upgrade. The text layout engine (which handles how words break across lines) is now significantly better: Better CJK + Latin mixed-script handling Smarter punctuation (quotes stay with their text) 7-12% faster Zero breaking changes The Stats 337 tests passing — production-ready 0 critical vulnerabilities — secure MIT licensed — free to use Open source — contribute or fork Technical Foundation The layout engine is based on pretext by Cheng Lou (React core team). I cherry-picked 11 patches for

As AI agents move from experiments to production, AWS, Cloudflare, and others are redesigning cloud infrastructure for a future dominated by machine-generated internet traffic instead of human users.

Demystifying WebP to PNG: How to Secure Serverless Edge Routing Configurations Safely We have all been there. You are building a high-performance, modern web application and you decide to store all user-generated assets in modern, ultra-compressed WebP formats. It is a smart move for your Google Lighthouse scores. Then, the legacy enterprise integration request hits your inbox. A major client needs to pull these same assets dynamically, but their internal 15-year-old reporting engine only supports PNG. Suddenly, you need to configure a runtime conversion pipeline that handles complex input schemas, transforms formats on the fly, and manages edge routes without exposing your internal database claims or API secrets. Setting up secure serverless edge routing configurations to convert images on-demand can quickly turn into a security nightmare. If you do not handle incoming credential tokens correctly, you risk forwarding sensitive OAuth scopes or database keys directly to downstream image-processing worker nodes. In this guide, we will break down exactly how to architect a lightweight, secure, and fast edge routing pipeline that validates incoming image request schemas and converts WebP to PNG without leaking sensitive backend credentials. The Problem Modern edge runtimes like Cloudflare Workers, Vercel Edge Functions, or AWS CloudFront Functions are incredibly fast, but they have strict execution limits. They run on V8 isolates, meaning you do not have a full Node.js environment with unlimited memory and access to heavy C++ binaries like sharp or canvas without paying a massive cold-start penalty. If you want to support legacy clients by converting WebP to PNG on the fly, you are faced with three major challenges: Bundle Size Restrictions : Edge functions typically restrict your code size to 1MB or 2MB. Bundling heavy native libraries to parse image bytes is a recipe for deployment failures. Credential Leakage : Edge routers often intercept incoming JWT authorization

Cloudflare recently added support for Claude Managed Agents, allowing developers to run and manage Claude agents within Cloudflare. Developers can connect agents to private systems, choose their runtime environment, and monitor agent activity using Cloudflare services. By Renato Losio