Scalable Solutions

Serverless Frontend Showdown: Why We Picked AWS Amplify (and When to Consider Cloudflare)

Jainam Shah — Wed, 09 Jul 2025 14:46:01 GMT

I was unexpectedly called into a meeting with my manager, tech lead, and the cloud team to decide on a frontend deployment strategy for a new project. As a recent graduate, I needed to quickly research and recommend a solution. We evaluated offerings from AWS, Google Cloud, and other providers. In consultation with the cloud team, we decided to test AWS Amplify, a fully-managed frontend hosting service.

AWS Amplify: Global Frontend Hosting with CI/CD

AWS Amplify is designed to deploy web frameworks globally with minimal setup. It supports major JavaScript frameworks (React, Angular, Vue, Next.js, Nuxt, etc.) and popular static-site generators (Gatsby, Hugo, Jekyll, etc.). Amplify uses the Amazon CloudFront CDN under the hood, giving global distribution and low latency for user requests.

Most importantly, Amplify ties directly into Git: once you connect a repository, Amplify automatically builds and deploys each commit, handling build scripts, CDN invalidations, and SSL certificates without extra configuration. Features like zero-configuration Next.js or Nuxt deployments mean we can push new features to high-traffic web applications in just a few clicks.

In practice, setting up Amplify was straightforward. I simply linked our GitHub repo to an Amplify app, defined the build command, and Amplify did the rest. This “full-stack deployment environment” really is serverless - no servers to choose or configure. Under the hood Amplify runs on AWS services (CodePipeline/CodeDeploy for CI/CD, S3 for storage, and CloudFront for CDN) but presents them as a single platform.

One nice bonus is cost: Amplify’s pricing is pay-as-you-go with no long-term contracts. The generous free tier (12 months of 1,000 build minutes, 5 GB storage, 15 GB serving, etc. per month) often means small projects cost effectively $0/month. For example, you can host an Amplify app for absolutely $0 if traffic is low.

In short, Amplify gave us a managed, low-overhead frontend CI/CD pipeline, global CDN distribution, and pricing that scales with usage.

Server-Based vs. Serverless Deployment

Before Amplify, we might have hosted the app on an EC2 or similar server. With a traditional server-based setup, we would pay a fixed price for each server instance (even when idle) and manually configure scaling and caching (e.g. setting up autoscaling groups and CloudFront distributions ourselves).

In contrast, Amplify is serverless: there are no persistent servers to manage, and AWS automatically handles scalability and caching. Amplify (like S3+CloudFront) is a serverless service; it requires less maintenance and management than self-hosted servers. We essentially relinquished control of infrastructure in exchange for ease-of-use.

Key differences include:

Cost model: EC2 servers cost a fixed hourly rate, whereas Amplify charges only for actual build time, storage, and data transferred.
Scaling: With EC2, you set up autoscaling manually, while Amplify (via CloudFront) scales automatically across AWS’s global network.
Maintenance: EC2 requires OS and runtime updates. Amplify is fully managed - AWS provisions SSL and server infrastructure, so our team can focus on code.

Using Amplify eliminated many ops tasks. We found that for a frontend (mostly static assets and pre-built code), the serverless approach was ideal - it avoided paying for idle capacity and handled CDN and TLS out of the box.

Frontend vs. Backend: Serverless Trade-offs

In general, serverless architectures (like Amplify, AWS Lambda, Cloudflare Workers, etc.) bring automatic scaling and cost-per-use. The main drawback is usually cold-start latency - backend functions may pause when idle and take time to spin up. For high-traffic or real-time backend APIs, that can be a concern.

However, frontend hosting is different - we are mostly serving static files (HTML/CSS/JS) which do not incur cold starts. Serverless frontends eliminate the overhead of provisioning servers and scaling.

Benefits include:

Lower Costs: Pay only for build and bandwidth you use.
Automatic Scaling: The CDN and edge network handle traffic spikes with no config.
Ease of Deployment: Pushing to Git triggers deployments immediately.
Reduced Latency: Serving from the nearest edge location cuts round-trip time.

The trade-offs (vendor lock-in, limited infra control) are less impactful for frontends. Notably, Cloudflare Workers eliminates cold starts by running code in V8 isolates everywhere. In short, “throwing the webpage code to the browser” from a global CDN sidesteps almost all the classic serverless cons - making serverless a no-brainer for frontends.

Exploring Frontend Deployment Platforms

Today, many platforms offer easy serverless frontend hosting. Some of the major ones include:

