[Series 2: Leveraging BaaS] Serverless vs. BaaS? End the Debate with an “Embedded Compute” Strategy

Have you ever felt frustrated because building every piece of logic with Serverless (FaaS) made your architecture feel too fragmented? Or conversely, have you felt trapped using a Backend as a Service (BaaS) because you couldn't find a clean way to implement complex business logic?

Viewing BaaS and Serverless as an "A vs. B" rivalry often hinders our understanding of modern backend design. Today’s BaaS has evolved far beyond simple data storage; it has internalized the Compute layer—traditionally the domain of Serverless.

The question is no longer "Which one should I use?" but rather "Where do I draw the line between built-in BaaS features and external compute?"

‍

1. BaaS is Already Embracing Serverless

Modern BaaS platforms provide more than just a state layer (DB, Auth, Storage). They now offer a compute layer to execute custom logic natively.

• SkyReve BaaS: Allows writing and managing functions directly via UI using Python syntax.
• Supabase: Offers Edge Functions (TypeScript) deployed across a global edge network.
• Firebase: Operates event-driven Cloud Functions.
• Appwrite / Nhost: Support workflow processing through Functions and Serverless Functions, respectively.
• AWS Amplify: Handles complex customization via Lambda-based Functions.

We can now redefine the architectural stack into three distinct tiers:

1. BaaS (State/Policy): DB, Auth, Storage, and access control (RLS, ACL, etc.).
2. Embedded Compute (In-platform Serverless): Functions, webhooks, and internal event handlers.
3. External Serverless (Extended Compute): External resources (like AWS Lambda) used when built-in functions hit their limits.

Core Principle:
"Keep the State in BaaS and handle the Rules with Compute. Always prioritize Embedded Compute before reaching for external tools."

‍

2. Clearing the Confusion: Realtime vs. Events

When working with BaaS, developers often confuse "Realtime Data Updates" with "Server-side Logic Execution." They serve entirely different purposes.

By distinguishing between "Realtime Sync" and "Server-side Event Execution (Functions)," you can significantly reduce communication overhead within your team.

‍

3. Debunking the Myth: "Who Updates the DB?”

In a BaaS environment, the default approach is for the client to update the BaaS database directly. Thinking that "Serverless must write to the DB on behalf of the client" often adds unnecessary complexity.

If a Compute function needs to write to the DB, it shouldn’t be because the DB is "inaccessible" to the client, but because of Trust and Integrity.

• The Myth: "All DB writes must go through a Serverless function to be secure."
• The Reality (1): Standard CRUD should be handled directly by the BaaS using security policies (like RLS).
• The Reality (2): Compute should only intervene for updates based on verified inputs (e.g., a payment webhook), tasks requiring Service Role permissions, or complex domain rules.

‍

4. The Trade-offs of Embedded Compute

While prioritizing built-in features is best, you must be aware of the technical trade-offs:

1. Cold Start Issues: While Edge Functions are generally fast, embedded functions using complex runtimes (e.g., calling heavy libraries like ‘sharp’ for image processing) may experience latency on the first call.
2. Vendor Lock-in: The more you rely on platform-specific functions (e.g., Supabase Edge Functions), the harder it becomes to migrate to another platform later.
3. Resource Constraints: Most built-in functions impose strict limits on execution time (timeouts) and memory allocation.

‍

5. Practical Guide: Choosing Between Embedded vs. External vs. Hybrid

In a BaaS-centric design, the goal is to use Embedded Compute as the default and External Serverless as an expansion option.

Pattern A: All-in on Embedded Compute (Speed + Simplicity)

Characteristics: Requires low latency, short execution time, and fits within platform constraints.

• Example 1 (Payment Webhooks): Receiving a signal from Stripe and immediately updating a user's "paid" status using a Service Role.
• Example 2 (Post-signup Processing): Automatically creating a profile record or saving default settings immediately after a user joins.
• Example 3 (API Proxy): Hiding API keys and transforming data formats before sending them to the client.

Pattern B: Offloading to External Serverless (High Performance)

Characteristics: Long-running tasks, high CPU/Memory usage, or native OS dependencies.

• Example 1 (Heavy Media Processing): Encoding large videos or merging hundreds of PDFs. These tasks often exceed BaaS timeout limits.
• Example 2 (Legacy/VPC Integration): Securely accessing a legacy database or internal corporate system located within a private VPC.

Pattern C: The Hybrid Approach (Orchestration + Worker)

Characteristics: The embedded function acts as the "Orchestrator" (validation/triggering), while the external serverless acts as the "Worker" (heavy lifting).

Real-world Workflow:

1. Client: User clicks "Generate Report."
2. BaaS Embedded Compute (Orchestrator): Validates the request, creates a record in the ‘reports’ table with ‘status=pending’, and issues a ‘job_id’ to the External Worker. It immediately returns a ‘200 OK’ to the client.
3. External Serverless (Worker): Fetches data using the ‘job_id’, performs heavy PDF generation, and uploads the result to BaaS Storage. It then updates the DB record to ‘status=done’ with the ‘result_url’.
4. Client: Detects the ‘status=done’ change via Realtime sync and enables the download button.

‍

Pro-tips & Alternatives:
1) Callback Pattern: While the Worker usually records the done status, you might encounter security constraints where granting DB write access to an external worker is difficult. In such cases, have the Worker send a callback (webhook) to the BaaS Embedded Compute, letting the internal function handle the final status update.
2) External Storage: Depending on file size, cost-efficiency, or data retention policies, you may choose to upload Worker-generated files to external object storage (like AWS S3) instead of the built-in BaaS Storage.

‍

Use the Overlap to Your Advantage

BaaS and Serverless are not competing technologies. In fact, the current trend is BaaS absorbing Serverless to become a more powerful, unified platform.

The most practical architectural advice is this:"Start Small, Scale Smart."

Don't struggle to build a massive external infrastructure from day one. Entrust your State to BaaS and start your Rules with Embedded Compute. When your service grows and hits the limits of those built-in features—that is the perfect time to scale outward.

‍