DEV Community: Ben Halpern

Meme Monday

Ben Halpern — Mon, 22 Jun 2026 14:47:34 +0000

Meme Monday!

Today's cover image comes from the last thread.

DEV is an inclusive space! Humor in poor taste will be downvoted by mods.

How We Saved Big and Simplified Our Image Pipeline: Adopting bunny.net on DEV

Ben Halpern — Tue, 16 Jun 2026 16:41:51 +0000

Hey everyone, Ben here.

If you’ve been following the journey of DEV and our open source project Forem, you know we’ve always been obsessed with web performance. Way back in the day, I spoke at Codeland about how to make your website so fast it goes viral in Japan, diving into the mechanics of edge caching and how we kept our page loads nearly instant.

Our core philosophy has always been simple: keep the architecture as lean as possible, cache aggressively at the edge, and let the Rails monolith (Forem) focus on what it does best. For years, Fastly has handled our HTML edge caching brilliantly—most of your page requests never even have to touch our Puma servers, which keeps our RAM usage low and our response times in the milliseconds. Fastly continues to be how all the document content on DEV is served.

But while edge-caching static HTML is a well-understood problem, user-uploaded media is a completely different beast.

As DEV grew, we found ourselves drowning in images. Every post cover, user avatar, comment screenshot, and challenge banner is a high-res asset uploaded by our community. Serving billions of these images globally, while keeping page sizes lightweight, eventually led us into a silent scaling trap: a tangled, multi-CDN media pipeline, massive cloud egress fees, and eye-watering monthly bills.

Here is the story of how we ended the multi-CDN chaos, simplified our media architecture, saved a small fortune, and used edge scripting to build a smarter, faster image-serving pipeline with bunny.net.

The Chaos of Multi-CDN and the Billing Reality Check

To understand why we made the switch, you have to look at what our image pipeline used to look like.

For a long time, our media stack was a bit of a patchwork. We had different CDNs handling different parts of the platform, an image proxying service for dynamic resizing, and raw assets sitting in cloud storage (like AWS S3).

When a user uploads a 10MB JPEG as an article cover, our Rails app doesn't pre-process it into dozens of different dimensions. Instead, we rely on on-the-fly image transformation. In theory, this is great: the browser requests image.jpg?width=800, and a dynamic image optimizer resizes it, converts it to WebP or AVIF, and serves it.

In practice, the economics and mechanics of this setup at scale are brutal, especially when you factor in the realities of modern web traffic:

The Scraper & Traffic Tax: On the open web, you aren't just serving human users. You are constantly being hit by RSS readers, search crawlers, and high-frequency scrapers. Traditional setups simply weren't smart enough to handle this gracefully. A wave of aggressive scrapers requesting un-cached variations or bypassing standard query parameters would force our pipeline to repeatedly re-fetch and re-process assets, sending computing costs into the stratosphere.
Egress Fees: Every single time an image optimizer had to fetch a raw image from our cloud storage origin because of a cache miss (often induced by the traffic patterns mentioned above), we paid steep cloud egress fees.
Transformation Pricing: Many premium image CDNs charge "per thousand images processed" or utilize complex, punitive usage tiers. When you have millions of active posts and users scrolling feeds with hundreds of custom-sized avatars, those transformation counts skyrocket.
Multi-CDN Friction: Running separate providers for HTML caching and image delivery/optimization created massive operational overhead. We had complex header configurations, CORS issues, and routing rules scattered across different YAML files and dashboards.

Our media bills were ballooning, it was incredibly expensive, and we were spending way too much time debugging why our pipeline wasn't smart enough to handle volatile traffic spikes smoothly. We needed a solution that was fast, reliable, highly configurable, and above all, economically sustainable.

Why We Hopped Over to bunny.net

I’ve actually been using bunny.net for years across many of my personal projects. Whether spinning up a quick side application or testing out a new concept, I always found myself returning to it because it is an incredibly well-designed platform with sensible, intuitive products. It lacks the dense, enterprise bloat of traditional cloud vendors; instead, it provides clean developer ergonomics that just work. Because of that first-hand experience, I knew it was a platform we could trust to scale seamlessly with DEV.