Firebase Hosting (Google Cloud)

Production-grade hosting with a global CDN. A single CLI command deploys your web app to edge servers. Optimized for static and SPA apps, with built-in SSL and caching. Can pair with Cloud Functions or Cloud Run.

Vercel

Built by the creators of Next.js, Vercel is a popular choice for frontend developers, especially with React/Next.js. It offers seamless Git integration, instant deploy previews, and built-in support for serverless edge functions.

Netlify

A JAMstack platform that automates builds and global deployment. Connects to Git repos, runs your build settings, and deploys to a CDN. Includes built-in functions (serverless backend), form handling, and identity services.

AWS Amplify

As discussed, Amplify offers managed frontend hosting with Git-based CI/CD, CloudFront CDN, and framework support. Ideal if your stack already uses AWS.

Cloudflare Pages & Workers

An edge-first deployment platform. Cloudflare Pages offers Git-driven JAMstack hosting. Cloudflare Workers adds dynamic logic at the edge. The free tier is generous - unlimited sites, 500 builds/month, and 100k Worker requests/day.

Each option has its strengths. For instance:

Firebase’s Google Cloud integration
Vercel’s deep Next.js support
Netlify’s JAMstack features
Cloudflare’s speed and pricing

We chose Amplify for its AWS alignment, but for personal projects, I found Cloudflare’s simplicity very appealing.

Why Cloudflare Became My Go-To Choice

While I have no major complaints about any one provider, Cloudflare stood out for my own use. Its edge network and pricing won me over. My personal site and small projects now run on Cloudflare Pages/Workers.

Here's why:

Global Edge Performance: Cloudflare Workers consistently respond quicker than AWS Lambda@Edge, thanks to 200+ Points of Presence and direct V8 engine execution. Cold starts are virtually eliminated.
Generous Free Tier: Pages allows unlimited free bandwidth and sites. Workers includes 100k requests/day and 10ms CPU time per request.
Built-In Security & DNS: Free SSL certificates, DDoS protection, and the fastest DNS resolver (1.1.1.1) are all included.
Easy Workflow: GitHub/GitLab integration means a quick push deploys to the edge. It also offers pull-request previews and built-in analytics.
Cost Savings: Friends at a startup reported major savings after migrating their services to Cloudflare Workers and Pages - no idle server fees, no egress charges.

In short, Cloudflare gave me everything I needed: performance, reliability, and low cost. I no longer worry about downtime or scaling - the edge network handles it.

Conclusion

In this case study, I evaluated several modern frontend hosting options and ultimately used a two-pronged approach:

AWS Amplify for our company project
Cloudflare for personal projects

Amplify’s Git-based CI/CD and AWS ecosystem made it a great choice for team use. Cloudflare’s edge performance, free tier, and developer-friendly workflow won out for my own needs.

Both choices show how far serverless frontend hosting has come: we now get global delivery, instant deployment, and cost-per-use billing - without managing a single server.

Atomic and Low-Level Design in Flutter: Crafting Scalable UI Components

Jainam Shah — Thu, 29 May 2025 17:15:57 GMT

Introduction

Flutter enables us to create very expressive UI easily. But for building a quality app contains many different components like Design systems, file structure, naming conventions, and many low level system design concepts. This article will particularly be about how we created both simple yet efficient component library using atomic design methodology and low level system design principles.

Understanding Atomic Design Methodology

Atomic Design, introduced by Brad Frost, structures UI components into five levels:

Atoms — Atoms are the fundamental UI elements (e.g., Buttons, Labels, Icons, Input Fields)
Molecules — Groups of atoms forming a molecule (e.g., Search Bar, Labelled input fields)
Organisms — Combinations of molecule forming distinct UI sections (e.g., Navbars)
Templates — Layouts defining content structure (e.g., Row, 2 Column Layout, Grid)
Pages — Fully assembled UI screen

Understanding Low Level System Design

Encapsulation — Manages Its own state and behaviour
Reusability — Reusable across entire application
Scalability — Should support multiple variations and allow future extensions seamlessly

Implementing a Scalable Button Component

For this article, we will focus on creating the atomic button. Buttons are simple to experiment with, easy to explain, and serve as a fundamental component that effectively demonstrates the implementation.

Let’s start with creating design tokens

Assuming all theme properties are applied using Flutter’s theme engine, we create tokens for button sizes. Many design systems, such as Material and Human Interface Design, define standard button heights. In our project, we follow SMRL (Small, Medium, Regular, Large) conventions:

