RPC in Modern Web Development: Why We're Going Back to Roots

For years, the debate has been centered around REST vs. GraphQL. But in 2026, we're seeing a significant shift toward something much older: RPC (Remote Procedure Call).

If you're working with modern tools like Supabase, serverless functions, or complex B2B systems, RPC is likely the tool you've been looking for without even knowing it.

What Exactly is RPC?

Simple explained: RPC lets you call a function on another machine (the server) as if it were local to your own machine (the client).

Instead of thinking in "resources" (REST) or "graphs" (GraphQL), you think in actions. You don't say "PATCH /users/123", you say "Call the function archive_user(123)".

Why is it Relevant Now?

There are three main reasons why RPC has become indispensable in modern web architecture:

1. Atomicity and Complex Actions

Imagine an invitation in a B2B system. You need to:

1. Check if seats are available (billing).
2. Create an invitation row.
3. Send an email.
4. Log the action in an audit log.

If you do this via REST from the frontend, you risk a "race condition" where things fail halfway through. With RPC, you wrap all logic into a single atomic database function. Either everything happens, or nothing does.

2. Security and "Security Definers"

With tools like Supabase, you can run RPC functions as a SECURITY DEFINER. This means the function runs with higher privileges than the normal user, but only within the strictly defined scope of the function.

CREATE FUNCTION accept_invitation(invite_token TEXT)
RETURNS void
LANGUAGE plpgsql
SECURITY DEFINER
SET search_path = ''  -- CRITICAL: Prevents privilege escalation
AS $$
BEGIN
  -- Only this function can update the invitations table
  UPDATE public.invitations 
  SET accepted_at = NOW()
  WHERE token = invite_token;
END;
$$;
 
-- Remove direct write access
REVOKE UPDATE ON invitations FROM authenticated;

Security Warning: Without SET search_path = '', an attacker can create malicious functions in the public schema that mask legitimate functions. This is a critical vulnerability in SECURITY DEFINER functions.

This removes the need to give the frontend access to sensitive tables via RLS (Row Level Security), as only the function has the necessary access.

3. Performance and Developer Experience

In 2026, we're tired of "over-fetching." But we're also tired of the complexity of GraphQL's caching. RPC gives you the best of both worlds:

• Precise Data: You return exactly what the function needs.
• Type Safety: With TypeScript and tools like Supabase-js, you get autocompletion on your database functions directly in your code.

When to Use Which?

Conclusion

RPC isn't a replacement for REST or GraphQL, but it's the missing link in many modern backends. By moving your most critical business logic into well-defined functions on the server (or directly in the database), you make your app more secure, faster, and much easier to maintain.