What really sold us for Forem wasn't just the raw bandwidth savings (though slashing our bandwidth bills to a fraction of what premium enterprise CDNs charge was a massive win). It was how beautifully their product ecosystem handled our specific architectural pain points through the combination of Bunny Optimizer and Edge Scripting.

1. Bunny Optimizer and Perma-Cache

Bunny Optimizer acts as a fully managed, dynamic image transformation API. We could easily plug it in, append simple URL query parameters (like ?width=600&height=300&crop=1:1), and let Optimizer handle the resizing, cropping, and automatic compression on-the-fly. It automatically negotiates next-gen formats like WebP or AVIF based on the browser's Accept headers, reducing file sizes by up to 80% without any visible quality loss.

But the real magic ingredient—and our ultimate weapon against scraper traffic—is Perma-Cache.

Normally, when a CDN edge server evicts an infrequently accessed image variant, the next request has to go all the way back to the origin (our cloud storage) to fetch and re-optimize it, triggering more egress fees. Perma-Cache solves this by permanently replicating the optimized image variants to Bunny Storage.

Once an image is processed once, it is stored at the edge forever. It never has to hit our AWS origin again, shielding our backend from erratic traffic and virtually eliminated our cloud storage egress fees overnight.

2. Edge Scripting: TypeScript-Native Control

While Bunny Optimizer gave us the raw power to resize images, we needed fine-grained control over how we served them. We didn't want to pollute our Rails views with complicated URL-building logic, and we wanted to prevent users (or bots) from downloading massive raw images.

This is where Edge Scripting came in.

Built on Deno and V8, Edge Scripting runs JavaScript and TypeScript directly at the edge, allowing us to write lightweight, type-safe middleware that executes in milliseconds. It completely replaced the need for custom image proxies or complex Rails controller routing.

Under the Hood: Forem’s Pluggable Images::Optimizer Service

If you look into Forem's codebase, you’ll see that we’ve always designed our image pipeline to be pluggable. We didn't want to hardcode our views to use a specific CDN's query parameters. If a template wants to render a post cover image, it calls a unified helper that delegates to our Images::Optimizer service:

# app/views/layouts/application.html.erb
<%= Images::Optimizer.call(Settings::General.favicon_url, width: 32) %>

Inside app/services/images/optimizer.rb, we use a simple strategy pattern. The Optimizer class acts as a router that maps standardized parameters (like width, height, fit, gravity) to the specific URL format required by the active CDN provider.

Historically, Forem has supported providers like Fastly, Cloudflare, and Cloudinary and adding bunny.net was incredibly straightforward. Here is a look at how our Rails service handles this multi-CDN routing:

# app/services/images/optimizer.rb
module Images
  class Optimizer
    def self.call(url, options = {})
      return url if url.blank?

      # Select the provider strategy based on our environment configuration
      case provider
      when :bunny
        BunnyProvider.call(url, options)
      when :cloudflare
        CloudflareProvider.call(url, options)
      when :fastly
        FastlyProvider.call(url, options)
      else
        url
      end
    end

    def self.provider
      ENV.fetch("IMAGE_OPTIMIZATION_PROVIDER", "bunny").to_sym
    end
  end
end

Each provider implements its own URL rewriting strategy. For example, our bunny.net provider simply builds standard query strings that Bunny Optimizer parses:

# app/services/images/bunny_provider.rb
module Images
  class BunnyProvider
    def self.call(url, options = {})
      uri = URI.parse(url)
      query_params = []
      query_params << "width=#{options[:width]}" if options[:width]
      query_params << "height=#{options[:height]}" if options[:height]
      query_params << "crop=#{options[:crop]}" if options[:crop]
      query_params << "auto=format"

      uri.query = [uri.query, query_params.join("&")].compact.join("&")
      uri.to_s
    end
  end
end

This decoupled architecture is fantastic for an open-source project like Forem. Different self-hosted communities can configure their own CDN of choice by simply changing the IMAGE_OPTIMIZATION_PROVIDER environment variable.

However, while the Rails app generates these optimized URLs, we ran into an interesting operational challenge: what happens when a template forgets to pass a width parameter, or a legacy post contains raw external URLs?

If we relied only on Rails-side URL building, any fallback or unparsed URL would still trigger a heavy, unoptimized image load. This is where our Edge Scripting strategy stepped in—to act as a global safety net right at the network boundary.

Deep Highlight: Smart Downsizing at the Edge

With Edge Scripting, we can intercept image requests right at the CDN layer and apply custom business logic before the request even reaches the optimizer or storage.

For example, we wanted to ensure that user profile avatars and feed thumbnails are never served larger than they actually need to be, regardless of what the original upload was or what query parameters were requested. If a client requests a raw, un-optimized avatar URL, our edge script automatically intercepts it, checks the context, and rewrites the request to enforce a strict maximum width and apply WebP compression.

Here's a simplified example

// A lightweight middleware script running on bunny.net's Edge
export default async function handleRequest(request: Request) {
  const url = new URL(request.url);

  // Intercept requests to our user-uploaded uploads path
  if (url.pathname.startsWith('/uploads/')) {
    const isAvatar = url.pathname.includes('/avatars/');
    const isThumbnail = url.pathname.includes('/thumbnails/');

    // Check if the request already has optimization parameters
    const hasWidth = url.searchParams.has('width');

    if (isAvatar && !hasWidth) {
      // Dedicatedly downsize all avatar requests to a max of 150px
      url.searchParams.set('width', '150');
      url.searchParams.set('height', '150');
      url.searchParams.set('crop', '1:1');
    } else if (isThumbnail && !hasWidth) {
      // Enforce a strict mobile-friendly limit on thumbnails
      url.searchParams.set('width', '400');
    }

    // Ensure automatic next-gen format negotiation (WebP/AVIF) is active
    url.searchParams.set('auto', 'format');

    // Fetch the optimized asset from bunny.net's CDN pipeline
    return fetch(url.toString(), request);
  }

  return fetch(request);
}

This is incredibly powerful because it offloads the "computational thinking" of image delivery entirely to the edge. Our Rails application doesn't have to keep track of responsive image breakpoints or generate heavy, complex markup. We just request the logical asset URL, and our edge script dynamically handles the rest based on client headers and context.

Even better, we’ve integrated this into our standard development workflows. We use GitHub Actions combined with fine-grained personal access tokens to manage and deploy these edge scripts automatically. When we want to adjust our optimization rules or add support for a new layout—like optimizing billboard images or adjusting resolutions on challenge pages—we just push a commit, our CI runs, and the new edge logic is live globally in seconds.

Graceful Failures: Smart Fallbacks Over Plain Broken Images

Beyond routing and sizing, running code at the edge unlocked a massive UX victory: the ability to handle missing or broken assets gracefully.

In a massive community ecosystem, edge cases happen. A user might delete an external image they linked to, an old upload path might break during a migration, or a malformed request could slide through. Traditionally, when an image fails to load or returns a 404/500, the browser drops a jarring, ugly "broken image" icon that disrupts the layout and makes the entire site look broken.

With Edge Scripting, we can catch these failures mid-flight. If our origin or storage returns an error status code, the edge script intercepts the response and seamlessly rewrites it to serve a beautifully styled, custom placeholder image that says "Image not available" or matches our UI theme.

Instead of writing complex, heavy JavaScript event listeners (onError) into every single <img> tag across the Rails application, we handle it natively at the network layer. The application layer never has to think about fallback logic, and our users get a consistent, unbroken visual experience no matter what happens behind the scenes.

Future considerations

Stabilizing and optimizing our image pipeline was just phase one. As we look ahead to how DEV and Forem will continue to evolve, video is the next logical horizon.

Video delivery is notoriously complex—requiring adaptive bitrate streaming (HLS/DASH), multi-resolution transcoding, specialized storage, and optimized video players. In legacy architectures, this usually means spinning up another fragmented set of expensive third-party video processors and complex integrations.

Given our success with their media infrastructure, bunny.net is our definitive first choice for how we are thinking about video moving forward. Their unified platform approach extends directly into video streaming with products that match the same sensible, developer-first philosophy as their image optimizer. Because we can trust their infrastructure to scale predictably without predatory data transfer costs, expanding our edge architecture to handle next-generation rich media feels like a natural progression rather than a daunting infrastructure overhaul.

Final Thoughts

As developers, we often focus on optimizing our database queries, refactoring Ruby code, or fine-tuning our server configurations. But sometimes, the biggest wins are sitting right there in your network tab.

Egress fees and bloated media delivery are a silent tax on growing platforms. By moving to an edge-native, developer-friendly platform like bunny.net, we were able to simplify our architecture, speed up our page loads, and save a lot of money in the process.

If you’re running a media-heavy platform or building open-source community software like Forem, do yourself a favor: look closely at your CDN bills, check your cloud storage egress, and see if you can offload some of that weight to a platform built to grow with you. Your budget (and your users) will thank you.

Happy coding ❤️

Meme Monday

Ben Halpern — Mon, 15 Jun 2026 12:10:18 +0000

Meme Monday!

Today's cover image comes from the last thread.

DEV is an inclusive space! Humor in poor taste will be downvoted by mods.

Meme Monday

Ben Halpern — Mon, 08 Jun 2026 12:39:59 +0000

Meme Monday!

Today's cover image comes from the last thread.

DEV is an inclusive space! Humor in poor taste will be downvoted by mods.

Every tool seems to have a coding agent horned in these days..... I don't think that makes sense.

Ben Halpern — Wed, 03 Jun 2026 13:46:51 +0000

Meme Monday

Ben Halpern — Mon, 01 Jun 2026 13:28:02 +0000

Meme Monday!

Today's cover image comes from the last thread.

DEV is an inclusive space! Humor in poor taste will be downvoted by mods.

This is great, taking an oldie-but-goodie and rethinking it

Ben Halpern — Wed, 27 May 2026 16:54:47 +0000

GitHub “Finish-Up-A-Thon” Challenge Submission

Divyesh

May 27

Reviving a 12K+ Star Abandoned Library: toastr-next v3 🍞

#devchallenge #githubchallenge #typescript #opensource

6 min read

Meme Monday

Ben Halpern — Mon, 25 May 2026 13:40:05 +0000

Meme Monday!

Today's cover image comes from the last thread.

DEV is an inclusive space! Humor in poor taste will be downvoted by mods.

How we're using Gemini Embeddings to build a smarter, community-driven feed on DEV

Ben Halpern — Fri, 22 May 2026 16:27:19 +0000

Big improvements incoming 👋

Finding the right balance for a feed algorithm is historically really hard. If you optimize purely for clicks and comments, you end up with a clickbait echo chamber. But if you just sort by recency, it's a firehose where great discussions disappear in hours.

We've wrestled with this tension at DEV for a long time. We want a feed that feels alive, but actually surfaces high-quality, intellectually stimulating stuff.

So, we're trying something new. We are combining standard community signals—like who you follow and what you react to—with Gemini Embeddings 2 and pgvector.

Here is a look under the hood at how we are putting this together.

1. Keeping things flexible and auditable

Instead of duct-taping API calls all over the codebase, we built a flexible foundation using wrapper classes, mostly centered around Ai::Base and Ai::Embedding.

When a service needs the API, it just passes wrapper: self to the client. This lets Ai::Base look at the calling object, grab its class name, and check its VERSION.

Ai::Base.new(wrapper: self)

This pattern gives us a really clean audit trail via our AiAudit model. Every single time we generate a vector or analyze a trend, we automatically log the model used, the caller's class, payloads, latency, and token counts.

It makes debugging and tracking costs so much easier, without muddying up our core business logic.

2. A more personalized feed

Our main feed is powered by FeedConfig. It compiles custom SQL to score and rank articles for you.

Historically, this was all hardcoded math based on things like tags and whether you follow the author. Now, we've introduced a semantic feedback loop.

As you interact with the platform, we compile a dynamic interest_embedding that represents what you actually care about. We use the pgvector extension in PostgreSQL to inject your interests directly into the SQL query:

(
  CASE
    WHEN articles.semantic_embedding IS NOT NULL
      AND articles.published_at >= :published_since
    THEN (1 - (articles.semantic_embedding <=> :interest_embedding)) * :semantic_similarity_weight
    ELSE 0
  END
)

By using 1 - (embedding <=> user_interest), we get a cosine similarity score. We scale that up and mix it in with standard social signals (like who you follow), post quality, and time decay.

This means a highly relevant post can rise to the top of your feed, but so can a globally trending post from a community member you love. It’s all about balance.

3. What the heck is an embedding anyway? (And why v2 matters)

If you're new to the concept, an embedding is basically taking a piece of content—like an article text—and turning it into a long string of numbers (a vector). These numbers map the content into a "semantic space." If two posts are talking about the exact same conceptual ideas, their numbers will look very similar mathematically, even if they use completely different wording.

We've upgraded this pipeline to use Google's newly released Gemini Embeddings 2 model.

A standard text embedding model only looks at words. But Gemini Embeddings 2 compiles into massive 3,072-dimensional vectors and maps everything into a single, unified semantic space.

Future-proofing for a multi-modal DEV

The coolest part about moving to Embeddings 2 is that it isn't just restricted to text. It natively accepts multimodal inputs—meaning text, code, images, audio, and video.

Right now, we're using it to analyze written DEV posts. But because the underlying math maps everything into the exact same vector space, we are completely future-proofing our infrastructure. As the DEV platform evolves, we can easily feed images, podcast audio, or video posts into the exact same database architecture[.

A user's interest_embedding will be able to effortlessly surface an open-source video tutorial or a technical podcast episode based entirely on conceptual relevance, without us needing to rewrite our feed logic from scratch.

4. Catching nuanced trends 📈

Tags are great for high-level sorting, but they miss the highly specific, timely conversations. If Ruby 3.4 drops, a #ruby tag search won't distinguish between a "Hello World" tutorial and a deep debate about the new parser.

To fix this, we are in the process of building a clustering service powered by TrendDetector.

Every 6 hours, a background job runs a Leader Clustering algorithm in pure Ruby:

Quality first: We only look at recent articles scoring at least 15 points above our homepage minimum.
Clustering: We measure the cosine distance between articles. If a post is close enough (0.15 or less) to an existing cluster, it joins it. If not, it starts a new one.
Labeling: Once a cluster hits 10 or more articles, we ask the Gemini API to label the trend and summarize the core debate.

We store all of this in TrendMembership, which lets us sort articles in the UI based on how close they are to the core topic.

All of this can be tracked via our open source codebase Forem:

forem / forem

For empowering community 🌱

Forem 🌱

For Empowering Community

Welcome to the Forem codebase, the platform that powers dev.to. We are so excited to have you. With your help, we can build out Forem’s usability, scalability, and stability to better serve our communities.

What is Forem?

Forem is open source software for building communities. Communities for your peers, customers, fanbases, families, friends, and any other time and space where people need to come together to be part of a collective See our announcement post for a high-level overview of what Forem is.

dev.to (or just DEV) is hosted by Forem. It is a community of software developers who write articles, take part in discussions, and build their professional profiles. We value supportive and constructive dialogue in the pursuit of great code and career growth for all members. The ecosystem spans from beginner to advanced developers, and all are welcome to find their place…

View on GitHub

5. Putting the community first ❤️

Human curation, both from the broader community and our editorial perspective, is still the backbone of the system.

We are using Gemini Embeddings to amplify what the community is already doing. It’s about mixing the raw utility of vector search with the human spirit of developer-voted scores and relationships.

We want DEV to be the best place on the internet to share code and talk about software. We think this is a big step in that direction.

What do you think? Let me know in the comments.

Happy coding!

Pretty normal

Ben Halpern — Thu, 21 May 2026 14:30:16 +0000

Staying updated as unpaid homework

Harsh

May 21

I Used to Get Excited About New Tools Now I Feel Tired.

#ai #mentalhealth #programming #career

5 min read

Definitely looking forward to using Antigravity 2.0

Ben Halpern — Tue, 19 May 2026 17:27:33 +0000

Meme Monday

Ben Halpern — Mon, 18 May 2026 12:47:35 +0000

Meme Monday!

Today's cover image comes from the last thread.

DEV is an inclusive space! Humor in poor taste will be downvoted by mods.