Create a mappings for this sizes:

static const Mapdouble> _buttonHeights = {
    ButtonSize.small: 36.0,
    ButtonSize.medium: 44.0,
    ButtonSize.regular: 52.0,
    ButtonSize.large: 60.0,
  };

This static map ensures that if we ever need to add more height parameters we can just add parameters to Enum and static map. This makes the component scalable to new variations easy.

Defining the button style

Majorly the button style remains fix UI wide, and this is just our primary button. We are using 4 types of button in our design system, Primary, Secondary, Tertiary and Textual Button more about them later. Just using the flutter theme engine to simplify lots of complexity here:

ButtonStyle getButtonStyle(BuildContext context) {
    return FilledButton.styleFrom(
      minimumSize: Size.fromHeight(buttonHeight),
      shape: RoundedRectangleBorder(borderRadius: BorderRadius.circular(8.0)),
      textStyle: Theme.of(context).textTheme.labelLarge,
    );
  }

This consists of 4 parameters which user can define:

final VoidCallback? onPressed;
final String label;
final Widget? icon;
final ButtonSize size;

In out design system we are utilising 4 material buttons (Filled, Elevated, Textual, Outlined). In primary button we are using the filled button. So as per the variables defined lets look at the build method of the widget.

Widget build(BuildContext context) {
    return icon == null
        ? FilledButton(
            onPressed: onPressed,
            style: getButtonStyle(context),
            child: Text(label),
          )
        : FilledButton.icon(
            onPressed: onPressed,
            style: getButtonStyle(context),
            label: Text(label),
            icon: icon!,
          );
  }

Here as we can see that if icon is null than the normal FilledButton will be rendered else the FilledButton.icon widget will be rendered.

Also the style is being fetched from the styles we created earlier. As you can observe this makes the code of widget itself seemingly very light and seperate from any other clutter.

Final Component

Now lets look at the full code of the widget, As I mentioned earlier we are using 4 material button components, This is our Primary Button Widget.

import 'package:flutter/material.dart';

/// Defines button sizes
enum ButtonSize { small, regular, medium, large }

/// Defines a primary button with configurable size and icon
class PrimaryButton extends StatelessWidget {
  final VoidCallback? onPressed;
  final String label;
  final Widget? icon;
  final ButtonSize size;

  const PrimaryButton({
    Key? key,
    required this.onPressed,
    required this.label,
    this.icon,
    this.size = ButtonSize.regular,
  }) : super(key: key);

  /// Predefined button heights
  static const Mapdouble> _buttonHeights = {
    ButtonSize.small: 36.0,
    ButtonSize.medium: 44.0,
    ButtonSize.regular: 52.0,
    ButtonSize.large: 60.0,
  };

  /// Retrieves button height
  double get buttonHeight => _buttonHeights[size] ?? 44.0;

  /// Retrieves button style
  ButtonStyle getButtonStyle(BuildContext context) {
    return FilledButton.styleFrom(
      minimumSize: Size.fromHeight(buttonHeight),
      shape: RoundedRectangleBorder(borderRadius: BorderRadius.circular(8.0)),
      textStyle: Theme.of(context).textTheme.labelLarge,
    );
  }

  @override
  Widget build(BuildContext context) {
    return icon == null
        ? FilledButton(
          onPressed: onPressed,
          style: getButtonStyle(context),
          child: Text(label),
        )
        : FilledButton.icon(
          onPressed: onPressed,
          style: getButtonStyle(context),
          label: Text(label),
          icon: icon!,
        );
  }
}

This button is being used application wide. It follow the low level design and Solid principle concepts:

Encapsulation — both the height and style guide is abstracted and developer don't need to bother about it.

Reusable — It is used all over screens in the application. the height can be customised as per need.

Scalability — It is scalable as it has multiple height support, styles can be pretty much same UI wide, and the labels and onpressed activity is handled outside of the component that give developer flexibility to customise the click action as per his need.

It follows the atomic guideline quite well:

Atom: PrimaryButton is a fundamental UI component.

Reusable: Works across multiple UI sections and screens.

Final Note

Using this methods, we were able to create a pretty good component library of our design system which follows practices around the Low Level Design and Atomic Design methodology. This makes any new developer onboarding easier, Faster development as don't need to focus on minor details like sizes and properties, and quality of components greatly enhanced as it is already created and quality tested. This improves overall Quality of life of the developer.

Here, attaching some references which inspired and helped us to create this library: