function.do vs. AWS Lambda: Why Radical Simplicity Matters in Serverless

The serverless paradigm, championed by giants like AWS Lambda, promised a revolution: run code without thinking about servers. It delivered on that promise, fundamentally changing how we build applications. But as with any powerful technology, a new layer of complexity emerged. We traded server provisioning for IAM roles, VPC configurations, and endless YAML files.

The core idea of serverless is brilliant, but the execution can often feel like death by a thousand paper cuts. You spend more time wrangling infrastructure-as-code than writing your actual business logic.

What if we could reclaim the original promise? What if serverless could be... simple?

This is the core philosophy behind function.do. It's not just another Function as a Service (FaaS) platform; it's a re-imagining of the developer experience, built on a foundation of radical simplicity. Let's compare the journey of deploying a function on AWS Lambda versus function.do.

The Lambda Journey: The "Building Blocks" Approach

AWS Lambda is an incredibly powerful and flexible tool. It gives you the "building blocks" to construct almost any backend imaginable. But with great power comes great responsibility—and a significant amount of configuration.

To create a simple, public-facing API with Lambda, your checklist looks something like this:

1. Write the Function: You write your logic in a specific handler format.
2. Define IAM Role: Create an IAM role with the correct permissions for your function to execute and access other AWS services.
3. Configure API Gateway: Set up an API Gateway, create a resource (e.g., /greeting), add a method (e.g., POST), and configure the integration request to pass data to your Lambda.
4. Set up Permissions: Grant API Gateway permission to invoke your Lambda function.
5. Manage Dependencies: Package your code and dependencies into a ZIP file or container image. For more complex setups, you might need to manage Lambda Layers.
6. Deploy: Upload your code and configure environment variables, memory allocation, and timeout settings.
7. Test and Debug: Use CloudWatch Logs to troubleshoot invocation errors or permission issues.

The actual code you wanted to write is a tiny fraction of this process. The rest is infrastructure management.

The function.do Philosophy: Deploy Functions. Get APIs.

function.do takes a different approach. We believe that if your goal is to expose a piece of logic as an API, that should be the only thing you have to do.

Here’s that same "get a greeting" API, built on function.do:

import { Do, Fn } from '@do-are/sdk';

/**
 * @description Generates a personalized greeting.
 * @param { name: string } - The name to include in the greeting.
 * @returns { message: string } - The personalized greeting message.
 */
export const getGreeting: Fn = async ({ name }) => {
  if (!name) {
    throw new Error('A name is required to generate a greeting.');
  }

  const message = `Hello, ${name}! Welcome to the platform.`;

  // This object is returned as the JSON API response.
  return { message };
};

// Deploying this creates a unique API endpoint:
// POST https://your-name.function.do/getGreeting
// BODY { "name": "World" }

You write this code, you deploy it, and you're done. That's it. The platform instantly generates a secure, scalable, and documented API for you. There is zero boilerplate and zero infrastructure to manage.

Notice what's missing?

• No IAM roles to configure.
• No API Gateway to provision.
• No handler boilerplate.
• No ZIP files to create.

You focus purely on the logic. We handle the rest.

Atomic and Composable: A Better Way to Build

This radical simplicity is enabled by two core concepts: atomic functions and composability.

What is an Atomic Function?

An atomic function is a small, self-contained unit of code designed to perform one specific task perfectly. On the function.do platform, each function you export from a file becomes its own dedicated, scalable API endpoint. This enforces a clean, microservices-style architecture by design.

The benefits are immense:

• Simplicity: Each function is easy to understand, test, and debug.
• Isolation: A failure or bug in one function doesn't bring down your entire system.
• Scalability: Each endpoint scales independently based on its specific load.

Are These Functions Composable?

Absolutely. Simplicity at the function level doesn't limit the complexity of what you can build. In fact, it enhances it. You can build sophisticated workflows by having your composable functions call each other.

Since every function is a standard HTTP API endpoint, you can orchestrate them using our SDK or any standard HTTP client. This allows you to build complex systems from simple, reusable, and independently scalable parts.

create-user can call send-welcome-email. process-payment can call generate-invoice and update-subscription-status. Each part remains simple, but together they form a powerful whole.

Feature-by-Feature: function.do vs. AWS Lambda

The Right Tool for the Job

AWS Lambda is a foundational piece of the cloud, and it's not going anywhere. It’s the right choice when you need granular control over every aspect of the execution environment.

But for the vast majority of use cases—where the goal is to get your logic running behind a secure, scalable API as quickly as possible—there's a better way.

function.do isn't designed to replace Lambda; it's designed to elevate the developer experience. It’s for developers who want to move faster, eliminate undifferentiated heavy lifting, and focus on what truly matters: creating value.

Stop building boilerplate. Start building features.

Try function.do today and turn your code into a live API in minutes.