Meet email_guard, a Trusted Language Extension (TLE) for PostgreSQL. It works well with Supabase Auth hooks to:

• Block disposable email domains with a big, auto-updated list.
• Normalize Gmail addresses to stop duplicate signups (by removing dots and +tags).
• Offer easy installation that fits in any schema.

When you use this with Supabase's own security tools, like leaked password protection, you build strong protection against bad signups and abuse.

Why You Need email_guard for Supabase Authentication Security

The Problem: Disposable Emails and Gmail Tricks

Disposable email services (like mailinator.com or guerrillamail.com) let anyone make short-term emails. These are good for tests, but often used to:

• Make spam or bot accounts.
• Skip limits on trials or rates.
• Avoid bans by making new accounts fast.

Gmail addressing quirks are tricky too. These all go to the same inbox:

• john.doe@gmail.com
• j.o.h.n.d.o.e@gmail.com
• johndoe+promo@gmail.com
• johndoe+whatever@gmail.com

Without fixing this, a user can make many accounts by adding dots or +tags. This breaks rules for one account per person and can cheat referral programs or trials.

The Solution: Smart Email Validation at Signup in Supabase

The email_guard TLE gives you:

1. A blocklist for disposable domains with over 20,000 known ones (updated weekly).
2. Gmail normalization that removes dots and +tags, and sets the domain to gmail.com.
3. A helper for Supabase Auth hooks that checks before creating a user.

All this runs in PostgreSQL, so it is fast, safe, and clear. For more on Supabase auth, see the Supabase Auth docs.

Understanding Trusted Language Extensions (TLE) in Supabase

Before installation, let's quickly explain what a Trusted Language Extension is and why it helps.

What is a TLE?

A Trusted Language Extension (TLE) is a PostgreSQL add-on written in a safe language (like PL/pgSQL or PL/Python). You can install it without special admin rights. This is key for hosted setups like Supabase, where you lack full access.

TLEs come from database.dev, the package manager for PostgreSQL. This makes them:

• Easy to install with the Supabase CLI.
• Version-controlled for safe updates.
• Flexible to place in any schema.
• Safe for production.

Learn more in Supabase's Trusted Language Extensions for Postgres blog post or the extensions docs.

Why Use TLEs for Security in Supabase?

With security logic in a TLE:

• It runs in the database, near your data.
• It stays the same for all apps and calls.
• You can check it with version history.
• It cannot be skipped by app code.

This is great for auth checks, data rules, and policies.

Step 1: Installing the TLE Infrastructure on Supabase

Before adding email_guard, set up the pg_tle extension (already on Supabase) and the dbdev tool for easy install.

A. Set Up dbdev and Supabase CLI (If Needed)

If not done yet:

1. Install dbdev CLI: Follow the dbdev getting started guide.
2. Install Supabase CLI: Check the Supabase CLI docs.
3. Link your project: Run supabase link to connect to your Supabase database.

Supabase has pg_tle ready, so create it:

CREATE EXTENSION IF NOT EXISTS pg_tle;

B. Generate the Migration with dbdev

Use dbdev to get the latest email_guard (version 0.3.1 or newer) in your migrations:

dbdev add \
  -o ./supabase/migrations/ \
  -v 0.3.1 \
  -s extensions \
  package \
  -n mansueli@email_guard

What this does:

• Makes a new migration file in ./supabase/migrations/.
• Puts the extension in the extensions schema (good for Supabase).
• Uses version 0.3.1 (change for new versions).

Adjust the -o path if your folder is different.

C. Apply the Migration

Push to your Supabase database:

supabase db push

Done! The extension is installed with the full blocklist.

For more on managing extensions, see Supabase database extensions docs.

Step 2: Understanding What You Just Installed

The email_guard extension adds objects in your schema (like extensions):

Table: disposable_email_domains

-- Holds over 20,000 disposable email domains
CREATE TABLE extensions.disposable_email_domains (
  domain text PRIMARY KEY,
  CONSTRAINT disposable_email_domains_domain_lowercase
    CHECK (domain = lower(domain))
);

It fills with domains like:

• mailinator.com
• guerrillamail.com
• 10minutemail.com
• And many more.

Function: normalize_email(text)

-- Example: normalize_email('J.o.h.n.Doe+promo@gmail.com')
-- Returns: 'johndoe@gmail.com'
SELECT extensions.normalize_email('J.o.h.n.Doe+promo@gmail.com');

What it does:

• Makes lowercase.
• For Gmail/Googlemail:
  • Removes dots from the start.
  • Cuts after + (and the +).
  • Sets domain to gmail.com.
• For others: Just lowercase.

Function: is_disposable_email_domain(text)

-- Check if a domain is disposable
SELECT extensions.is_disposable_email_domain('mailinator.com'); -- true
SELECT extensions.is_disposable_email_domain('gmail.com');      -- false

Smart check:

• Looks at parent domains (e.g., sub.mailinator.com matches).
• Fast with index.

Function: is_disposable_email(text)

-- Easy check for full emails
SELECT extensions.is_disposable_email('user@guerrillamail.com'); -- true

Hook Helper: hook_prevent_disposable_and_enforce_gmail_uniqueness(jsonb)

This is the key part! For Supabase Auth hooks, it:

1. Checks disposable domains → Sends 403 error if yes.
2. Normalizes Gmail → Checks if the same normalized email exists.
3. Sends 409 error if duplicate.
4. Allows phone signups or non-email.

Step 3: Wire Up the Supabase Auth Hook for Email Validation

Now, connect it to signups.

Navigate to Auth Hooks in Dashboard

1. Go to your Supabase Dashboard.
2. Pick your project.
3. Go to Authentication → Hooks.
4. Turn on Before User Created.

Configure the Hook

Pick:

• Hook Type: Postgres Function.
• Schema: extensions (or your choice).
• Function: hook_prevent_disposable_and_enforce_gmail_uniqueness.

Done! The hook is on. See Supabase Auth Hooks docs for details.

What Happens During Signup

When signing up, the hook checks first:

// Try with disposable email
supabase.auth.signUp({
  email: 'test@mailinator.com',
  password: 'secure_password_123'
})
// ❌ Error: { message: "Disposable email addresses are not allowed", status: 403 }

// Try with duplicate Gmail
// If johndoe@gmail.com exists
supabase.auth.signUp({
  email: 'j.o.h.n.d.o.e+test@gmail.com',
  password: 'secure_password_123'
})
// ❌ Error: { message: "A user with this normalized email already exists", status: 409 }

// Valid email
supabase.auth.signUp({
  email: 'alice@example.com',
  password: 'secure_password_123'
})
// ✅ User created

Step 4: Testing Your email_guard Setup on Supabase

Check if it works.

Test 1: Check Disposable Email Detection

-- True
SELECT extensions.is_disposable_email('user@mailinator.com');

// False
SELECT extensions.is_disposable_email('user@gmail.com');

Test 2: Test Gmail Normalization

-- All return 'johndoe@gmail.com'
SELECT extensions.normalize_email('John.Doe@gmail.com');
SELECT extensions.normalize_email('j.o.h.n.d.o.e@googlemail.com');
SELECT extensions.normalize_email('johndoe+promo@gmail.com');

Test 3: Simulate the Hook

-- Disposable reject
SELECT extensions.hook_prevent_disposable_and_enforce_gmail_uniqueness(
  '{"user": {"email": "test@guerrillamail.com"}}'::jsonb
);
-- Error: "Disposable email addresses are not allowed"

// Gmail duplicate (after adding test user)
SELECT extensions.hook_prevent_disposable_and_enforce_gmail_uniqueness(
  '{"user": {"email": "j.o.h.n.d.o.e+test@gmail.com"}}'::jsonb
);
-- Error: "A user with this normalized email already exists"

Step 5: Combining with Supabase's Built-in Protections

email_guard is stronger with Supabase features.

Leaked Password Protection

Supabase checks against HaveIBeenPwned. Turn it on in Dashboard → Authentication → Password Protection.

// Leaked password
supabase.auth.signUp({
  email: 'alice@example.com',
  password: 'password123'  // Leaked
})
// ❌ Error: { message: "Password has been leaked", status: 422 }

Keeping the Blocklist Current in email_guard

email_guard updates itself.

How Updates Work

A GitHub workflow:

1. Runs every week (Mondays).
2. Gets new list from disposable-email-domains repo.
3. Makes upgrade script if changed.
4. Updates version (e.g., 0.3.1 to 0.3.2).
5. Saves changes auto.

Upgrading to the Latest Version

For new version:

# Make upgrade migration
dbdev add \
  -o ./supabase/migrations/ \
  -v 0.3.2 \  # New
  -s extensions \
  package \
  -n mansueli@email_guard

# Apply
supabase db push

It adds new domains and keeps data. Watch releases on GitHub repo.

Advanced Usage & Customization for Supabase email_guard

Custom Domain Blocking

Block extra domains:

-- Add one
INSERT INTO extensions.disposable_email_domains (domain)
VALUES ('suspicious-domain.com')
ON CONFLICT DO NOTHING;

-- Remove one
DELETE FROM extensions.disposable_email_domains
WHERE domain = 'some-domain.com';

Checking Existing Users

Audit users:

-- Find disposable
SELECT id, email
FROM auth.users
WHERE extensions.is_disposable_email(email);

-- Find Gmail duplicates
WITH normalized AS (
  SELECT 
    id,
    email,
    extensions.normalize_email(email) AS normalized_email
  FROM auth.users
  WHERE email ILIKE '%@gmail.com'
     OR email ILIKE '%@googlemail.com'
)
SELECT 
  normalized_email,
  array_agg(email) AS duplicate_emails,
  count(*) AS duplicate_count
FROM normalized
GROUP BY normalized_email
HAVING count(*) > 1;

Custom Hook Logic

Make your own hook:

CREATE OR REPLACE FUNCTION public.my_custom_signup_hook(event jsonb)
RETURNS jsonb
LANGUAGE plpgsql
AS $$
DECLARE
  user_email text;
BEGIN
  user_email := event->'user'->>'email';

  IF extensions.is_disposable_email(user_email) THEN
    RAISE EXCEPTION 'Nice try! No disposable emails here.'
      USING HINT = 'Please use a permanent email address',
            ERRCODE = 'P0001';
  END IF;

  -- Add custom rules

  RETURN event;
END;
$$;

Performance Considerations for email_guard in Supabase

Benchmarking

Functions are fast:

-- Domain check: ~0.1ms
SELECT extensions.is_disposable_email_domain('mailinator.com');

-- Normalize: ~0.05ms
SELECT extensions.normalize_email('j.o.h.n.d.o.e+test@gmail.com');

-- Full hook: ~1-2ms

Index Optimization

Extension adds index on auth.users(email). For big databases:

-- Partial index for Gmail
CREATE INDEX IF NOT EXISTS users_gmail_normalized_idx 
ON auth.users (extensions.normalize_email(email))
WHERE email ILIKE '%@gmail.com' OR email ILIKE '%@googlemail.com';

Troubleshooting email_guard on Supabase

Hook Not Triggering

Check setup:

SELECT * FROM supabase_functions.hooks
WHERE hook_name = 'before_user_created';

Check rights:

GRANT EXECUTE ON FUNCTION extensions.hook_prevent_disposable_and_enforce_gmail_uniqueness(jsonb)
TO supabase_auth_admin;

False Positives

If wrong block:

DELETE FROM extensions.disposable_email_domains
WHERE domain = 'legitimate-domain.com';

Report to blocklist repo.

Migration Conflicts

Use different schema:

dbdev add \
  -o ./supabase/migrations/ \
  -v 0.3.1 \
  -s email_guard \
  package \
  -n mansueli@email_guard

Update hook to email_guard.hook_prevent_disposable_and_enforce_gmail_uniqueness.

Security Best Practices for Supabase Authentication

Defense in Depth

Add layers:

1. Verify emails: Make users confirm.
2. CAPTCHA: Use hCaptcha on forms.
3. Rate limits: Stop many tries per IP.
4. Review accounts: Flag odd patterns.

Monitoring

Track blocks:

CREATE TABLE IF NOT EXISTS blocked_signups (
  id uuid DEFAULT gen_random_uuid() PRIMARY KEY,
  email text NOT NULL,
  reason text NOT NULL,
  created_at timestamptz DEFAULT now()
);

-- Log in hook (add yourself)

Privacy Considerations

• Avoid logging full emails.
• Hash data for stats.
• Follow GDPR/CCPA for stored info.

Conclusion: Building a Secure Foundation with email_guard on Supabase

Authentication is the door to your app. Secure it with layers. The email_guard TLE gives a simple way to block disposable emails and stop Gmail duplicates in Supabase.

With Supabase tools like leaked password checks, email verification, and rate limits, you get a strong system that:

• ✅ Blocks bad signups auto.
• ✅ Stops abuse without work.
• ✅ Grows with your app.
• ✅ Updates weekly.

It runs in the database, so it is clear, checked, and hard to skip.

Next Steps

1. Install the extension as shown.
2. Turn on the auth hook in dashboard.
3. Test with disposable and Gmail tests.
4. Watch logs for blocks.
5. Update when new versions come.

For more, see:

• email_guard GitHub repository
• Supabase Auth Hooks documentation
• Trusted Language Extensions blog post
• database.dev package registry

Check my previous posts: Building User Authentication with Username and Password Using Supabase and Streamlining PostgreSQL Function Management with Supabase.

In this post, you will learn a simple pattern with Supabase, PostgreSQL, and KSUID (via the pg_idkit extension). By the end, you get SQL code to add to your database. You also get workflows to create, check, and list API keys. This setup is optimized for Supabase users, with tips on the Supabase CLI and JavaScript client. It helps with secure API key management in Supabase.

For more on secrets in Supabase, see previous posts on Supabase Vault. If you work with PostgreSQL extensions, check out Trusted Language Extensions for Postgres which is used on this blog post.

Overview: A Simple Way to Manage API Keys

We make API keys that look like this:

[KSUID][SECRET]

• The KSUID is a short ID that sorts by time. We use it as the row ID.
• The SECRET is a random string shown once to the user.
• In the database, we store:
  • The KSUID (as id),
  • A salted hash of the secret,
  • A random salt,
  • The last 4 characters for the dashboard,
  • The client_id (UUID) to link to a Supabase user (see Supabase Auth docs),
  • And a name for the key label.

To check a key: Split it into KSUID and secret. Find the row by KSUID (fast with index). Compute the hash and compare. This is quick: one lookup and one hash.

This method keeps your Supabase API key management secure and efficient.

Step 1: Install pg_idkit Extension with dbdev and Supabase CLI

The pg_idkit extension gives KSUID functions like gen_random_ksuid_microsecond(). We install it as a Trusted Language Extension (TLE) using dbdev CLI to generate a migration. Then, use Supabase CLI to apply it. This fits well with Supabase workflows for installing PostgreSQL extensions in Supabase.

A. Set Up dbdev and Supabase CLI

If you do not have dbdev CLI, install it. Follow the dbdev installation docs. For Supabase CLI, see the Supabase CLI docs. Link your local project to your Supabase database.

Note: On Supabase, the pg_tle extension is already installed. This meets the prerequisite.

B. Generate Migration File with dbdev

Run this command to create a migration file for pg_idkit version 0.0.4 in the extensions schema:

dbdev add -o "./supabase/migrations/" -v 0.0.4 -s extensions package -n kiwicopple@pg_idkit

• This makes a SQL file in your migrations folder.
• Adjust the path if your migrations folder is different.

For more details, see the dbdev install a package docs.

C. Apply the Migration with Supabase CLI

Push the migration to your Supabase database:

supabase db push

This applies the extension. Now you can use functions like:

SELECT gen_random_ksuid_microsecond();

For more on extensions, see Supabase Database Extensions docs.

Step 2: Set Up the Table Schema

Use this SQL in your Supabase SQL editor or a migration file. It creates the api_keys table with KSUID as the primary key.

CREATE EXTENSION IF NOT EXISTS pgcrypto;

CREATE TABLE api_keys (
  id TEXT PRIMARY KEY DEFAULT gen_random_ksuid_microsecond(), -- KSUID as ID (27 chars)
  client_id UUID NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
  name TEXT NOT NULL,                    -- user label
  secret_hash BYTEA NOT NULL,            -- digest(secret || salt)
  salt BYTEA NOT NULL DEFAULT gen_random_bytes(16), -- auto salt
  last4 TEXT NOT NULL,                   -- last 4 chars of secret for UI
  created_at TIMESTAMPTZ DEFAULT now()
);
-- Index for fast per-user listing, ordered by KSUID (time-sortable)
CREATE INDEX api_keys_client_id_idx ON api_keys (client_id, id DESC);

Notes:

• KSUIDs sort by time and are 27 characters long.
• We link to auth.users for Supabase auth.
• Use the Supabase CLI to push this as a migration: supabase migration new create_api_keys_table, add the SQL, then supabase db push.

Step 3: Create an API Key Server-Side

This function creates a key. It takes client_id and name, generates everything, and returns the full key once.

Add this in a migration or SQL editor:

CREATE OR REPLACE FUNCTION create_api_key(client_id UUID, key_name TEXT)
RETURNS TEXT AS $$
DECLARE
  ksuid_prefix TEXT := gen_random_ksuid_microsecond();
  secret TEXT := encode(gen_random_bytes(16), 'base32'); -- random secret
  salt_val BYTEA := gen_random_bytes(16);
  full_key TEXT := ksuid_prefix || secret;
BEGIN
  INSERT INTO api_keys (id, client_id, name, secret_hash, salt, last4)
  VALUES (
    ksuid_prefix,
    client_id,
    key_name,
    digest(secret || salt_val, 'sha256'),
    salt_val,
    right(secret, 4)
  );
  RETURN full_key; -- show this to the user once
END;
$$ LANGUAGE plpgsql;

The database makes the secret. Show it once in your app.

Step 4: Verify API Keys with Supabase Edge Functions

To check keys, use a Supabase Edge Function. This is fast and secure. Create one with the Supabase CLI:

supabase functions new verify-api-key

Edit functions/verify-api-key/index.ts with Supabase JS:

import { createClient } from 'https://esm.sh/@supabase/supabase-js@2';

const supabase = createClient(Deno.env.get('SUPABASE_URL')!, Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!);

Deno.serve(async (req) => {
  const { full_key } = await req.json();
  const { data, error } = await supabase.rpc('verify_api_key', { full_key });

  if (error || !data) {
    return new Response(JSON.stringify({ error: 'Invalid key' }), { status: 401 });
  }

  return new Response(JSON.stringify({ client_id: data }), { status: 200 });
});

Deploy it: supabase functions deploy verify-api-key.

The verify_api_key function (add to DB):

CREATE OR REPLACE FUNCTION verify_api_key(full_key TEXT)
RETURNS UUID AS $$
DECLARE
  ksuid_prefix TEXT := left(full_key, 27);
  secret TEXT := substr(full_key, 28);
  stored_hash BYTEA;
  stored_salt BYTEA;
  key_owner UUID;
BEGIN
  SELECT secret_hash, salt, client_id
  INTO stored_hash, stored_salt, key_owner
  FROM api_keys
  WHERE id = ksuid_prefix;

  IF NOT FOUND THEN
    RETURN NULL;
  END IF;

  IF digest(secret || stored_salt, 'sha256') = stored_hash THEN
    RETURN key_owner; -- valid: return owner id
  ELSE
    RETURN NULL;       -- invalid
  END IF;
END;
$$ LANGUAGE plpgsql;

This is efficient: one index lookup and one hash. See Supabase Functions docs for more.

Step 5: List Keys for Your Dashboard

This function lists keys, sorted by time.

CREATE OR REPLACE FUNCTION list_api_keys(
  client_id UUID,
  limit_count INT DEFAULT 50,
  offset_count INT DEFAULT 0
)
RETURNS TABLE(id TEXT, name TEXT, last4 TEXT, created_at TIMESTAMPTZ) AS $$
BEGIN
  RETURN QUERY
  SELECT id, name, last4, created_at
  FROM api_keys
  WHERE client_id = list_api_keys.client_id
  ORDER BY id DESC
  LIMIT limit_count OFFSET offset_count;
END;
$$ LANGUAGE plpgsql;

Call it from your app with Supabase JS:

const { data, error } = await supabase.rpc('list_api_keys', { client_id: user.id });

How Your App Uses These in Supabase

Create a Key

• App calls: const { data } = await supabase.rpc('create_api_key', { client_id: user.id, key_name: 'My Key' });
• Show data once to the user.

Verify a Key

• Send full_key to your Edge Function.
• If it returns client_id, allow access.

List Keys

• Use the list function in your dashboard.

Additional Notes on Security and Choices

• You cannot get back secrets. This is safer.
• Add revocation: Include revoked_at in the table and check in verify_api_key.
• For rate limits, log usage after verify succeeds.

This setup makes secure API key management in Supabase simple and fast.

Ready to try? Start with the Supabase CLI and build your own.

Why BrainFuck? Why Not?

PostgreSQL has long been celebrated for its extensibility. So why stick with conventional languages like SQL, PL/pgSQL, or even Python when you can support something as esoteric as BrainFuck? With its minimalist syntax (just 8 commands) and unparalleled debugging experience where every error is considered a feature, BrainFuck offers:

• Minimalist syntax: Finally, a language where SELECT * is far too verbose.
• Unparalleled debugging experience: Errors in BrainFuck keep you on your toes—every mistake is practically an art form.
• Legacy compatibility: Perfect for those rare moments when you need to integrate with systems dating back to the era of teleprinters.

Introducing the brainfuck() Function

The crown jewel of SupaBrain is the brainfuck(code text, input text) function, which lets you execute BrainFuck code directly within PostgreSQL using PLV8. Here’s a simple example:

SELECT brainfuck(',[.[-],]', 'Hello!');

This snippet will output "Hello!" -- right after PostgreSQL takes a brief existential pause.

The Code Behind the Magic

Below is the full implementation of the brainfuck() function:

CREATE OR REPLACE FUNCTION brainfuck(code text, input text)
 RETURNS text
 LANGUAGE plv8
 IMMUTABLE STRICT
AS $function$
  var tokens = {
    ".": "output += String.fromCharCode(tape[pointer]);",
    ",": "tape[pointer] = input.length ? input.shift().charCodeAt(0) : 0;",
    "<": "pointer = pointer ? pointer - 1 : 255;",
    ">": "pointer = (pointer + 1) % 256;",
    "-": "tape[pointer] = tape[pointer] ? tape[pointer] - 1 : 255;",
    "+": "tape[pointer] = tape[pointer] ? (tape[pointer] + 1) % 256 : 1;",
    "[": "while(tape[pointer]){",
    "]": "}"
  };
  if (!input) {
    input = "";
  }
  var inner_code = "";
  for (var i=0; i<code.length; i++){
    if (tokens[code[i]]) {
      inner_code += tokens[code[i]] + "\n";
    }
  }
  var js_code = "input = Array.from(input + '');\nvar output = '';\nvar tape = [];\nvar pointer = 0;\n" + 
    inner_code + "return output;";
  var fn = new Function("input", js_code);
  return fn(input.split(','));
$function$;

This implementation maps each BrainFuck token to a corresponding JavaScript snippet, effectively creating a bridge between BrainFuck and PostgreSQL. By compiling BrainFuck code into JavaScript, SupaBrain enables the execution of esoteric programs in your database.

Real-World "Applications"

While SupaBrain is clearly a tongue-in-cheek experiment, its potential applications are as imaginative as they are impractical:

• Query Optimization:
  Tired of instantaneous results? Implement a BrainFuck-based execution engine to slow things down. Your queries now run with the deliberation of geological time scales.

• Data Encryption (Sort of):
  Secure your data not with advanced cryptography, but with sheer unreadability. If no one can decipher your BrainFuck logic, your secrets are safe by default.

• Hiring Filter:
  Ever been frustrated by a candidate's inability to appreciate complexity? If someone voluntarily writes queries in BrainFuck, congratulations—you’ve likely found your next 10x engineer.

Performance Considerations (or Lack Thereof)

Traditional SQL queries finish in milliseconds. With BrainFuck, you’re invited to experience time in a whole new dimension.

Why do:

-- 0.1ms 
SELECT 1;

When you can:

-- 1.7 billion years
SELECT brainfuck('[-]+>[-]+>[-]+>[-]+>[-]+>[-]+<<[>>>[-]>>[-]>[-]<<<<<[>>>>+>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<[-]>>>[-]<<<<<[>>+>>>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<<[>[<<[-]+>>[-]]<[-]]>>>>[-]>[-]<<<<<<[>>>>>+>+<<<<<<-]>>>>>>[<<<<<<+>>>>>>-]>[-]+>[-]>[-]<<<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<[-]>[-]]<<<[>>>>>[-]>>[-]>[-]<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>+>+<<<<<<<<<<<<<<<-]>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>-]<<[-]>>>[-]<<<<<<<<<<<<<<<[>>>>>>>>>>>>+>>>+<<<<<<<<<<<<<<<-]>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>-]<<<[>[<<[-]+>>[-]]<[-]]>>>>[-]>[-]<<<<<<[>>>>>+>+<<<<<<-]>>>>>>[<<<<<<+>>>>>>-]>[-]+>[-]>[-]<<<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<[-]>[-]]<<<[>>>>>[-]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>[-]+>[-]+>[-]>>[-]>[-]<<<<<[>>>>+>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<[-]>>>[-]<<<<<[>>+>>>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<<[>[<<[-]+>>[-]]<[-]]>>>>[-]>[-]<<<<<<[>>>>>+>+<<<<<<-]>>>>>>[<<<<<<+>>>>>>-]>[-]+>[-]>[-]<<<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<[-]>[-]]<<<[<<<<<<<<.>>>>>>>>[-]]>>[[-]]<<<<<<<<<<<<<<<[-]]>>[[-]]>>>>[-]>>[-]>[-]<<<<<<<<<<<<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>>>>>>>>>>>+>+<<<<<<<<<<<<<<<<<<<<<<<<<<-]>>>>>>>>>>>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>-]<<[-]>>>[-]<<<<<<<<<<<<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>>>>>>>>>+>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<-]>>>>>>>>>>>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>-]<<<[>[<<[-]+>>[-]]<[-]]>>>>[-]>[-]<<<<<<[>>>>>+>+<<<<<<-]>>>>>>[<<<<<<+>>>>>>-]>[-]+>[-]>[-]<<<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<[-]>[-]]<<<[>>>>>[-]++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>[-]+>[-]+>[-]>>[-]>[-]<<<<<[>>>>+>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<[-]>>>[-]<<<<<[>>+>>>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<<[>[<<[-]+>>[-]]<[-]]>>>>[-]>[-]<<<<<<[>>>>>+>+<<<<<<-]>>>>>>[<<<<<<+>>>>>>-]>[-]+>[-]>[-]<<<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<[-]>[-]]<<<[<<<<<<<<.>>>>>>>>[-]]>>[[-]]<<<<<<<<<<<<<<<[-]]>>[[-]]>>>>[-]>>[-]>[-]<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<-]>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>-]<<[-]>>>[-]<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<-]>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>-]<<<[>[<<[-]+>>[-]]<[-]]>>>>[-]>[-]<<<<<<[>>>>>+>+<<<<<<-]>>>>>>[<<<<<<+>>>>>>-]>[-]+>[-]>[-]<<<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<[-]>[-]]<<<[>>>>>[-]++++++++++>[-]+>[-]+>[-]>>[-]>[-]<<<<<[>>>>+>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<[-]>>>[-]<<<<<[>>+>>>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<<[>[<<[-]+>>[-]]<[-]]>>>>[-]>[-]<<<<<<[>>>>>+>+<<<<<<-]>>>>>>[<<<<<<+>>>>>>-]>[-]+>[-]>[-]<<<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<[-]>[-]]<<<[<<<<<<<<.>>>>>>>>[-]]>>[[-]]<<<<<<<<<<<<<<<[-]]>>[[-]]<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<[-]]>>[[-]]<<<<<<<<[-]+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>[-]+>[-]>>[-]>[-]<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<-]>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>-]<<[-]>>>[-]<<<<<[>>+>>>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<<[>[<<[-]+>>[-]]<[-]]<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<[-]>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>[-]<<<<<[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<]
, '');

The performance trade-off is clear: if you desire to truly savor the passage of time, SupaBrain’s execution will ensure that every moment counts. And don’t worry about scalability—if anything, it scales logarithmically… downwards.

Installation: Making PostgreSQL Regret Its Flexibility

Before proceeding, ensure you have the following installed:

• PLV8: Required for running JavaScript code within PostgreSQL.
• Database.dev: Provides access to the PostgreSQL package manager and trusted language extensions (TLE).

Installing the Trusted Language Extension (TLE)

If you don't have the TLE installed already, follow these steps:

-- Install TLE if not already installed
create extension if not exists http with schema extensions;
create extension if not exists pg_tle;
drop extension if exists "supabase-dbdev";
select pgtle.uninstall_extension_if_exists('supabase-dbdev');
select
    pgtle.install_extension(
        'supabase-dbdev',
        resp.contents ->> 'version',
        'PostgreSQL package manager',
        resp.contents ->> 'sql'
    )
from http(
    (
        'GET',
        'https://api.database.dev/rest/v1/'
        || 'package_versions?select=sql,version'
        || '&package_name=eq.supabase-dbdev'
        || '&order=version.desc'
        || '&limit=1',
        array[
            ('apiKey', 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InhtdXB0cHBsZnZpaWZyYndtbXR2Iiwicm9sZSI6ImFub24iLCJpYXQiOjE2ODAxMDczNzIsImV4cCI6MTk5NTY4MzM3Mn0.z2CN0mvO2No8wSi46Gw59DFGCTJrzM0AQKsu_5k134s')::http_header
        ],
        null,
        null
    )
) x,
lateral (
    select
        ((row_to_json(x) -> 'content') #>> '{}')::json -> 0
) resp(contents);
create extension "supabase-dbdev";
select dbdev.install('supabase-dbdev');
drop extension if exists "supabase-dbdev";
create extension "supabase-dbdev";

Installing the BrainFuck TLE

Once the TLE is in place, install the BrainFuck extension:

-- Install the BrainFuck extension using the database package manager
SELECT dbdev.install('mansueli@brainfuck');
CREATE EXTENSION "mansueli@brainfuck"
    SCHEMA public -- You can change it here to something else
    VERSION '4.2.0';

⚠️ Warning: Installing this extension may void your database's warranty.

Example Function Using BrainFuck

Here’s an example that uses the BrainFuck TLE to format a date:

CREATE OR REPLACE FUNCTION public.format_date(input_date timestamp with time zone)
RETURNS text
LANGUAGE plpgsql
IMMUTABLE STRICT
AS $function$
BEGIN
return brainfuck(',>,>,>,>,>,>,<<,>>>,>,>>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]<<<<<<<<<<[-]>>>>>>>>>>>[-]++++++++++[-<<<<<<<<<<<++++++++++>>>>>>>>>>>]<<<<<<<<<<[-]>>>>>>>>>>>[-]++++++++++[-<<<<<<<<<<<++++++++++>>>>>>>>>>>]<<<<<<<<<<[-]>>>>>>>>>>>[-]++++[-<<<<<<<<<<<++++++++++>>>>>>>>>>>]<<<<<<<<<<<+++++++>[-]>>>>>>>>>>>[-]++++++++++[-<<<<<<<<<<<++++++++++>>>>>>>>>>>]<<<<<<<<<<<+++++++++>[-]>>>>>>>>>>>[-]++++++++++[-<<<<<<<<<<<++++++++++>>>>>>>>>>>]<<<<<<<<<<<+++++++++>[-]>>>>>>>>>>>[-]++++[-<<<<<<<<<<<++++++++++>>>>>>>>>>>]<<<<<<<<<<<+++++++>[-]>>>>>>>>>>>[-]++++++++++++[-<<<<<<<<<<<++++++++++>>>>>>>>>>>]<<<<<<<<<<<+>[-]>>>>>>>>>>>[-]++++++++++++[-<<<<<<<<<<<++++++++++>>>>>>>>>>>]<<<<<<<<<<<+>[-]>>>>>>>>>>>[-]++++++++++++[-<<<<<<<<<<<++++++++++>>>>>>>>>>>]<<<<<<<<<<<+>[-]>>>>>>>>>>>[-]++++++++++++[-<<<<<<<<<<<++++++++++>>>>>>>>>>>]<<<<<<<<<<<+>[-]>[-]>[-][-]<<<<<<<<<<<<<<<<.>.>>>>>>>>>>>>>>[-][-]>>[-]++++[-<<++++++++++>>]<<+++++++.<<<<<<<<<<<<<<<<<.>.>>>>>>>>>>>>>>>>[-][-]>>[-]++++[-<<++++++++++>>]<<+++++++.<<<<<<<<<<<<<<<<<<<<<<.>.>.>.>>>>>>>>>>>>>>>>>>>>[.>]',input_date::text);
END;
$function$

The Future of SupaBrain

The journey of SupaBrain has just begun. Some exciting ideas for future enhancements include:

• AI-Powered Code Generation:
  Imagine a world where ChatGPT refuses to generate BrainFuck code—simply citing ethical concerns. The irony isn’t lost on us.

• Multi-threaded BrainFuck Execution:
  While PostgreSQL isn’t ready for it yet, we dream of a day when BrainFuck can run concurrently across multiple threads.

• BrainFuck ORM:
  Stay tuned for our BrainFuck Object-Relational Mapping tool. It’s coming soon—just as soon as we figure out how to map tables to tape memory.

Conclusion: The Feature You Never Knew You Didn’t Need

SupaBrain transforms your database experience into something frustratingly unique. Whether it’s for a quirky hiring filter, or simply to prove that just because you can, doesn’t mean you should, SupaBrain has a place in every developer’s toolkit. So, why not give it a try? Or don’t—we promise not to judge.

Happy coding (or decoding)!

We're always looking for ways to improve the developer experience and reduce complexity across your application development pipeline. One way you can use Supabase to do that is with dynamic JavaScript in Edge Functions. This greatly increases the versatility of your edge functions and reduces the need for you to redeploy your functions if you need to change business logic.

Introduction to Edge Functions

Edge Functions in Supabase are serverless functions that execute in response to HTTP requests. These functions are deployed at the edge, meaning they run close to the user's location, resulting in faster response times.

Why Use Dynamic Code Execution?

Dynamic code execution allows you to modify and run JavaScript code on the fly without having to redeploy your function each time the code changes. This is particularly useful when you need the flexibility to execute different logic depending on the incoming request, without incurring the overhead of redeployment.

Prerequisites

To follow along, you will need:

• A Supabase project
• Supabase CLI installed on your local machine
• Orb Stack or Docker Desktop installed on your local machine
• Environment variables set up in Vault, ensuring it passes validation in the function (e.g., service_role)

Edge Functions defaults to the verification of the JWT, so it could be called with the ANON API Key. Make sure to implement proper security measures.

Install the SQL script from the repo

We have a repo with the SQL script to create helper functions to support the dynamic execution of JavaScript code. You can find the repo here: supa-dynamic

Install the SQL script supa-dynamic--0.1.sql from the repo in your Supabase project. (You can copy and paste the code from the repo into the SQL editor in your Supabase project.) These are the functions we'll use to execute the JavaScript code:

• edge.http_request(url text, method text, headers jsonb, params jsonb, payload jsonb, timeout_ms integer) RETURNS jsonb: Makes an HTTP request with the specified parameters.
• edge_wrapper(code text) RETURNS text: Executes the provided JavaScript code.
• edge.get_secret(secret_name text) RETURNS text: Retrieves a secret from Vault.

Deep Dive into the helper functions (optional)

You can skip this section if you are only interested in using the dynamic execution of JavaScript code. However, if you want to understand how the helper functions work, keep reading.

edge.http_request Function

This function handles the actual HTTP request and processes the response. It ensures consistency in response format.

CREATE OR REPLACE FUNCTION edge.http_request(
    url TEXT,
    method TEXT DEFAULT 'POST',
    headers JSONB DEFAULT '{"Content-Type": "application/json"}'::jsonb,
    params JSONB DEFAULT '{}'::jsonb,
    payload JSONB DEFAULT '{}'::jsonb,
    timeout_ms INTEGER DEFAULT 5000
) RETURNS jsonb AS $$
DECLARE
    http_response extensions.http_response;
    status_code integer := 0;
    response_json jsonb;
    response_text text;
    header_array extensions.http_header[];
    request extensions.http_request;
BEGIN
    -- Set the timeout option
    IF timeout_ms > 0 THEN
        PERFORM http_set_curlopt('CURLOPT_TIMEOUT_MS', timeout_ms::text);
    END IF;

    -- Convert headers JSONB to http_header array
    SELECT array_agg(extensions.http_header(key, value::text))
    FROM jsonb_each_text(headers)
    INTO header_array;

    -- Construct the http_request composite type
    request := ROW(method, url, header_array, 'application/json', payload::text)::extensions.http_request;

    -- Make the HTTP request
    http_response := http(request);
    status_code := http_response.status;

    -- Attempt to extract JSONB response content
    BEGIN
        response_json := http_response.content::jsonb;
    EXCEPTION
        WHEN others THEN
            response_text := http_response.content;
            response_json := jsonb_build_object('status_code', status_code, 'response', response_text);
    END;

    RETURN jsonb_build_object('status_code', status_code, 'response', response_json);
END;
$$ LANGUAGE plpgsql;

edge_wrapper Function

The edge_wrapper function manages HTTP requests with features like retries, custom headers, and region selection. Below are the parameters it accepts:

• url: The endpoint to call.
• method: HTTP method, defaulting to POST.
• headers: Custom headers to include, including region information.
• timeout_ms: Timeout duration in milliseconds.
• max_retries: Maximum retry attempts for the request.

CREATE OR REPLACE FUNCTION edge.edge_wrapper(
    url TEXT,
    method TEXT DEFAULT 'POST',
    headers JSONB DEFAULT '{"Content-Type": "application/json"}'::jsonb,
    params JSONB DEFAULT '{}'::jsonb,
    payload JSONB DEFAULT '{}'::jsonb, -- Payload as JSONB
    timeout_ms INTEGER DEFAULT 5000,
    max_retries INTEGER DEFAULT 0,
    allowed_regions TEXT[] DEFAULT NULL
) RETURNS jsonb AS $$
DECLARE
    retry_count INTEGER := 0;
    retry_delays DOUBLE PRECISION[] := ARRAY[0, 0.250, 0.500, 1.000, 2.500, 5.000];
    succeeded BOOLEAN := FALSE;
    current_region_index INTEGER := 1; -- Start index at 1 for PostgreSQL array
    combined_headers JSONB;
    response_json JSONB;
BEGIN
    -- Validate headers, params, and payload are JSON objects
    IF headers IS NULL OR NOT jsonb_typeof(headers) = 'object' THEN
        RAISE EXCEPTION 'Invalid headers parameter: %', headers;
    END IF;

    IF params IS NULL OR NOT jsonb_typeof(params) = 'object' THEN
        RAISE EXCEPTION 'Invalid params parameter: %', params;
    END IF;

    IF payload IS NULL OR NOT jsonb_typeof(payload) = 'object' THEN
        RAISE EXCEPTION 'Invalid payload parameter: %', payload;
    END IF;

    -- Validate allowed_regions if provided
    IF allowed_regions IS NOT NULL AND cardinality(allowed_regions) = 0 THEN
        RAISE EXCEPTION 'allowed_regions parameter cannot be an empty array';
    END IF;

    -- Check if retry_delays has enough elements
    IF cardinality(retry_delays) < max_retries + 1 THEN
        RAISE EXCEPTION 'retry_delays array must have at least % elements', max_retries + 1;
    END IF;

    -- Retry loop
    WHILE NOT succeeded AND retry_count <= max_retries LOOP
        combined_headers := headers;

        -- Set x-region header if allowed_regions is provided
        IF allowed_regions IS NOT NULL AND cardinality(allowed_regions) > 0 THEN
            combined_headers := combined_headers || jsonb_build_object('x-region', allowed_regions[current_region_index]);
        END IF;

        -- Sleep if not the first attempt
        IF retry_count > 0 THEN
            PERFORM pg_sleep(retry_delays[retry_count]);
        END IF;

        retry_count := retry_count + 1;

        -- Increment region index, wrapping around if necessary
        IF allowed_regions IS NOT NULL AND cardinality(allowed_regions) > 0 THEN
            current_region_index := current_region_index + 1;
            IF current_region_index > cardinality(allowed_regions) THEN
                current_region_index := 1;
            END IF;
        END IF;

        BEGIN
            RAISE WARNING 'headers:%s', combined_headers;

            -- Call the simplified HTTP request function
            response_json := edge.http_request(url, method, combined_headers, params, payload, timeout_ms);

            -- Check the status code
            IF (response_json->>'status_code')::INTEGER < 500 THEN
                succeeded := TRUE;
            END IF;
        EXCEPTION
            WHEN OTHERS THEN
                IF retry_count > max_retries THEN
                    RAISE EXCEPTION 'HTTP request failed after % retries. SQL Error: { %, % }',
                        max_retries, SQLERRM, SQLSTATE;
                END IF;
        END;
    END LOOP;

    RETURN response_json;
END;
$$ LANGUAGE plpgsql;

To securely manage secrets, you will need to set your service_role_key in Vault. Here’s how you can create a function to retrieve secrets:

CREATE OR REPLACE FUNCTION edge.get_secret(secret_name text) RETURNS text
    LANGUAGE "plpgsql"
    AS $$
DECLARE
    decrypted text;
BEGIN
    IF current_setting('request.jwt.claims', true)::jsonb->>'role' = 'service_role' OR current_user = 'postgres' THEN
        SELECT decrypted_secret
        INTO decrypted
        FROM vault.decrypted_secrets
        WHERE name = secret_name;
        RETURN decrypted;
    ELSE
        RAISE EXCEPTION 'Access denied: only service_role or postgres user can execute this function.';
    END IF;
END;
$$;

This function can retrieve the service_role secret from Vault, it also ensures that only authorized roles can access sensitive environment variables.

Setting Up the Edge Function

Let's dive into the code and set up our dynamic JavaScript executor Edge Function using Deno. Below is an overview of how to accomplish this.

Code Walkthrough

We'll create a function named multi-purpose:

supabase functions new multi-purpose

Now, we'll edit the code adding verification and the eval function, including the supabase client so we have it ready without the need to import.

import "jsr:@supabase/functions-js/edge-runtime.d.ts";

// Import the supabase client
import { createClient } from "<https://esm.sh/@supabase/supabase-js@2>";

console.log("===\\n\\tBooted Edge Worker!\\n===\\n");
const supabase_url = Deno.env.get("SUPABASE_URL") ?? "";
const service_role = Deno.env.get("SUPABASE_SERVICE_ROLE_KEY");
// Set the permission to service_role key:
const supabase = createClient(supabase_url, service_role);
// This allows us to use Supabase.ai in the function
const session = new Supabase.ai.Session('gte-small');

Deno.serve(async (req: Request) =>
  const authorization = req.headers.get("Authorization");
  if (!authorization) throw new Error("Authorization header is missing.");
  // Ensures that the function is called with service_role to prevent missuse
  if (!authorization.includes(service_role)) {
    throw new Error("Authorization header is invalid.");
  }

  const { code } = await req.json();
  try {
    // Wrap the provided code in an async function context
    const asyncFunction = new Function('supabase', `
      return (async () => {
        ${code.replace(/\\\\/g, '')}
      })();
    `);
    // Pass the Supabase client as the scope for the function to use:
    const data = await asyncFunction(supabase);
    console.log(data);
    return new Response(
      JSON.stringify({ data }),
      { headers: { 'Content-Type': 'application/json', 'Connection': 'keep-alive' } },
    );
  } catch (error) {
    console.error("Error executing user code:", error);
    return new Response(
      JSON.stringify({ error: "An error occurred -> " + error.message }),
      { status: 500, headers: { "Content-Type": "application/json" } }
    );
  }
});

Note: If you need more details, check the full guide to create an edge function.

Step-by-Step Walkthrough

1. Validate Authorization: First, we ensure the request contains a valid authorization header. (this prevents calls from anon users)

const authorization = req.headers.get('Authorization')
if (!authorization) throw new Error('Authorization header is missing.')
// Ensures that the function is called with service_role to prevent missuse
if (!authorization.includes(service_role)) {
  throw new Error('Authorization header is invalid.')
}

1. Receive JavaScript Code Payload: Extract the code from the request body.

const { code } = await req.json()

1. Wrap Code in Async Context: Use new Function() to create an async function that executes the incoming JavaScript code. This allows async calls in the code to be executed:

try {
    // Wrap the provided code in an async function context
    const asyncFunction = new Function('supabase', `
      return (async () => {
        ${code.replace(/\\\\/g, '')}
      })();
    `);
}

1. Execute and Return Results: Run the JavaScript code, which can interact with Supabase via the provided client, and return the results.

// Pass the Supabase client as the scope for the function to use:
const data = await asyncFunction(supabase)
console.log(data)
return new Response(JSON.stringify({ data }), {
  headers: { 'Content-Type': 'application/json', Connection: 'keep-alive' },
})

Deploying the Edge Function

To deploy this Edge Function, you'll need to use the Supabase CLI. Ensure you have Docker installed and running on your local machine. Follow these steps to deploy:

1. Install the Supabase CLI: If you haven't already, install the Supabase CLI by following the instructions in the Supabase CLI Documentation.
2. Log In to Supabase: Use the command supabase login to authenticate your account.
3. Deploy the Function: Run the command supabase functions deploy <function_name> to deploy your Edge Function. Replace <function_name> with the desired name for your function.

Setting Environment Variables in Vault

Creating the main function to interact with the edge function

We are using the helper functions defined earlier to create a function that interacts with the edge function. This function will execute the dynamic JavaScript code and return the results. This is the main function that will be used to execute the dynamic JavaScript code and return the results.

edge.exec Function

The edge.exec is a simple function leverages edge_wrapper to execute dynamic JavaScript code. Here's an example of how it is structured:

CREATE OR REPLACE FUNCTION edge.exec(data text) RETURNS JSONB LANGUAGE plpgsql
AS $function$
DECLARE
    custom_headers JSONB;
-- Example restricting regions available to Europe
    allowed_regions TEXT[] := ARRAY['eu-west-1', 'eu-west-2', 'eu-west-3', 'eu-north-1', 'eu-central-1'];
BEGIN
    -- Set headers with anon key and Content-Type
    custom_headers := jsonb_build_object(
        'Authorization', 'Bearer ' || edge.get_secret('service_role_key'),
        'Content-Type', 'application/json',
        'x-region', allowed_regions
    );
    -- Call edge_wrapper function with default values
    RETURN edge.edge_wrapper(
        url := ('https://<ref>.supabase.co/functions/v1/multi-purpose'),
        headers := custom_headers,
        payload := jsonb_build_object('code', data),
        max_retries := 5,
        allowed_regions := allowed_regions
    );
END;
$function$;

Executing Dynamic JavaScript Code

The key to executing the dynamic JavaScript code is wrapping it in an async function context using new Function(). This approach lets you evaluate the code in isolation while retaining access to the supabase client for interacting with your database. You can check the examples of how to use this calling the supabase client or even generating embeddings.

Example of Using Supabase Client Libraries

To demonstrate the execution of dynamic JavaScript, you can use the Supabase client libraries within the SQL context. Here’s an example query:

SELECT edge.exec(
  $js$
  const { data, error } = await supabase.rpc('postgres_function', {'foo': 'bar'});
  if (error) {
    return new Response(JSON.stringify({ error: "An error occurred ->" + error.message }), {
      status: 500,
      headers: { "Content-Type": "application/json" },
    });
  }
  return data;
  $js$
);

Using the Edge Function in Practice

Example: Generating Embeddings

The edge.exec function allows for dynamic JavaScript execution, such as interacting with an AI session to generate embeddings. When executed, the JavaScript code within the SQL context runs through the edge function, returning results to the database.

select edge.exec(
$js$

const session = new Supabase.ai.Session('gte-small');
return await session.run('hello world');

$js$);

You can also create a Postgres function to generate embeddings:

CREATE OR REPLACE FUNCTION edge.generate_embedding(input_text TEXT) RETURNS JSONB AS $$
DECLARE
    response JSONB;
BEGIN
    -- Call the edge function to generate the embedding for the provided text
    response := edge.exec(
        format(
            $js$
            const session = new Supabase.ai.Session('gte-small');
            return await session.run(%L);
            $js$,
            input_text
        )
    );
    RETURN response->'response'->'data';
END;
$$ LANGUAGE plpgsql;

 select edge.generate_embedding('The quick brown fox jumps over the lazy dog');

-- response:
-- [-0.07254139333963394,-0.02173878252506256,0.042930446565151215,0.04853367060422897,0.015609614551067352,0.02912059798836708,0.0371023565530777,0.05054798722267151,0.0035842431243509054,0.0015563230263069272,0.0009484672918915749,-0.09247169643640518,0.04190639406442642,0.05874202027916908,-0.012341015040874481,0.01661474071443081,-0.013452880084514618,0.003742767730727792,-0.07664268463850021,0.03231268376111984,0.0006968052475713193,-0.06508929282426834,-0.04956015944480896,-0.014327225275337696,0.03270547464489937,0.01635774038732052,-0.022707758471369743,-0.007586371619254351,-0.03548099845647812,-0.17844657599925995,0.03325255215167999,-0.07009242475032806,0.02982083335518837,-0.05649203434586525,-0.006693259347230196,-0.02781110256910324,-0.01687553897500038,0.04976152256131172,-0.015715090557932854,0.038247860968112946,0.040495794266462326,-0.007263457402586937,-0.019288228824734688,-0.0527581050992012,-0.0065462407656013966,-0.022786622866988182,-0.04975651577115059,-0.04053974151611328,0.03047902137041092,-0.05064946785569191,-0.023929744958877563,-0.03891737014055252,0.03785012289881706,-0.0133274607360363,0.03001898154616356,-0.007281183265149593,0.060004156082868576,0.017414024099707603,0.025516854599118233,0.029599720612168312,0.02893918938934803,0.03455337509512901,-0.14698833227157593,0.09387505799531937,0.05768263339996338,0.019130567088723183,-0.0380706787109375,-0.04105521738529205,0.008963614702224731,0.012743324972689152,0.009223062545061111,0.060711149126291275,0.007398003712296486,0.04229794815182686,0.046996768563985825,-0.003397924592718482,0.00808036606758833,0.022617157548666,-0.01847437582910061,0.0026343590579926968,-0.010598739609122276,-0.037673674523830414,-0.04375630244612694,-0.0007789010996930301,-0.007935777306556702,-0.03272915259003639,0.021433845162391663,-0.07967976480722427,0.06888656318187714,0.07489841431379318,-0.02783842757344246,-0.006374717690050602,-0.035476282238960266,0.006344574969261885,-0.03357071802020073,-0.036727335304021835,0.012309364043176174,-0.00006389369809767231,-0.053050097078084946,0.19709722697734833,-0.05575009435415268,0.05757850036025047,0.0951322615146637,-0.04633559286594391,0.03476420044898987,0.012983368709683418,0.0004390157700981945,0.010212302207946777,-0.012741461396217346,0.014706282876431942,0.03321540355682373,-0.006495281588286161,0.041682176291942596,0.003406582633033395,0.02581774815917015,-0.0007246752502396703,0.011133069172501564,0.08353550732135773,0.006477882619947195,0.00224463758058846,0.020395604893565178,-0.013416256755590439,0.05663946643471718,-0.028388522565364838,0.019082417711615562,-0.08387858420610428,0.054498571902513504,0.10694538056850433,0.06286843866109848,0.03180928900837898,0.037740662693977356,-0.07479764521121979,0.010231229476630688,-0.04866624251008034,0.004061027429997921,0.0362103171646595,-0.009540606290102005,0.00915283989161253,0.031154874712228775,-0.04876647889614105,-0.015956921502947807,-0.1429857611656189,-0.01470054779201746,-0.09399641305208206,-0.019157350063323975,0.02896934375166893,-0.018669532611966133,0.014991801232099533,-0.06764508783817291,0.027312103658914566,-0.003859955817461014,0.025718173012137413,-0.018675100058317184,-0.016409857198596,-0.021459592506289482,0.004702075384557247,-0.0323822982609272,0.10394860059022903,-0.020106177777051926,-0.008876764215528965,-0.027185838669538498,0.0003392586368136108,-0.009877108968794346,-0.0004303457390051335,0.04185814782977104,-0.05188998952507973,-0.021185973659157753,0.00026368125691078603,-0.02180171199142933,-0.03400561958551407,0.020068379119038582,0.034275852143764496,-0.10943055897951126,0.031987469643354416,0.054017845541238785,-0.009243185631930828,-0.07103140652179718,0.00785127654671669,-0.0040434580296278,-0.05036382004618645,0.07858535647392273,-0.08356015384197235,-0.06914680451154709,0.06180981919169426,0.043073058128356934,-0.020246226340532303,-0.015496478416025639,-0.005946696270257235,0.006562687456607819,0.04845070466399193,-0.029123008251190186,0.02194702997803688,0.002446065191179514,-0.06825454533100128,-0.07056894898414612,0.01598423719406128,-0.04185032472014427,-0.01633128523826599,0.014294272288680077,-0.01768324337899685,0.05590462312102318,-0.044063832610845566,0.02461099997162819,0.0006756667862646282,0.07429251074790955,0.011551265604794025,0.014212443493306637,-0.02237367257475853,0.039057254791259766,0.000325449975207448,-0.004185846075415611,-0.003040974261239171,0.01800958439707756,-0.02479490265250206,-0.019247515127062798,0.04366869106888771,-0.027130864560604095,0.018955133855342865,0.03239727392792702,0.03226468712091446,0.06487660109996796,-0.06456360220909119,0.0006639647181145847,-0.20788206160068512,0.05066373199224472,-0.012870946899056435,-0.034873317927122116,0.023824242874979973,-0.02305314689874649,0.030056791380047798,-0.06937119364738464,0.0642433762550354,0.05418730527162552,0.06050065532326698,-0.04655877873301506,-0.026898164302110672,-0.003803820814937353,0.002598312683403492,0.1081414744257927,0.014850604347884655,0.013619652017951012,0.013523285277187824,-0.0016119466163218021,-0.00329813570715487,0.002907108049839735,0.014589778147637844,-0.048919934779405594,0.056754376739263535,-0.03171522915363312,0.2308642566204071,0.08356188982725143,0.05350973457098007,-0.03191335126757622,0.003732810029760003,0.031172126531600952,-0.08899383991956711,-0.09938952326774597,0.08256369829177856,0.08178982138633728,0.07785400003194809,-0.04618730768561363,-0.02995850332081318,-0.022348755970597267,-0.05898110195994377,0.05294518917798996,0.0038859194610267878,-0.0923057422041893,-0.01576364040374756,-0.0035308743827044964,-0.04901731014251709,-0.012596397660672665,-0.036502618342638016,0.00886201299726963,0.059619251638650894,-0.017561428248882294,0.05459151417016983,0.04560315981507301,-0.0019153780303895473,0.009595169685781002,-0.057729125022888184,0.026341130957007408,-0.023892194032669067,0.016832968220114708,-0.026450062170624733,-0.07305766642093658,0.03468620404601097,-0.02054707705974579,0.041034333407878876,0.00404499564319849,-0.017474710941314697,-0.043891143053770065,0.02514275535941124,0.02372695878148079,0.010677577927708626,0.06225359067320824,0.040919024497270584,0.005154050886631012,0.030111495405435562,0.0054080006666481495,0.03592434898018837,0.0001651789789320901,0.017304912209510803,-0.01922907680273056,0.04822206869721413,-0.0688890889286995,0.019858958199620247,-0.0008752745925448835,0.03513675928115845,-0.07729781419038773,0.08145932108163834,-0.0327017717063427,0.03425054997205734,-0.08482713997364044,0.006879036780446768,0.059308722615242004,-0.03618019446730614,-0.056978799402713776,-0.021730659529566765,-0.0007874490693211555,-0.30017349123954773,0.011467894539237022,0.0029629627242684364,-0.00585860526189208,-0.010300826281309128,0.023507587611675262,0.009586751461029053,0.01615791581571102,-0.05407087132334709,-0.0025957857724279165,-0.005770532879978418,0.03627054765820503,0.03723520413041115,0.0002953026269096881,-0.01028500497341156,0.003999052103608847,-0.005846572108566761,0.033623822033405304,-0.0072589460760355,-0.07468357682228088,0.03272583335638046,-0.00448765279725194,0.21248994767665863,-0.057705674320459366,0.044046953320503235,0.03008623979985714,-0.018218697980046272,0.04393533617258072,0.07603447884321213,-0.04150347039103508,0.06695082038640976,-0.010416779667139053,0.08510852605104446,-0.07743050903081894,-0.005964982323348522,0.03540671616792679,-0.036865249276161194,0.058287233114242554,0.005791360046714544,-0.03530560061335564,-0.010620728135108948,0.03216135874390602,0.012065712362527847,-0.05922657623887062,0.08696120232343674,-0.051534030586481094,-0.08612160384654999,-0.04676511138677597,-0.005788259673863649,0.06060168892145157,-0.02552523836493492,-0.02923434041440487,-0.05256013199687004,0.0033684736117720604,0.023232899606227875,0.023369308561086655,-0.02598796784877777,-0.02167469449341297,-0.05872185155749321,-0.0459195151925087,0.008857548236846924,-0.07634632289409637,0.016223475337028503,0.03924580290913582,0.11316763609647751]

Example: Creating Users via Admin API

You can also leverage the admin API to create users:

select edge.exec(
$js$

const { data, error } = await supabase.auth.admin.createUser({
  email: 'user@email.com',
  password: 'password',
  user_metadata: { name: 'Yoda' }
});

$js$));

Conclusion

As you can see, combining dynamic Javascript in Edge Functions with a few SQL support functions gets you a powerful new set of tools. By leveraging the edge_wrapper, edge.http_request, and edge.exec functions, developers can create robust and flexible serverless applications that can dynamically execute JavaScript code while interacting with PostgreSQL databases.

As we continue to build and innovate with Supabase, combining edge functions and SQL support functions opens up new avenues for building scalable, efficient, and secure applications. Whether developing a simple project or a complex application, these tools provide the flexibility and power to bring your ideas to life.

This blog post explores the limitations of default Supabase webhooks and how pgwebhook empowers developers to overcome these challenges. We'll delve into the functionalities of pgwebhook and showcase practical use cases that demonstrate its effectiveness.

Understanding the Need for Integration

Integrating databases with external services presents several challenges. The default approach for Postgres webhooks with pg_net might fall short when you need to process the results of a call or handle high volumes that could overwhelm the worker process. Additionally, Supabase's built-in webhooks currently lack the ability to customize the payload before sending it to external services.

Introducing pgwebhook: A revamped Webhook experience

pgwebhook is more than just a webhook solution; it's a comprehensive extension designed to streamline Postgres integration with webhooks. Built with reliable technology like cURL (through pghttp), pgwebhook ensures dependable and performant HTTP requests. It surpasses traditional webhook functionalities by offering features like:

Automatic Fallbacks: Ensures uninterrupted operation even during edge function failures. Regional Fallbacks: (exclusive for edge functions) Guarantees compliance with regulations like GDPR by allowing you to restrict calls to specific regions. Customizable Payloads: Provides flexibility in tailoring the data sent to external services. Seamless Supabase Integration: Integrates effortlessly with the Supabase platform, making it an ideal choice for Supabase users.

Installation and Setup

Installing pgwebhook is a straightforward process, whether you're a Supabase user or prefer manual installation.

Installing Database.dev

create extension if not exists http with schema extensions;
create extension if not exists pg_tle;
drop extension if exists "supabase-dbdev";
select pgtle.uninstall_extension_if_exists('supabase-dbdev');
select
    pgtle.install_extension(
        'supabase-dbdev',
        resp.contents ->> 'version',
        'PostgreSQL package manager',
        resp.contents ->> 'sql'
    )
from http(
    (
        'GET',
        'https://api.database.dev/rest/v1/'
        || 'package_versions?select=sql,version'
        || '&package_name=eq.supabase-dbdev'
        || '&order=version.desc'
        || '&limit=1',
        array[
            ('apiKey', 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InhtdXB0cHBsZnZpaWZyYndtbXR2Iiwicm9sZSI6ImFub24iLCJpYXQiOjE2ODAxMDczNzIsImV4cCI6MTk5NTY4MzM3Mn0.z2CN0mvO2No8wSi46Gw59DFGCTJrzM0AQKsu_5k134s')::http_header
        ],
        null,
        null
    )
) x,
lateral (
    select
        ((row_to_json(x) -> 'content') #>> '{}')::json -> 0
) resp(contents);
create extension "supabase-dbdev";
select dbdev.install('supabase-dbdev');
drop extension if exists "supabase-dbdev";
create extension "supabase-dbdev";

Installing pgwebhook:

-- 
SELECT dbdev.install('mansueli@pgwebhook');
CREATE EXTENSION "mansueli@pgwebhook" VERSION '0.1.1';

You can also install it manually by running the SQL script in your database.

https://github.com/mansueli/tle/blob/master/pgwebhook/

Practical Usage Scenarios

Let's explore practical scenarios where pgwebhook shines:

Direct Usage:

Direct calls to external services are sometimes necessary, particularly for edge functions or APIs restricted to specific regions. For instance, imagine OpenAI restricts calls to allowed regions, or for GDPR compliance, you might need to keep your Edge Function calls within specific subregions. In such cases, pgwebhook offers a solution by providing a wrapper function that sets defaults for the integration process.

Secure Secret Management with Vault

For best practices, consider storing secrets in Vault and fetching them with functions like:

CREATE OR REPLACE FUNCTION vault.get_anon (bearer BOOLEAN DEFAULT FALSE)
RETURNS TEXT 
AS $$
BEGIN
    IF bearer THEN
        RETURN 'Bearer ' || (SELECT decrypted_api_secret FROM secrets.decrypted_api_keys WHERE name = 'anon');
    ELSE
        RETURN (SELECT decrypted_api_secret FROM secrets.decrypted_api_keys WHERE name = 'anon');
    END IF;
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION vault.get_supabase_url () 
RETURNS TEXT 
AS $$
BEGIN
    RETURN (SELECT decrypted_api_secret 
            FROM secrets.decrypted_api_keys 
            WHERE name = 'supabase_url');
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE 
FUNCTION vault.get_service_role (bearer BOOLEAN DEFAULT FALSE) 
RETURNS TEXT 
AS $$
BEGIN
    IF bearer THEN
        RETURN 'Bearer ' || (SELECT decrypted_api_secret 
                             FROM secrets.decrypted_api_keys 
                             WHERE name = 'service_role');    
    ELSE
        RETURN (SELECT decrypted_api_secret 
                FROM secrets.decrypted_api_keys 
                WHERE name = 'service_role');
    END IF;
END;
$$ LANGUAGE plpgsql;

Following this approach, you can create a wrapper function that ensures calls originate from the specified regions:

-- Create wrapper function in the public schema
CREATE OR REPLACE FUNCTION public.euro_edge (func TEXT, data JSONB) RETURNS JSONB LANGUAGE plpgsql
AS $function$
DECLARE
    custom_headers JSONB;
    allowed_regions TEXT[] := ARRAY['eu-west-1', 
                                    'eu-west-2', 
                                    'eu-west-3', 
                                    'eu-north-1', 
                                    'eu-central-1'];
BEGIN
    -- Set headers with anon key and Content-Type
    custom_headers := jsonb_build_object('Authorization', 
                                   vault.get_anon_key(bearer := true), 
                      'Content-Type', 'application/json');
    -- Call edge_wrapper function with default values
    RETURN hook.edge_wrapper(url := ('https://supanacho.supabase.co/functions/v1/' || func), 
                             headers := custom_headers, 
                             payload := data, 
                             max_retries := 5, 
                             allowed_regions := allowed_regions);
END;
$function$;

Webhooks: Powerful Automation

Webhook triggers are crucial for automating actions based on database events. However, ensuring compliance and reliability can be challenging, especially with edge cases like GDPR or service availability issues. pgwebhook addresses these challenges with features like automatic retries and regional fallbacks.

Using Triggers on a Table

You can use pgwebhook similarly to Supabase webhooks:

CREATE TRIGGER your_trigger_name
AFTER INSERT OR UPDATE OR DELETE ON your_table
FOR EACH ROW EXECUTE FUNCTION hook.webhook_trigger(
    'https://your-webhook-url.com',
    'POST',
    '{"Content-Type": "application/json"}',
    '{}',
    5000
);

However, you can also get more:

pgwebhook goes beyond Supabase webhooks by enabling triggers that automatically handle retries and regional headers. This ensures compliance with regulations like GDPR and maintains service availability during regional outages.

Create a Trigger Using a PL/pgSQL Custom Handler

CREATE OR REPLACE FUNCTION hook.custom_handler_function(payload jsonb)
RETURNS jsonb AS $$
DECLARE
    new_payload jsonb;
BEGIN
    -- Modify the payload as needed
    -- Example: Add a new field to the payload
    new_payload := payload || jsonb_build_object('additional_info', 'This is extra info');

    -- Example: Remove a sensitive field
    new_payload := new_payload - 'sensitive_field';

    -- Return the modified payload
    RETURN new_payload;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER your_trigger_name
AFTER INSERT OR UPDATE OR DELETE ON your_table
FOR EACH ROW EXECUTE FUNCTION hook.webhook_trigger(
    'https://your-webhook-url.com',
    'POST',
    '{"Content-Type": "application/json"}',
    '{}',
    5000,
    'hook.custom_handler_function'
);

Conclusion

pgwebhook is a promising new Postgres Trusted Language Extension that simplifies and streamlines webhook integration for Supabase users. Its robust feature set, including automatic retries, regional fallbacks, and customizable payloads, addresses common challenges associated with managing webhooks effectively. By leveraging pgwebhook, developers can enhance their Supabase workflows and ensure reliable communication between databases and external services.

Experimentation and Community

As an actively developed project, pgwebhook welcomes contributions from the community. We encourage you to explore the possibilities of pgwebhook and share your feedback. Feel free to experiment, submit pull requests (PRs) for improvements, and open issues on GitHub to report any bugs or request new features.

We believe that pgwebhook has the potential to become a valuable asset for the Supabase developer community. Join us on GitHub (https://github.com/mansueli/tle/blob/master/pgwebhook/) to explore further and contribute to its development!

In database management and support operations, ensuring Service Level Agreement (SLA) compliance is paramount. Supabase, known for its innovative approach to database management and support, introduces SLA Buddy, a robust support tool aimed at efficient SLA enforcement. This blog post delves into the intricacies of SLA Buddy, shedding light on its functions, operations, and interactions within the Supabase ecosystem.

Introducing SLA Buddy

Supabase's commitment to innovation extends beyond database solutions; it encompasses robust support operations. SLA Buddy stands as a testament to Supabase's dedication to streamlining support processes and ensuring timely resolution of user queries.

Dogfooding: The Birth of SLA Buddy

Supabase firmly believes in dogfooding a philosophy that entails using one's own products internally. This approach played a pivotal role in the creation of SLA Buddy. Leveraging Supabase's suite of tools, including Edge Functions and Database functionalities, SLA Buddy was meticulously developed to meet the stringent demands of support operations.

Understanding SLA Buddy's Functions

SLA Buddy's core function revolves around enforcing SLAs effectively. Let's delve into its primary functions:

SLA Enforcement

SLA Buddy ensures SLA compliance through a series of intricate processes. This includes:

• Slack Reminders: Utilizing Slack reminders to prompt support engineers about impending SLA deadlines.

• Calendar Checks: Employing calendar integration to determine who's currently available to answer support tickets.

Let's take a look at SLA Buddy's Operations

Watching Messages

SLA Buddy actively monitors Slack channels using PostgreSQL functions like process_channels. This function scans Slack channels, handles new messages, and adds tasks to the queue for each new ticket that comes to the platform. Once the channel is scanned through the scan_channel edge function it adds rows to the slack_watcher table. There is a trigger function on that table that creates tasks for each ticket according to the SLA which depends on which channel that the message came from. Tickets have different SLAs, depending on both severity and the subscription level of the user opening the ticket.

CREATE OR REPLACE FUNCTION "public"."insert_tasks"() RETURNS "trigger"
    LANGUAGE "plpgsql"
    AS $$
declare
    escalationtimeintervals int[];
    currentinterval int;
    threadts text;

BEGIN
    IF new.channel_id <> '' THEN
        SELECT escalation_time INTO escalationtimeintervals
          FROM priority WHERE channel_id = new.channel_id;
    ELSE
        escalationtimeintervals := array[10, 20, 35, 50]; -- minutes
    END IF;
    -- INSERT tasks for each escalation level
    FOR i IN 1..4
    LOOP
        -- set the current escalation time interval
        currentinterval := escalationtimeintervals[i];
        -- format thread_ts as (epoch time as a big int) + '.' + ts_ms
        thread_timestamp := extract(epoch FROM new.ts)::bigint::text || '.' || new.ts_ms;

        -- check IF ticket_type is not 'feedback'
        IF lower(new.ticket_type) <> 'feedback' THEN
            INSERT INTO checking_tasks_queue (http_verb, payload, due_time, replied)
            values (
                'POST',
                jsonb_build_object(
                    'channel_id', new.channel_id,
                    'thread_ts', thread_timestamp,
                    'escalation_level', i,
                    'ticket_id', new.ticket_number,
                    'ticket_priority', new.ticket_priority,
                    'ticket_type', new.ticket_type
                ),
                new.ts + (currentinterval * interval '1 minute'),
                false
            );
        END IF;
    END LOOP;
    -- return the new slack_msg row
    return new;
END;
$$;

Verifying Due Tasks

The core function check_due_tasks_and_update() plays a pivotal role in task verification and status updating. It ensures that tasks are duly acknowledged, thereby facilitating timely resolution.

CREATE OR REPLACE FUNCTION "public"."check_due_tasks_and_update"() RETURNS "void"
    LANGUAGE "plpgsql"
    AS $$
DECLARE
    _task RECORD;
    _response JSONB;
    _response_row JSONB;
    _ticket_id text;
    _have_replied BOOLEAN;
    _ticket_array text;
    _lock_key CONSTANT int := 42;
    _lock_acquired boolean;
BEGIN
    -- Try to acquire the advisory lock
    _lock_acquired := pg_try_advisory_lock(_lock_key);
    IF NOT _lock_acquired THEN
        RAISE NOTICE 'Could not acquire lock. Another instance is running. Exiting function...';
        RETURN;
    END IF;

    -- Call create_ticket_array()
    RAISE NOTICE 'Calling create_ticket_array()';
    _ticket_array := public.create_ticket_array();

    -- Check IF _ticket_array is '[]'
    IF _ticket_array = '[]' THEN
        RAISE NOTICE 'No tickets to process. Exiting function...';
        -- Release the advisory lock
        PERFORM pg_advisory_unlock(_lock_key);
        RETURN;
    END IF;

    -- Call help_plataform_wrapper() using _ticket_array
    RAISE NOTICE 'Calling help_plataform_wrapper()';
    _response := public.help_plataform_wrapper(_ticket_array);

    -- Check IF _response is NULL
    IF _response IS NULL THEN
        RAISE NOTICE 'Response is NULL. Exiting function...';
        -- Release the advisory lock
        PERFORM pg_advisory_unlock(_lock_key);
        RETURN;
    END IF;

    -- Process the response
    FOR _response_row IN SELECT * FROM jsonb_array_elements(_response)
    LOOP
        _ticket_id := _response_row->>'ticket_id';
        _have_replied := (_response_row->>'have_replied')::BOOLEAN;
        RAISE NOTICE 'Processing response for ticket_id: %, have_replied: %', _ticket_id, _have_replied;
        IF _have_replied THEN
            RAISE NOTICE 'Ticket % has a reply. Updating...', _ticket_id;
            -- Perform actions for replied tickets
            UPDATE public.checking_tasks_queue
            SET replied_at = NOW(), replied = TRUE
            WHERE payload->>'ticket_id' = _ticket_id;
        ELSE
            RAISE NOTICE 'Ticket % has no reply. Taking actions...', _ticket_id;
            -- Perform actions for no reply
            SELECT * INTO _task FROM public.checking_tasks_queue
            WHERE payload->>'ticket_id' = _ticket_id AND status = '' AND due_time <= NOW()
            ORDER BY due_time ASC
            LIMIT 1;

            IF FOUND THEN
                RAISE NOTICE 'Sending Slack notification for ticket %', _ticket_id;
                -- Use EXCEPTION to handle duplicate keys
                BEGIN
                    INSERT INTO post_to_slack_log(payload) VALUES (_task.payload);
                    PERFORM slack_post_wrapper(_task.payload);
                EXCEPTION
                    WHEN unique_violation THEN
                        RAISE NOTICE 'Duplicate entry for ticket %. Skipping...', _ticket_id;
                    WHEN OTHERS THEN
                        RAISE NOTICE 'Error while inserting into post_to_slack_log. Skipping...';
                        RAISE NOTICE '% %', SQLERRM, SQLSTATE;
                END;
                -- Update the status to 'sent' after calling slack_post_wrapper
                UPDATE public.checking_tasks_queue
                SET status = 'sent'
                WHERE id = _task.id;
            ELSE
                RAISE NOTICE 'Task for ticket % not found!', _ticket_id;
            END IF;
        END IF;
    END LOOP;
    -- Release the advisory lock
    PERFORM pg_advisory_unlock(_lock_key);
END;
$$;

Posting SLA Enforcement Messages on Slack

SLA Buddy employs the Edge Function post_ticket_escalation to post SLA enforcement messages on Slack. This integration with PostgreSQL functions ensures streamlined execution and effective communication with support engineers.

Interactions with Support Members

SLA Buddy fosters seamless interactions between support engineers and the tool itself. Through Slack threads, support members can postpone the next steps in the escalation process by 30 min by @mentioning the bot in the thread. We also pushed a guide on how to interact with mentions in Slack as part of the bot's development.

The bot won't get disarmed until a response is sent in the ticket because we believe that even if the Support Engineer is unable to help the user, they can at least triage and set expectations for the next steps in the ticket like escalating to a specific team.

Watching Support Events

Another crucial aspect of SLA Buddy is its ability to monitor support events seamlessly. At Supabase we have the concept of Embedded Support when a member of the support team will work on more advanced tickets related to a specific Supabase product such as Edge Functions, Dashboard, Storage, Auth, Realtime etc.

The shift information about Support Engineers is hosted in a Google Calendar. This information is retrieved using the following function:

CREATE OR REPLACE FUNCTION "public"."get_embedded_event_names"
    ("date_param" timestamp with time zone DEFAULT "now"())
  RETURNS "jsonb"
  LANGUAGE "plpgsql" SECURITY DEFINER
  SET "search_path" TO 'public', 'extensions', 'vault'
  AS $$
DECLARE
  target_date timestamp with time zone := COALESCE(date_param, now());
  start_date timestamp with time zone := target_date + INTERVAL '2 hours';
  end_date timestamp with time zone := start_date + INTERVAL '1 day' - INTERVAL '1 millisecond';
  time_min text := to_char(start_date, 'YYYY-MM-DD"T"HH24:MI:SS.MS"Z"');
  time_max text := to_char(end_date, 'YYYY-MM-DD"T"HH24:MI:SS.MS"Z"');
  base_url text;
  api_url text;
  response jsonb;
  events jsonb; -- Change the declaration to jsonb
  embedded_event_names text[];
BEGIN
  SELECT decrypted_secret
  INTO base_url
  FROM vault.decrypted_secrets
  WHERE name = 'calendar_base_url';

  api_url := base_url || '&timeMin=' || time_min || '&timeMax=' || time_max;

  select "content"::jsonb into response from http_get(api_url);
  events := response->'items'; -- Remove the typecast to ::jsonb

  SELECT ARRAY_AGG(event->>'summary')
  INTO embedded_event_names
  FROM jsonb_array_elements(events) AS event -- Use jsonb_array_elements function
  WHERE (event->>'summary') ILIKE '%embedded%';
  RETURN COALESCE(to_jsonb(embedded_event_names)::text,'[]');
END;
$$;

Escalation Logic

SLA Buddy's escalation logic is defined in 4 steps of escalation going from a more narrow set of Support Engineers to the Head of Success. Here's the progression:

Conclusion

SLA Buddy is a core operational component for Supabase support operations, keeping the whole team informed and engaged, and assisting with prioritizing tickets by their SLA restrictions.

We are firm believers in letting technology streamline operational work and allowing humans to focus on solving real problems, and SLA Buddy is a great example of that.

Final Thoughts

SLA Buddy started a passion project, born from a need to ensure that we're providing top-quality support to Supabase's users. We're big fans of personal exploration and kaizen incremental change.

And we're not done with SLA Buddy. It'll grow and evolve as Supabase grows, and our needs and the needs of our users change. Because it's built on Supabase features, it'll be easy to update and maintain, and it'll provide more and more value to our internal operations, we hope it might provide some value to you, too. We're also big believers in the Open Source community, and welcome any feedback or ideas you might have to make SLA Buddy even better for everyone.

More Resources About Slack and Edge Functions

• GitHub Repo: SLA Buddy

• Docs Edge Functions: slack mention reply

• Docs Edge Functions: geting started

• Docs Edge Functions: debugging

• Slack Consolidate: a slackbot build with Python & Supabase

Prerequisites:

Before we dive into the code, you'll need a few things:

1. Supabase Account: Ensure you have an account on Supabase.

2. Slack Workspace: You'll require access to a Slack workspace where you can create and install the bot.

3. API Keys: Obtain API keys for Hugging Face and OpenAI.

Creating the Slack Bot Manifest:

To begin, you need to define the bot's characteristics in a manifest file (manifest.yaml). This file specifies the bot's display name, features, OAuth configuration, and settings. Here's an example manifest for your Slack AI bot:

display_information:
  name: SlackAI
features:
  bot_user:
    display_name: SlackAI
    always_online: false
oauth_config:
  scopes:
    bot:
      - app_mentions:read
      - chat:write
      - im:write
      - channels:history
      - commands
settings:
  org_deploy_enabled: false
  socket_mode_enabled: false
  token_rotation_enabled: false

We'll interact with the Slack bot using custom webhooks. For detailed instructions, refer to our previous post on Deploying and Debugging Custom Webhooks on Supabase & PostgreSQL.

Setting Secrets on Supabase CLI:

You'll need to securely store sensitive information, such as API keys, on Supabase using the CLI. Here's how to do it:

# Set OpenAI API Key
supabase --project-ref nacho_slacker secrets \
set OPEN_AI=sk-FB9ZJJbluyN4CH0luSQkwG0t6ZZG3wSQ6SFyBj3k8JZDRKSt

# Set Hugging Face API Key
supabase --project-ref nacho_slacker secrets \
set HUGGINGFACE_TOKEN=hf_rSji7SZZuZwN8ZW53tN4CH0TKRtFCN6Cai

# Set Bot OAuth Token
supabase --project-ref nacho_slacker secrets \
set SLACK_TOKEN=xoxb-3882900064320-6000640064577-QDr8Nk637kw6nachoR7bDu9

Edge Functions: The Soul of Your Slack Bot

In this section, we'll explore two critical Edge Functions, namely slack_ai_mentions.ts and consume_job.ts. These functions play vital roles in your Slack bot's functionality.

1. slack_ai_mentions.ts: This Edge Function sets up an HTTP server using Deno to listen for Slack events. When the bot receives an app mention, it processes the text adding it into a Queue System in Postgres, which will process the requests and send them back to the user.

import { serve } from 'https://deno.land/std@0.197.0/http/server.ts';
import { WebClient } from 'https://deno.land/x/slack_web_api@6.7.2/mod.js';
import { SupabaseClient } from 'https://esm.sh/@supabase/supabase-js@2';

const slack_bot_token = Deno.env.get("SLACK_TOKEN") ?? "";
const bot_client = new WebClient(slack_bot_token);
const supabase_url = Deno.env.get("SUPABASE_URL") ?? "";
const service_role = Deno.env.get("SUPABASE_SERVICE_ROLE_KEY");
const supabase = new SupabaseClient(supabase_url, service_role);

console.log(`Slack URL verification function up and running!`);

serve(async (req) => {
  try {
    const req_body = await req.json();
    console.log(JSON.stringify(req_body, null, 2));
    const { token, challenge, type, event } = req_body;

    if (type == 'url_verification') {
      return new Response(JSON.stringify({ challenge }), {
        headers: { 'Content-Type': 'application/json' },
        status: 200,
      });
    } else if (event.type == 'app_mention') {
      const { user, text, channel, ts } = event;
      const url_path = text.toLowerCase()
            .includes('code') ? '/code' : '/general';
      const { error } = await supabase.from('job_queue').insert({
        http_verb: 'POST',
        payload: { user, text, channel, ts },
        url_path: url_path
      });

      if (error) {
        console.error(error);
        return new Response(JSON.stringify({ error: error.message }), {
          headers: { 'Content-Type': 'application/json' },
          status: 400,
        });
      }
      await post(channel, 
                 ts, 
                 `Taking a look and will get back to you shortly!`);
      return new Response('', { status: 200 });
    }
  } catch (error) {
    return new Response(JSON.stringify({ error: error.message }), {
      headers: { 'Content-Type': 'application/json' },
      status: 400,
    });
  }
});

async function post(channel: string, thread_ts: string, message: string): 
  Promise<void> {
  try {
    const result = await bot_client.chat.postMessage({
      channel: channel,
      thread_ts: thread_ts,
      text: message,
    });
    console.info(result);
  } catch (e) {
    console.error(`Error posting message: ${e}`);
  }
}

1. consume_job.ts: This Edge Function manages tasks related to AI model interactions. It handles requests from the slack_ai_mentions.ts file and communicates with either Hugging Face or OpenAI to generate text responses. The blog post provides detailed instructions on installing and configuring this Edge Function.

import { serve } from "https://deno.land/std@0.197.0/http/server.ts";
import { WebClient } from "https://deno.land/x/slack_web_api@6.7.2/mod.js";

const slack_bot_token = Deno.env.get("SLACK_TOKEN") ?? "";
const bot_client = new WebClient(slack_bot_token);
const hf_token = Deno.env.get("HUGGINGFACE_TOKEN") ?? "";
const openai_api_key = Deno.env.get("OPEN_AI") ?? "";

console.log("Function that will handle the tasks!");

serve(async (req) => {
  const payload = await req.json();
  const url = new URL(req.url);
  const method = req.method;

  // Extract the last part of the path as the command
  const command = url.pathname.split("/").pop();
  try {
    let generated_text = '';
    if (command == "general") {
      generated_text = await getGeneratedTextFromHuggingFace(payload);
    } else {
      generated_text = await getGeneratedTextFromChatGPT(payload);
    }
    await post(payload.channel, 
               payload.ts, 
               `Thanks for asking: ${generated_text}`);
    return new Response('ok',
      { headers: { "Content-Type": "application/json" }, 
        status: 200
      },
    );
  } catch (error) {
    console.error(error);
    return new Response(
      JSON.stringify({ error: error.message }),
      {
        headers: { "Content-Type": "application/json" },
        status: 500,
      },
    );
  }
});

async function post(
  channel: string,
  thread_ts: string,
  message: string,
): Promise<void> {
  try {
    const result = await bot_client.chat.postMessage({
      channel: channel,
      thread_ts: thread_ts,
      text: message,
    });
    console.info(result);
  } catch (e) {
    console.error(`Error posting message: ${e}`);
  }
}

async function getGeneratedTextFromHuggingFace(payload) {
  let huggingface_url = "";
  let body_content = "";
  huggingface_url = "https://api-inference.huggingface.co/models/mistralai/Mistral-7B-Instruct-v0.1";
  body_content = `[INST] ${payload.text} [/INST]`;
  body_content = JSON.stringify({ "inputs": body_content }, null, 2);

  const huggingface_response = await fetch(huggingface_url, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${hf_token}`,
    },
    body: body_content,
  });
  const huggingface_data = await huggingface_response.json();
  if (huggingface_data.error) {
    console.error(huggingface_data.error);
    throw new Error(huggingface_data.error.message);
  }
  const generated_text = huggingface_data[0]
        .generated_text.split("[/INST]");
  return generated_text.length > 1 ? 
         generated_text[1] : generated_text[0];
}

async function getGeneratedTextFromChatGPT(payload) {
  const headers = {
    "Content-Type": "application/json",
    "Authorization": `Bearer ${openai_api_key}`,
  };

  const openai_url = "https://api.openai.com/v1/chat/completions";

  let body_content = {
    "model": "gpt-3.5-turbo", // Replace with the name of the chat model you want to use
    "messages": [
      {
        "role": "system",
        "content": `You are a detail-oriented, helpful, 
                    and eager to please assistant.`
      },
      {
        "role": "user",
        "content": payload.text
      }
    ]
  };
  const body_content_text = JSON.stringify(body_content, null, 2);
  const openai_response = await fetch(openai_url, {
    method: "POST",
    headers: headers,
    body: body_content_text,
  });
  const openai_data = await openai_response.json();
  if (openai_data.error) {
    console.error(openai_data.error);
    throw new Error(openai_data.error.message);
  }
  return openai_data.choices[0].message.content.trim();
}

These Edge Functions are essential components of the Slack bot, allowing it to seamlessly integrate with external AI services and provide intelligent responses in real-time.

Deploying Edge Functions:

Next, you'll deploy these two Edge Functions using Supabase CLI:

supabase functions deploy consume_job \
--project-ref nacho_slacker --no-verify-jwt

supabase functions deploy slack_ai_mentions \
--project-ref nacho_slacker --no-verify-jwt

Storing Secrets Securely in Vault

To ensure the security of sensitive information, it's crucial to utilize Vault for secret management. Here's a step-by-step guide to adding service_role and consumer_function to Vault:

1. Add service_role by using the service_role key found in the Supabase dashboard.

2. Incorporate consumer_function into Vault by utilizing the URL of the Edge Function consume_job from the Supabase dashboard.

   

Configuring Slack Apps

For your bot to seamlessly interact with Slack, you'll need to configure Slack Apps:

1. Navigate to the Slack Apps page.

2. Under "Event Subscriptions," add the URL of the slack_ai_mentions function and click to verify the URL.

3. The Edge function will respond, confirming that everything is set up correctly.

4. Add app-mention in the events the bot will subscribe to.

Installing DBDEV and Supa_Queue

To enhance your Supabase project's capabilities, consider installing the supabase-dbdev and supa_queue extensions. Here's how you can do it:

Installing supabase-dbdev

-- Install supabase-dbdev
create extension if not exists http with schema extensions;
create extension if not exists pg_tle;
select pgtle.uninstall_extension_if_exists('supabase-dbdev');
drop extension if exists "supabase-dbdev";
select
    pgtle.install_extension(
        'supabase-dbdev',
        resp.contents ->> 'version',
        'PostgreSQL package manager',
        resp.contents ->> 'sql'
    )
from http(
    (
        'GET',
        'https://api.database.dev/rest/v1/'
        || 'package_versions?select=sql,version'
        || '&package_name=eq.supabase-dbdev'
        || '&order=version.desc'
        || '&limit=1',
        array[
            ('apiKey', 'YOUR_DATABASE_DEV_API_KEY_HERE')::http_header
        ],
        null,
        null
    )
) x,
lateral (
    select
        ((row_to_json(x) -> 'content') #>> '{}')::json -> 0
) resp(contents);
create extension "supabase-dbdev";
select dbdev.install('supabase-dbdev');
drop extension if exists "supabase-dbdev";
create extension "supabase-dbdev";

Installing the supa_queue Extension

To further empower your Supabase project, consider installing the supa_queue extension. This extension offers a robust queue system for efficiently managing tasks and processes. Here's how you can install it:

-- Install supa_queue
select dbdev.install('mansueli-supa_queue');
create extension "mansueli-supa_queue" version '1.0.3';

Note: The supa_queue extension is a Trusted Language Extension available at https://database.dev/mansueli/supa_queue. It was created based on a previous post we published about building a simple & robust queue system for PostgreSQL. This extension enables you to implement a powerful queue system in your Supabase project, which can prove invaluable for managing asynchronous tasks and background processing.

Installing and Interacting with Your Slack Bot

Now that your Slack bot is ready to roll, it's time to integrate it into your Slack workspace and start interacting with it in two different contexts: one for general use with the Hugging Face model and another for code-related inquiries using the ChatGPT model.

Installing Your Bot to Slack

1. Add Your Bot to Slack: Navigate to your Slack workspace and access the "Apps" section. Search for your bot's name (e.g., "SlackAI") and add it to your workspace.

2. Authorize Bot Permissions: Ensure you authorize the necessary permissions for your bot, including sending messages, interacting with users, and reading messages.

3. Place Your Bot in a Channel: Choose a Slack channel where you'd like your bot to operate. Invite your bot to join the channel by mentioning it (e.g., @SlackAI).

General Use with Hugging Face Model

In this context, you can utilize the Hugging Face model for general conversations and inquiries. Mention your bot in the channel and ask a question or initiate a conversation. For example:

@SlackAI How's the weather today?

Your bot, powered by the Hugging Face model, will respond with intelligent insights or answers.

Code-Related Inquiries with ChatGPT Model

When you have code-related questions or need assistance with technical matters, you can invoke the ChatGPT model. Mention your bot again in the channel and frame your inquiry:

@SlackAI Can you help me with this Python code snippet?

Your bot will be ready to assist with coding-related queries, making your team's technical discussions more efficient.

Conclusion

In this comprehensive exploration of creating a powerful Slack bot with AI capabilities using Supabase, you've gained the knowledge and tools to elevate your team's communication and productivity. By seamlessly integrating AI models and efficient queue management into your Slack bot, you've unlocked a world of automation and intelligent responses.

As you continue to refine and expand your bot's functionalities, consider these top-performing articles for further insights and optimizations:

1. Using Custom Claims & Testing RLS with Supabase: Dive deep into custom claims and role-level security with Supabase to enhance your application's data security.

2. Supabase User Self-Deletion: Empower Users with Edge Functions: Learn how to implement user self-deletion features using Supabase Edge Functions, empowering users with control over their accounts.

3. Creating Customized i18n-Ready Authentication Emails using Supabase Edge Functions, PostgreSQL, and Resend: Dive into internationalization and create personalized authentication emails with Supabase Edge Functions and PostgreSQL.

4. Testing Supabase Edge Functions with Deno Test: Explore best practices for testing your Supabase Edge Functions using Deno, ensuring robust functionality.

These articles complement your journey to master Supabase and Slack bot development, offering valuable insights and strategies for enhancing your applications. Experimentation and customization are key to tailoring your bot to meet your project's specific needs.

References

For additional guidance and resources, consider exploring these valuable references:

• Supabase Official Documentation: Access the official documentation for Supabase to explore the platform's capabilities and features.

• PostgreSQL Official Documentation: Dive into the official documentation of PostgreSQL, the powerful database system at the core of Supabase.

• Deno Documentation: Explore Deno documentation for insights into this secure runtime for JavaScript and TypeScript.

Building a Slack bot infused with AI capabilities offers an exciting opportunity to automate tasks and deliver intelligent responses, ultimately streamlining your team's interactions and fostering a more engaging work environment. Enjoy the journey of experimenting with various AI models and expanding your bot's functionalities!

In this blog post, we'll explore an approach tailored for quick prototyping and agile development—how to easily deploy and rollback PostgreSQL functions using Supabase. Supabase, a powerful open-source alternative to traditional database management systems, simplifies the process of deploying and managing functions in these scenarios.

If you're working on more complex workflows or long-term projects, we highly recommend referring to Supabase's migration guide for optimal version control and deployment practices.

PostgreSQL and Supabase in Modern Web Applications

PostgreSQL, a robust open-source relational database management system (RDBMS), has gained popularity in web development due to its reliability, extensibility, and support for complex data types.

Supabase, an open-source platform, offers various tools and services for modern web applications. It leverages PostgreSQL as its core database engine and provides a user-friendly interface for managing data, authentication, and more.

We'll explore how Supabase complements PostgreSQL by simplifying function deployment and rollback. You can refer to the PostgreSQL Documentation to learn more about PostgreSQL.

Tracking Function History in PostgreSQL

When managing a PostgreSQL database, it's essential to track changes made to functions over time. This historical record allows you to review, audit, and revert to previous versions if needed.

To facilitate this, we'll create an archive.function_history table that stores crucial information about each function, including its name, arguments, return type, source code, and language settings.

Here's the SQL code for creating this table:

CREATE SCHEMA archive;

CREATE TABLE archive.function_history (
  id BIGINT GENERATED BY DEFAULT AS IDENTITY,
  schema_name text,
  function_name text,
  args text,
  return_type text,
  source_code text,
  lang_settings text,
  updated_at timestampz DEFAULT now(),
  version NUMERIC DEFAULT 1,
  CONSTRAINT function_history_pkey PRIMARY KEY (id)
);

--Handling version numbers automatically:
CREATE OR REPLACE FUNCTION calculate_version()
RETURNS TRIGGER AS $$
BEGIN
  -- Calculate the version number for new rows
    SELECT COALESCE(MAX(version), 0) + 1
    INTO NEW.version
    FROM archive.function_history
    WHERE schema_name = NEW.schema_name
      AND function_name = NEW.function_name
      AND return_type = NEW.return_type
      AND args = NEW.args;

  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER before_insert_function_history
BEFORE INSERT ON archive.function_history
FOR EACH ROW
EXECUTE FUNCTION calculate_version();

Saving Function History

The archive.save_function_history Function

To automate recording function changes, we'll create a PostgreSQL function called archive.save_function_history. This function takes parameters such as the function name, arguments, return type, source code, schema name, and language settings.

Here's the SQL code for creating the archive.save_function_history function:

CREATE OR REPLACE 
FUNCTION archive.save_function_history(
  function_name text,
  args text,
  return_type text,
  source_code text,
  schema_name text default 'public',
  lang_settings text default 'plpgsql'
) RETURNS void 
SET search_path = public, archive
SECURITY DEFINER
AS
$$
BEGIN
  INSERT INTO archive.function_history (
        schema_name, 
        function_name, 
        args, 
        return_type, 
        source_code, 
        lang_settings)
  VALUES (schema_name, function_name, args, return_type, source_code, lang_settings);
END;
$$
LANGUAGE plpgsql;
-- Protecting the function:
REVOKE EXECUTE ON FUNCTION 
archive.save_function_history FROM public;

REVOKE EXECUTE ON FUNCTION 
archive.save_function_history FROM anon, authenticated;

This function allows us to easily store a snapshot of a function each time it's modified.

Deploying Functions from Source

The create_function_from_source Function

Managing functions often involves deploying them from source code. PostgreSQL requires specific syntax for function creation, and Supabase simplifies this with the create_function_from_source function.

CREATE OR REPLACE FUNCTION 
create_function_from_source(
  function_text text,
  schema_name text default 'public'
) RETURNS text 
SECURITY DEFINER
AS $$
DECLARE
  function_name text;
  argument_types text;
  return_type text;
  function_source text;
  lang_settings text;
BEGIN
  -- Execute the function text to create the function
  EXECUTE function_text;

  -- Extract function name from function text
  SELECT (regexp_matches(function_text, 'create (or replace )?function (public\.)?(\w+)', 'i'))[3]
  INTO function_name;

  -- Get function details from the system catalog
  SELECT pg_get_function_result(p.oid), 
                pg_get_function_arguments(p.oid), p.prosrc, l.lanname
  INTO return_type, argument_types, function_source, lang_settings
  FROM pg_proc p
  JOIN pg_namespace n ON n.oid = p.pronamespace
  JOIN pg_language l ON l.oid = p.prolang
  WHERE n.nspname = schema_name AND p.proname = function_name;

  -- Save function history
  PERFORM archive.save_function_history(function_name, argument_types, return_type, function_text, schema_name, lang_settings);

  RETURN 'Function created successfully.';
EXCEPTION
  WHEN others THEN
    RAISE EXCEPTION 'Error creating function: %', sqlerrm;
END;
$$ LANGUAGE plpgsql;
-- Protecting the function:
REVOKE EXECUTE ON FUNCTION 
create_function_from_source FROM public;

REVOKE EXECUTE ON FUNCTION 
create_function_from_source FROM anon, authenticated;

This function takes the function's SQL source code and schema name as parameters, creating the function within the database. It's a powerful tool for dynamic function creation.

Here's an example of deploying a function using create_function_from_source:

SELECT create_function_from_source(
$$
-- Note that you can just paste the function below:
CREATE OR REPLACE FUNCTION public.convert_to_uuid(input_value text)
 RETURNS uuid
AS $function$
DECLARE
  hash_hex text;
BEGIN
  -- Return null if input_value is null or an empty string
  IF input_value IS NULL OR NULLIF(input_value, '') IS NULL THEN
    RETURN NULL;
  END IF;
  hash_hex := substring(encode(digest(input_value::bytea, 'sha512'), 'hex'), 1, 36);
  RETURN (left(hash_hex, 8) || '-' || right(hash_hex, 4) || '-4' || right(hash_hex, 3) || '-a' || right(hash_hex, 3) || '-' || right(hash_hex, 12))::uuid;
END;
$function$
LANGUAGE plpgsql
IMMUTABLE
SECURITY DEFINER;
-- End of the function above
$$
);

Rolling Back Functions

Rolling back functions is as crucial as deploying them. Mistakes happen, and being able to revert to a previous version can save valuable time and prevent data corruption.

The rollback_function function comes to the rescue. It retrieves the most recent function version from the archive.function_history table and executes it. If no previous version exists, it gracefully handles the situation.

Here's the SQL code for creating and using the rollback_function:

CREATE OR REPLACE FUNCTION rollback_function(
  func_name text,
  schema_n text default 'public'
) RETURNS text 
SECURITY DEFINER
AS $$
DECLARE
  function_text text;
BEGIN
  -- Get the most recent function version from the function_history table
  SELECT source_code
  INTO function_text
  FROM archive.function_history
  WHERE function_name = func_name AND schema_name = schema_n
  ORDER BY updated_at DESC
  LIMIT 1;

  -- If no previous version is found, raise an error
  IF function_text IS NULL THEN
    RAISE EXCEPTION 'No previous version of function % found.', func_name;
  END IF;

  -- Add 'or replace' to the function text if it's not already there (case-insensitive search and replace)
  IF NOT function_text ~* 'or replace' THEN
    function_text := regexp_replace(function_text, 'create function', 'create or replace function', 'i');
  END IF;

  -- Drop current version:
  EXECUTE format('DROP FUNCTION IF EXISTS %I.%I', schema_n, func_name);
  -- Execute the function text to create the function
  EXECUTE function_text;

  RETURN 'Function rolled back successfully.';
EXCEPTION
  WHEN others THEN
    RAISE EXCEPTION 'Error rolling back function: %', sqlerrm;
END;
$$ LANGUAGE plpgsql;

-- Protecting the function:
REVOKE EXECUTE ON FUNCTION rollback_function FROM public;
REVOKE EXECUTE ON FUNCTION rollback_function FROM anon, authenticated;

-- Example of rolling back a function
SELECT rollback_function('convert_to_uuid');

Setting up existing functions as the first version

If you are starting with an existing database but want to start versioning from now. You can use this function below to archive all in the public schema.

CREATE OR REPLACE FUNCTION archive.setup_function_history(schema_name text default 'public')
RETURNS VOID AS
$$
DECLARE
  function_record record;
BEGIN
  -- Loop through existing functions in the specified schema
  FOR function_record IN (
    SELECT
      n.nspname AS schema_name,
      p.proname AS function_name,
      pg_catalog.pg_get_function_arguments(p.oid) AS args,
      pg_catalog.pg_get_function_result(p.oid) AS return_type,
      pg_catalog.pg_get_functiondef(p.oid) AS source_code,
      l.lanname AS lang_settings
    FROM pg_catalog.pg_proc p
    LEFT JOIN pg_catalog.pg_namespace n ON n.oid = p.pronamespace
    LEFT JOIN pg_catalog.pg_language l ON l.oid = p.prolang
    WHERE n.nspname = schema_name
  )
  LOOP
    -- Insert information about the function into the history table
    PERFORM archive.save_function_history(
      function_record.function_name,
      function_record.args,
      function_record.return_type,
      function_record.source_code,
      function_record.schema_name,
      function_record.lang_settings
    );
  END LOOP;
END;
$$
LANGUAGE plpgsql;

SELECT archive.setup_function_history();

Conclusion

In conclusion, efficient management of PostgreSQL functions is crucial for web application development. Supabase, with its integration with PostgreSQL and the tools we've explored, offers a streamlined approach to function deployment and rollback.

Key takeaways from this blog post include the importance of function history tracking, the creation of the archive.function_history table, the archive.save_function_history function for recording changes, and the convenience of create_function_from_text and

rollback_function for deployment and rollback.

If you found this article valuable, you might also be interested in exploring related topics:

• Rate Limiting Supabase Requests with PostgreSQL and pg_headerkit: Learn how to implement rate limiting for Supabase requests.

• Comprehensive Guide: Deploying and Debugging Custom Webhooks on Supabase & PostgreSQL: Explore techniques for deploying and debugging custom webhooks.

We encourage you to explore Supabase and PostgreSQL further to unlock the full potential of efficient database management.

Additional Resources

For further information and exploration, here are some additional resources:

• Supabase Documentation

• PostgreSQL Documentation

• Supabase GitHub Repository

• PostgreSQL Official Site

Feel free to delve deeper into these resources to enhance your understanding of these powerful tools for database management.

Understanding the Issue

SMTP (Simple Mail Transfer Protocol) serves as the backbone for sending emails from web applications. When integrating GoTrue as an authentication service in Supabase, the platform relies on SMTP to send important email notifications to users. However, some users have reported issues with Office365 not allowing these emails to go through.

GoTrue is designed to streamline user authentication and management within Supabase applications. To ensure its features work seamlessly, the underlying email delivery system must be properly configured.

Troubleshooting

If you've encountered the problem of emails not being sent when using Office365 as the SMTP server, you may have noticed the following symptoms:

• Failed Email Delivery: Emails not reaching their intended recipients.
• Authentication Issues: Error messages indicating authentication problems.
• Spam or Non-Delivery: Emails being marked as spam or not being delivered at all.

Why Office365 May Block SMTP Authentication

Office365, like many email services, has security measures in place to prevent unauthorized use of its SMTP servers. By default, it may block SMTP authentication for specific mailboxes to protect against misuse. Understanding these security measures is crucial when configuring Office365 for SMTP in GoTrue.

Solution - Configuring Office365 for SMTP Authentication

Now that we've grasped the issue's context and symptoms, let's delve into the solution: configuring Office365 for SMTP authentication.

Step-by-Step Guide

Accessing Supabase.com

To begin, visit Supabase.com to learn more about Supabase and its features.

Accessing the Office365 Admin Center

Next, you'll need to access the Office365 Admin Center. Follow these steps:

• Log in to your Office365 account as an administrator.
• Navigate to the Admin Center.

Navigating to Mailbox Settings

Once you're in the Admin Center, proceed to find mailbox settings:

• Locate and click on the "Users" or "Active users" option.
• Select the user whose mailbox settings you want to configure.

Enabling SMTP Authentication

SMTP Authentication must be enabled for the selected mailbox. Here's how:

• Scroll down to the "Email apps" section.
• Click "Manage email apps."
• Find "SMTP AUTH (SMTP Authentication)" and ensure it's enabled.

Alternative Method: PowerShell

In some cases, you may prefer using PowerShell for this configuration, especially if you need to configure multiple mailboxes. Here's the PowerShell command to enable SMTP authentication. If you never used PowerShell to connect with your Office365 Exchange services, run the following commands:

Set-ExecutionPolicy RemoteSigned
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

We can set this mailbox to allow SMTP Authentication now:

Set-CASMailbox -Identity <MailboxIdentity> -SmtpClientAuthenticationDisabled $false

In the command, replace <MailboxIdentity> with the actual mailbox you want to configure (e.g., support@contoso.com).

Using PowerShell provides flexibility and scalability, especially in larger organizations.

Testing the Configuration

With Office365 configured for SMTP authentication, it's essential to test the setup to ensure everything is working as expected. Testing helps verify that email notifications from GoTrue will be reliably delivered to your users.

To perform this test, you can use the supabase.auth.admin.inviteUserByEmail method provided by Supabase. This method allows you to send an invitation email to a specified email address. Here's how you can use it in JavaScript:

const { data, error } = await supabase
  .auth.admin.inviteUserByEmail('email@example.com');

You can find detailed information about this method in the Supabase documentation.

By using this method, you can invite a dummy user to your app. If the email is sent successfully, it indicates that your SMTP configuration with Office365 is working correctly. However, if you encounter any errors or issues during this test, you may need to revisit your SMTP configuration settings and consult the troubleshooting tips in the next section to resolve the problem.

Testing is a crucial step in ensuring the reliability of your email communication within Supabase applications. Make sure to perform this test as part of your configuration process and periodically to verify ongoing functionality.

Conclusion

In conclusion, configuring Office365 for SMTP authentication is a critical step in ensuring the smooth operation of email notifications within your Supabase applications. We have explored the background context of SMTP, and the integration of GoTrue in Supabase, and addressed the issue of emails not being delivered successfully. By following the step-by-step guide and considering alternative methods like PowerShell, you can overcome these challenges and provide reliable email communication to your users.

Remember that proper configuration and regular testing are key to maintaining a robust email system. We encourage you to follow best practices for email configuration and security to ensure the integrity of your email communications.

Additional Resources

For further reading and reference, here are some additional resources:

• Office365 Documentation
• Supabase Documentation

Please note that configurations and settings may change over time, so it's a good practice to refer to the official documentation for the most up-to-date information.

Prerequisites

Before we embark on this tutorial, it's crucial to have a foundational understanding of web development and Node.js. Familiarity with Next.js, a popular React framework, will also be advantageous. Additionally, you need Node.js and npm (Node Package Manager) installed on your system.

Setting up the Project

To kickstart our journey, let's create a new Next.js project integrated with Supabase. Execute the following command to establish the initial project structure:

npx create-next-app -e with-supabase username-login

This command will generate a Next.js project preconfigured with Supabase support with default authentication and routes.

Configuring Supabase

Before we start coding, let's set up Supabase for our project. You need a Supabase project to get the credentials you need. Make sure you have your Supabase URL and API keys ready. It's important to keep these credentials safe, such as by using environment variables. You can find more information on configuring Supabase in the Supabase documentation.

Tweaking the Sign-In Route

Now, let's closely examine the code responsible for user sign-in. Navigate to the username-login/app/auth/sign-in/route.ts file in your project. We will replace the default code for user authentication as follows:

Replace:

const { error } = await supabase.auth.signInWithPassword({
  email,
  password,
})

With:

const { data } = await supabase.functions.invoke('sign-in', {
  body: {
    email,
    password,
  }
});

const { error } = await supabase.auth.setSession({
  access_token: data.access_token,
  refresh_token: data.refresh_token
});

This code leverages Supabase Edge Functions to handle user sign-in, enabling users to choose between username and password or email for login.

Edge Function for Sign-In

Within the authentication workflow, this edge function plays a pivotal role in managing sign-in requests. This function offers users greater flexibility by enabling them to use their usernames as an alternative login option. We'll be using this cors.ts file for handling the CORS headers:

export const corsHeaders = {
  'Access-Control-Allow-Origin': '*',
  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
}

To set up the Edge Function for Sign-In, create a Deno script as follows:

import { serve } from 'https://deno.land/std@0.192.0/http/server.ts'
import { createClient } from 'https://esm.sh/@supabase/supabase-js@2'
import { corsHeaders } from '../_shared/cors.ts'

console.log(`Function "sign-in" is up and running!`)

const options =  {
  auth: {
    flowType: 'implicit',
    autoRefreshToken: false,
    persistSession: false,
    detectSessionInUrl: false
  }
};

serve(async (req: Request) => {
  // This is needed if you're planning to invoke your function from a browser.
  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }
  try {
    const supabaseAdmin = createClient(
      Deno.env.get('SUPABASE_URL') ?? '',
      Deno.env.get('SUPABASE_SERVICE_ROLE_KEY') ?? '',
      options
    )
    const { email, password } = await req.json()
    // Create a Supabase client with the Auth context of the logged-in user.
    const supabaseClient = createClient(
      // Supabase API URL - env var exported by default.
      Deno.env.get('SUPABASE_URL') ?? '',
      // Supabase API ANON KEY - env var exported by default.
      Deno.env.get('SUPABASE_ANON_KEY') ?? '',
      options
    )
    const { data: profileData, error: userError } = await supabaseAdmin
      .from('profiles')
      .select('email')
      .or(`username.eq.${email},email.eq.${email}`)
      .limit(1)
      .maybeSingle();
    console.log("profileData:" + JSON.stringify(profileData, null, 2))
    if (userError) throw userError

    const { data: { session }, error } = await supabaseClient.auth.signInWithPassword({
      email: profileData.email,
      password: password,
    })
    if (error) throw error
    console.log("data:" + JSON.stringify(session, null, 2))
    return new Response(JSON.stringify(session), {
      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
      status: 200,
    });
  } catch (error) {
    return new Response(JSON.stringify({ error: error }), {
      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
      status: 400,
    })
  }
})

This Deno script handles sign-in requests and allows users to choose between usernames and email for login. It leverages Supabase Edge Functions, enhancing the flexibility of your authentication system.

To learn more about testing Supabase Edge Functions, check our dedicated blog post on Testing Supabase Edge Functions with Deno Test.

Here's an example structure for the public.profiles table that you can use in your project:

CREATE TABLE public.profiles (
  id uuid NOT NULL,
  updated_at timestamp with time zone NULL,
  username text NULL,
  full_name text NULL,
  avatar_url text NULL,
  website text NULL,
  email text NULL,
  CONSTRAINT profiles_pkey PRIMARY KEY (id),
  CONSTRAINT profiles_username_key UNIQUE (username),
  CONSTRAINT profiles_id_fkey FOREIGN KEY (id) REFERENCES auth.users (id) ON DELETE CASCADE,
  CONSTRAINT username_length CHECK (char_length(username) >= 3)
);
ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;

You can read more about creating such a table in Managing User Data.

Conclusion

In this extensive exploration of user authentication with Supabase, we've equipped you with the knowledge and tools to build secure and flexible login systems for your web applications. By enabling users to choose between username and password or email and password login methods, you've enhanced the user experience.

As you continue to develop and fine-tune your authentication systems, consider the following articles for further insights and optimizations:

• Comprehensive Guide: Deploying and Debugging Custom Webhooks on Supabase & PostgreSQL: Learn how to automate webhooks for seamless integration into your applications.

• Creating Customized i18n-Ready Authentication Emails using Supabase Edge Functions, PostgreSQL, and Resend: Dive into the world of internationalization and create personalized authentication emails.

• How to Boost Supabase Reliability: A Guide to Using Postgres Foreign Data Wrappers: Enhance the reliability of your Supabase applications with foreign data wrappers.

These articles will complement your journey to master Supabase authentication and take your web development skills to the next level. Experimentation and customization are key to tailoring authentication systems to your specific project needs.

References

For additional guidance and resources, consider exploring these valuable references:

• Supabase Official Documentation: Explore Supabase's official documentation for comprehensive insights into this robust backend platform.

• PostgreSQL Official Documentation: Dive into the official documentation of PostgreSQL, the powerful database system at the core of Supabase.

• Next.js Documentation: Access Next.js documentation for further information on this popular React framework.

• Deno Documentation: Explore Deno documentation for insights into this secure runtime for JavaScript and TypeScript.

With these references and your newfound knowledge, you're well-prepared to create exceptional web applications powered by Supabase. Continue your journey in web development, and don't hesitate to explore additional features and customization options offered by Supabase and PostgreSQL.

Why Migrate from MongoDB to Supabase with PostgreSQL?

MongoDB has been a go-to choice for its flexibility, but as your project matures, scalability and complex querying challenges may arise. Supabase, built on PostgreSQL, combines the best of both worlds—a flexible NoSQL-style database with the reliability and performance of PostgreSQL. This migration opens up new possibilities for your application, making it a vital step for your project's growth.

Understanding the Migration Process

Why Choose Supabase and PostgreSQL for Your Migration?

To kick off your migration journey, let's delve into why Supabase and PostgreSQL are the great choices:

• Scalability: Supabase, powered by PostgreSQL, offers superb scalability, making it a fit for projects of all sizes.

• Performance: PostgreSQL is renowned for its speed and efficiency, ensuring smooth application operation even as your data grows.

• Ease of Use: Supabase simplifies database management with an intuitive interface, catering to developers of all skill levels.

Planning the Migration Process

Before diving into the technical aspects, meticulous planning is paramount for a seamless migration. Considerations like data mapping, schema design, and data transformation require careful attention. As discussed in our previous article on "Exploring Data Relationships with Supabase and PostgreSQL", understanding your data's structure is a crucial initial step.

Running the Migration

You can run the migration process using this Colab notebook I've prepared for your convenience. It provides step-by-step instructions to ensure a smooth transition from MongoDB to Supabase with PostgreSQL. Below, we'll go through the steps to set it up yourself:

Preparing Your Environment

Installing the Required Python Libraries

Let's begin by installing the essential Python libraries for your migration journey:

pip install mongo
pip install psycopg2

Setting Up Connection URIs

To begin the migration process, it's essential to configure the connection URIs for both MongoDB and Supabase. Make sure you have your credentials ready and set the environment variables as shown below:

# Source DB variables:
%env supabase_uri=postgresql://postgres:password@db.xxasaxx.supabase.co:5432/
%env mongo_uri=mongodb+srv://nacho:password@cluster001.jjj.mongodb.net/?retryWrites=true&w=majority
%env mongo_db=sample_mflix

Running the Migration Manually

Mapping Data Types

Mapping data types from MongoDB to PostgreSQL is a crucial step in the migration process. The provided script handles these conversions intelligently based on the Python types encountered in your MongoDB data. For example, it recognizes ObjectId and correctly maps it to the equivalent PostgreSQL data type. This ensures that your data retains its integrity throughout the migration process.

Here's how data types are mapped in the script:

# Mapping MongoDB types to PostgreSQL types
SQL_DATA_TYPE = {
    "string": "TEXT",
    "ObjectId": "TEXT",
    "datetime": "TIMESTAMP WITH TIME ZONE",
    "int": "INT",
    "list": "JSONB",
    "dict": "JSONB",
    "bool": "Boolean",
    "float": "NUMERIC",
    "default": "TEXT",
}

Creating PostgreSQL Tables

Creating the necessary tables in PostgreSQL is seamlessly handled by the provided script. If a table doesn't already exist for a MongoDB collection, the script creates one. Additionally, it checks for existing tables to avoid duplicates. This ensures that your data is organized efficiently in the PostgreSQL database, making it ready for further use.

In the script, you have the flexibility to specify the target MongoDB database using the mongo_db_manual variable. If left empty, the script will run for all databases in MongoDB.

For databases with more resources, consider including collection.find(no_cursor_timeout=True) in the code to prevent cursor timeouts during the migration.

Migration code

Here's the migration code that establishes connections, maps data types, and creates PostgreSQL tables:

from bson.decimal128 import Decimal128
import pymongo
import psycopg2
from psycopg2.extensions import AsIs
import json
from datetime import datetime
from psycopg2 import sql, extensions, connect, Error
from bson import ObjectId
import os

mongo_url = os.environ['mongo_uri']
supabase_url = os.environ['supabase_uri']

class CustomEncoder(json.JSONEncoder):
    def default(self, obj):
        if isinstance(obj, ObjectId):
          return str(obj)
        if isinstance(obj, datetime):
          return obj.isoformat()
        if isinstance(obj, Decimal128):
          return str(obj)
        if isinstance(obj, complex):
            return [obj.real, obj.imag]
        return json.JSONEncoder.default(self, obj)


psycopg2.extensions.register_adapter(Decimal128, lambda val: AsIs(str(val.to_decimal())))

# Connect to MongoDB
mongo_client = pymongo.MongoClient(mongo_url)
# Connect to PostgreSQL
pg_conn = connect(supabase_url)
pg_conn.set_isolation_level(extensions.ISOLATION_LEVEL_AUTOCOMMIT)
pg_cur = pg_conn.cursor()

# Mapping MongoDB types to PostgreSQL types
SQL_DATA_TYPE = {
  "str": "TEXT",
  "ObjectId": "TEXT",
  "datetime.datetime": "TIMESTAMP WITH TIME ZONE",
  "datetime": "TIMESTAMP WITH TIME ZONE",
  "int": "INT",
  "list": "JSONB",
  "dict": "JSONB",
  "bool": "Boolean",
  "float": "NUMERIC",
  "default": "TEXT",
  "NoneType":"TEXT",
  "Decimal128":"NUMERIC",
}

# Store the type of each field
field_types = {}

# Get the list of database names from MongoDB
mongo_db_manual = os.environ['mongo_db']
mongo_db_names = []
if(len(mongo_db_manual)>0):
  mongo_db_names.append(mongo_db_manual)
else:
  mongo_db_names = mongo_client.list_database_names()

# Iterate over all MongoDB databases
for db_name in mongo_db_names:
    print("Starting to migrate :"+ str(db_name))
    mongo_db = mongo_client[db_name]

    # Iterate over all collections in the current database
    for collection_name in mongo_db.list_collection_names():
        # Skip system collections
        if collection_name.startswith("system."):
            continue

        collection = mongo_db[collection_name]
        # Create table in PostgreSQL if it doesn't exist
        pg_cur.execute(sql.SQL("CREATE TABLE IF NOT EXISTS {} ()").format(
            sql.Identifier(collection_name)))

        # Iterate over all documents in the collection
        cursor = collection.find()
        for document in cursor:
            # For each document, build a list of fields and a list of values
            fields = []
            values = []
            for field, value in document.items():
                # Determine PostgreSQL type based on Python type
                if isinstance(value, ObjectId):
                    pg_type = SQL_DATA_TYPE["ObjectId"]
                    value = str(value)
                else:
                    pg_type = SQL_DATA_TYPE.get(type(value).__name__, SQL_DATA_TYPE["default"])

                # Add type suffix to field name if a new type is encountered
                field_with_type = field
                if field in field_types:
                    if type(value).__name__ not in field_types[field]:
                        field_types[field].add(type(value).__name__)
                        field_with_type = f"{field}_{type(value).__name__}"
                else:
                    field_types[field] = {type(value).__name__}

                # Add column in PostgreSQL if it doesn't exist
                try:
                    pg_cur.execute(sql.SQL("ALTER TABLE {} ADD COLUMN {} {}").format(
                        sql.Identifier(collection_name),
                        sql.Identifier(field_with_type),
                        sql.SQL(pg_type)))
                except Error:
                    pass  # Column already exists, no action needed

                # Add field and value to the lists
                fields.append(sql.Identifier(field_with_type))
                if isinstance(value, list) or isinstance(value, dict):
                    value = json.dumps(value, cls=CustomEncoder)
                values.append(value)

            # Insert data into PostgreSQL
            pg_cur.execute(sql.SQL("INSERT INTO {} ({}) VALUES ({})").format(
                sql.Identifier(collection_name),
                sql.SQL(', ').join(fields),
                sql.SQL(', ').join(sql.Placeholder() * len(values))),
                values)

pg_cur.close()
pg_conn.close()

This script simplifies the migration process by automating many of the essential tasks.

Data Transformation and Beyond

Making the Transition

With your connection set up and tables created, it's time to dive into the heart of the migration process - transforming MongoDB documents into PostgreSQL rows. This step is pivotal for a successful migration and ensuring that your data remains intact.

The Data Transformation Journey

The journey of transforming your data from MongoDB to PostgreSQL is where the magic happens. MongoDB and PostgreSQL have distinct data models, which means a meticulous transformation process is crucial. We won't just guide you through this journey; we'll take you on a hands-on tour with detailed code samples and explanations.

Code in Action

Our approach is all about clarity and understanding. We provide code samples that vividly showcase the transformation of MongoDB data into a PostgreSQL-compatible format. Each sample is accompanied by a comprehensive explanation, ensuring that you not only get the job done but also understand the underlying nuances and intricacies.

Exploring Alternatives

While our primary focus has been on migrating from MongoDB to PostgreSQL, it's always a good practice to explore alternative solutions. One compelling alternative is FerretDB, a MongoDB-like database using PostgreSQL that can be hosted within the Supabase ecosystem. Depending on your specific requirements and preferences, this might be an excellent choice to consider.

Handling Challenges

Migration projects often encounter unexpected challenges. It's essential to acknowledge that no migration process is entirely free of hurdles. While we've covered a broad spectrum of challenges and provided solutions, unique scenarios may require specialized attention. In such cases, it's advisable to seek professional guidance to ensure a seamless migration experience.

Post-Migration Considerations

With your data successfully migrated to PostgreSQL through Supabase, let's shift our focus to what comes next - ensuring your database performs optimally and reliably.

Data Validation and Optimization

After completing the migration, your first priority should be data validation and testing. It's not just about getting your data into the new system; it's about making sure it made the transition accurately and retains its integrity. Learn about best practices and available tools for this crucial step. We'll guide you through the process, leaving no room for uncertainty.

Unleashing PostgreSQL's Power

To fully harness the capabilities of PostgreSQL, it's essential to optimize your database's performance. This section is a treasure trove of insights into key areas like indexing, query optimization, and other relevant topics. Discover how to fine-tune your database for optimal speed and efficiency, ensuring that your application runs smoothly.

Conclusion

In conclusion, migrating from MongoDB to Supabase with PostgreSQL can be a transformative step for your application. We've covered crucial stages, from understanding the advantages of this transition to handling post-migration considerations. Please note that this is an initial effort migrating from live connections and is not performant at this time. I am also working on an alternative migration guide from mongodump to Postgres in this GitHub repo. Contributions are very welcome.

Additional Resources

To further assist you in your migration journey, here are some additional resources:

• Supabase Documentation: Explore Supabase's official documentation for in-depth information and guidance.

• PostgreSQL Official Documentation: Dive into the official PostgreSQL documentation to expand your knowledge of this powerful database system.

• GitHub Repository with Migration Code Samples: Access our GitHub repository, where you can find detailed code samples and resources related to the migration process.

Feel free to explore these resources as you embark on your journey to a more efficient and robust database solution. Happy migration!

Rate limiting is a critical aspect of web applications that ensures fair usage of resources and prevents abuse. In this blog post, we'll explore how to implement rate limiting for Supabase requests using PostgreSQL and the pg_headerkit extension. This article is part of a series on optimizing Supabase performance, and it builds upon our previous guide on Boosting Supabase Reliability.

Supabase, a powerful backend platform built on top of PostgreSQL, relies on PostgreSQL as its underlying database. By leveraging PostgreSQL and pg_headerkit, we can efficiently control the rate at which requests are made to Supabase, ensuring optimal performance and resource allocation.

Prerequisites

Before we dive into the implementation, make sure you have the following prerequisites:

1. Supabase Project: Ensure you have an existing Supabase project with the necessary API endpoints set up.

2. PostgreSQL Database: Use PostgreSQL as your backend database for Supabase. If you haven't set up PostgreSQL with Supabase yet, follow the official documentation to get started.

3. pg_headerkit: You will need to install the pg_headerkit library. Find installation instructions and more information on this library at https://database.dev/burggraf/pg_headerkit.

Setting up the Environment

Before we dive into rate limiting, let's ensure we have the necessary prerequisites in place:

1. Supabase Account: Make sure you have a Supabase account set up.

2. Database.dev: Install dbdev using https://database.dev/installer.

Next, let's install and set up pg_headerkit:

SELECT dbdev.install('burggraf-pg_headerkit');
CREATE EXTENSION "burggraf-pg_headerkit" VERSION '1.0.0';

Creating the Rate Limiting Infrastructure

In this section, we'll dive into the process of creating the essential infrastructure for rate limiting within your Supabase-powered application. Rate limiting is a crucial mechanism that allows you to control the number of requests made to your Supabase endpoints, ensuring fair usage of resources and maintaining system stability.

The request_log Table

We begin with the creation of the request_log table. This table serves as a main component for tracking and monitoring incoming requests. Here's how we set it up:

CREATE UNLOGGED TABLE request_log (
  id BIGINT NOT NULL primary key,
  ip inet NOT NULL,
  timestamp timestamptz DEFAULT NOW()
);

CREATE UNLOGGED SEQUENCE request_log_id_seq    
    START WITH 1
    INCREMENT BY 1
    NO MINVALUE
    NO MAXVALUE
    CACHE 1;

ALTER TABLE request_log ALTER COLUMN id SET DEFAULT nextval('request_log_id_seq');

The request_log table has three essential columns:

• id: A unique identifier for each log entry, automatically generated.

• ip: This column captures the client's IP address, helping us identify the source of each request.

• timestamp: It records the exact time each request was made, ensuring accurate tracking.

The register_request Function

With the request_log table in place, we proceed to create the register_request function. This function plays a pivotal role in the rate-limiting process by logging every incoming request and associating it with the client's IP address. Here's how it's defined:

CREATE OR REPLACE FUNCTION register_request(ip_in TEXT) 
RETURNS VOID 
LANGUAGE plpgsql AS $$
BEGIN
  INSERT INTO request_log (ip) 
  VALUES (inet(ip_in));
END;
$$;

The register_request function takes the client's IP address as input and inserts a corresponding entry into the request_log table. This action ensures that we have a comprehensive record of all incoming requests, which is essential for rate limiting and analytics.

With the infrastructure for tracking requests established, we're now ready to move forward with the rate-limiting implementation. In the following sections, we'll explore how to set rate limits and enforce them effectively.

Cleaning Old Requests

To maintain the efficiency of our system, it's crucial to regularly clean up old request logs. The clean_old_requests function takes care of this task:

CREATE OR REPLACE FUNCTION clean_old_requests() 
RETURNS VOID 
LANGUAGE plpgsql AS $$
BEGIN
  -- Delete request logs older than 12 hours
  DELETE FROM request_log 
  WHERE timestamp < NOW() - INTERVAL '12 hours';
END;
$$;

This function ensures that our database remains clutter-free and retains only the most relevant request data.

Implementing Rate Limiting

Now, let's delve into implementing rate limiting within our Supabase-powered application. Rate limiting is essential to prevent abuse and ensure fair resource allocation. We achieve this through the exceeded_rate_limit and check_rate_limit functions.

The exceeded_rate_limit Function

The exceeded_rate_limit function is responsible for checking if a client has exceeded the rate limit, which in this example is set at 5 requests per minute. Here's how it's defined:

CREATE OR REPLACE FUNCTION exceeded_rate_limit(ip_in TEXT) 
RETURNS BOOLEAN 
LANGUAGE plpgsql AS $$
DECLARE
  request_count INTEGER;
BEGIN
  SELECT count(*) INTO request_count 
  FROM request_log 
  WHERE ip = inet(ip_in) AND timestamp > NOW() - INTERVAL '1 minute';

  RETURN request_count >= 5; -- limit of 5 requests per minute
END;
$$;

This function counts the number of requests made by a client within the last minute and returns true if the limit is exceeded.

The check_rate_limit Function

The check_rate_limit function is pivotal for enforcing rate limits. It effectively manages rate limiting by logging the current request using the register_request function and verifying if the rate limit has been surpassed. If the limit is exceeded, it raises an exception:

CREATE OR REPLACE FUNCTION check_rate_limit() 
RETURNS VOID 
LANGUAGE plpgsql 
SET search_path = public, hdr, extensions
SECURITY DEFINER
AS $$
DECLARE 
  current_ip TEXT := hdr.ip();
  request_method TEXT := current_setting('request.method', TRUE);
BEGIN
  -- Only log requests that are not GET or HEAD because they are run
  -- in read-only transactions
  IF request_method IS NULL OR request_method NOT IN ('GET', 'HEAD') THEN
    PERFORM register_request(current_ip);
  END IF;

  -- Check if the rate limit has been exceeded 
  -- and raise an exception if necessary
  IF exceeded_rate_limit(current_ip) THEN
    RAISE EXCEPTION 'Rate limit exceeded';
  END IF;
END;
$$;

This function is a crucial component of your rate-limiting strategy, ensuring that each incoming request is correctly monitored and preventing clients from exceeding their allocated rate limits. It's important to note that this function primarily focuses on rate limiting for insert operations. While rate limiting for GET requests is possible, it may introduce performance concerns, such as making network requests that insert rate-limiting data.

Configuring pg_headerkit with PostgREST

To seamlessly integrate rate limiting with your Supabase-powered application, configure the pgrst.db_pre_request option to utilize the check_rate_limit function as a pre-request action within PostgREST:

ALTER ROLE authenticator 
SET pgrst.db_pre_request = 'check_rate_limit';
NOTIFY pgrst, 'reload config';

This configuration ensures that every request made to Supabase undergoes rate limit validation before execution, guaranteeing a fair and controlled usage of resources. Now, we can test the rate limit by sending a few post requests to a table:

Scheduled Cleanup

Maintaining the performance of your database requires periodic cleanup of old request logs. Schedule the clean_old_requests function to run automatically every midnight:

SELECT cron.schedule(
  'clean_old_requests',
  '0 0 * * *', -- Run every midnight
  $$ SELECT clean_old_requests(); $$
);

This automated cleanup process is crucial for keeping your database in an optimal state, free from unnecessary clutter, and ensuring efficient resource management.

Conclusion

In this comprehensive blog post, we've delved into the intricacies of implementing rate limiting for your Supabase-powered applications. Leveraging the power of PostgreSQL and the versatile pg_headerkit extension, we've provided you with a step-by-step guide to ensure fair resource allocation and safeguard your application against abuse.

Rate limiting is a fundamental tool in your arsenal to maintain top-notch performance and deliver a consistently excellent user experience. Armed with the knowledge gained from this article, you're now well-prepared to seamlessly integrate rate limiting into your Supabase application.

Don't stop here; take the concepts discussed in this post and adapt them to your specific use cases. Experiment, explore, and fine-tune your rate-limiting strategy to perfectly align with your application's unique requirements.

If you found this article valuable, you might also be interested in exploring related topics:

• Boosting Supabase Reliability: A Guide to Using Postgres Foreign Data Wrappers: Learn how to enhance the reliability of your Supabase applications.

• Exploring Data Relationships with Supabase and PostgreSQL: Dive deeper into understanding data relationships in Supabase.

• Safeguarding Data Integrity with pg-safeupdate in PostgreSQL and Supabase: Explore techniques to maintain data integrity in your database.

For further information and guidance, consider these valuable references. For any questions, feedback, or assistance, please don't hesitate to reach out to me. We're here to help you on your journey to mastering rate limiting in Supabase.

References

For further information and guidance, consider these valuable references:

• Supabase Official Documentation: Explore Supabase's official documentation for in-depth insights into this powerful backend platform.

• PostgreSQL Official Documentation: Dive into the official documentation of PostgreSQL, the robust database system at the core of Supabase.

• pg_headerkit Extension: For more details on pg_headerkit, visit the official GitHub repository.

• PostgREST Official Documentation: Discover PostgREST's documentation for additional information on this helpful tool.

The Nexus of Empowerment: An Alliance of Supabase and PostgreSQL

In the dynamic realm of modern application development, the selection of a backend service extends beyond technical considerations; it's a strategic choice with far-reaching implications for productivity and efficiency. The formidable partnership between Supabase and PostgreSQL presents a compelling proposition. This article delves into the realm of webhooks—automated triggers designed to spring into action in response to specific database events. Our journey involves an in-depth exploration of the intricacies involved in designing and debugging Postgres webhooks, harnessing the capabilities of Supabase to establish a fluid and efficient workflow.

Expanding Horizons: The Webhook Wrapper Function

At the heart of our webhook implementation, a pivotal role is played by the request_wrapper function. This versatile function operates as an intermediary, adroitly handling HTTP methods such as GET, POST, and DELETE. It forges smooth communication channels with external services and APIs, driven by dynamic input parameters encompassing method, url, params, body, and headers. Crafted using the expressive plpgsql language and fortified by the security definer concept for meticulous execution control, this function embodies the quintessence of streamlined automation.

Taking Charge of Your Automation: The Supabase Advantage

While Supabase generously offers webhooks as part of its toolkit, it is worth contemplating the merits of deploying them independently. By taking the reins of deployment, you gain the freedom to expand the timeout window, granting you greater control over the nature of the requests being executed. This strategic move allows you to tailor the automation to your specific needs, resulting in a more responsive and versatile system.

-- 
-- Webhook wrapper
--
CREATE OR REPLACE FUNCTION request_wrapper(
    method TEXT,
    url TEXT,
    params JSONB DEFAULT '{}'::JSONB,
    body JSONB DEFAULT '{}'::JSONB,
    headers JSONB DEFAULT '{}'::JSONB
)
RETURNS BIGINT
SECURITY DEFINER
SET search_path = public, extensions, net
LANGUAGE plpgsql
AS $$
DECLARE
    request_id BIGINT;
    timeout INT;
BEGIN
    timeout := 3000;

    IF method = 'DELETE' THEN
        SELECT net.http_delete(
            url:=url,
            params:=params,
            headers:=headers,
            timeout_milliseconds:=timeout
        ) INTO request_id;
    ELSIF method = 'POST' THEN
        SELECT net.http_post(
            url:=url,
            body:=body,
            params:=params,
            headers:=headers,
            timeout_milliseconds:=timeout
        ) INTO request_id;
    ELSIF method = 'GET' THEN
        SELECT net.http_get(
            url:=url,
            params:=params,
            headers:=headers,
            timeout_milliseconds:=timeout
        ) INTO request_id;
    ELSE
        RAISE EXCEPTION 'Method must be DELETE, POST, or GET';
    END IF;
    RETURN request_id;
END;
$$;

Creating a Trigger Function for Automated Insert Events

Imagine a scenario where a new row enters the picture in the orders table. This particular moment sets in motion an automatic process triggered by a special function we've named after_order_insert(). Within this function's code lies a sophisticated logic that effortlessly triggers a call to another function called request_wrapper. This dynamic function orchestrates a POST request that's directed to a specific webhook URL you define. The magic happens as the values from the newly added row come together to form a JSON package—an essential element that shapes the upcoming webhook request.

CREATE OR REPLACE FUNCTION after_order_insert()
RETURNS TRIGGER AS $$
BEGIN
    PERFORM request_wrapper('POST', 'your_webhook_url_here', 
                            '{"order_id": ' || NEW.order_id || 
                            ', "customer_id": ' || NEW.customer_id || 
                            ', "total_amount": ' || NEW.total_amount || '}');
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Leading the Way with Triggers: Powering Automation for New Inserts

In the dynamic realm of PostgreSQL databases, the birth of triggers stands as a foundational pillar of database event automation. Our carefully crafted trigger, given the name orders_insert_webhook, steps onto the stage. This conductor is designed to harmonize with the rhythm of each fresh row that finds its place in the revered orders table. This invisible maestro then coordinates the execution of the after_order_insert() function as soon as a new data insertion event occurs. The result is a symphony of seamless coordination, allowing webhooks to come to life in response to the emergence of new data.

CREATE TRIGGER orders_insert_webhook
AFTER INSERT ON orders
FOR EACH ROW
EXECUTE FUNCTION after_order_insert();

Exploring Webhook Debugging: A Closer Look

The journey through webhook integration entails not only implementation but also a vital debugging phase. This phase ensures the smooth functioning of your automated processes. At the core of this endeavor lies the net._http_response table—a valuable tool for debugging. This table captures the responses generated by HTTP requests executed through the request_wrapper function. It offers insights into request outcomes, including success, status codes, headers, content, timeouts, error messages, and creation timestamps.

Navigating the Debugging Process: Inside net._http_response

In your PostgreSQL database architecture, the net._http_response table takes on a crucial role. Its design encapsulates essential debugging information, aiding you in refining your automated workflows. This table serves as a repository of records detailing each HTTP request's journey. These insights are invaluable for diagnosing and resolving any issues in your automation processes. From tracking response status and content type to examining headers, content, and possible timeouts, this table becomes your compass in the journey to create robust and efficient automation.

Real-World Insight: Practical Scenarios

To understand the practicality of the net._http_response table, let's consider an example where you've set up a webhook to notify customers upon order fulfillment. As you navigate this process, the net._http_response table becomes your ally.

Use Case 1: Checking Request Status

To verify request status, execute the following query:

SELECT id, status_code, timed_out
FROM net._http_response;

This query offers a quick overview of request details, displaying IDs, status codes, and any timeouts.

Use Case 2: Exploring Request Details

For a comprehensive view of a specific request, use:

SELECT *
FROM net._http_response
WHERE id = your_request_id_here;

Replace your_request_id_here with the actual ID of the request. This query provides a detailed examination, including headers, content, and error messages.

In the process of webhook debugging, the net._http_response table shines as a guiding light. Its insights empower you to craft and maintain automation processes that endure.

-- Example: Checking request status
SELECT id, status_code, timed_out
FROM net._http_response;

-- Example: Exploring request details
SELECT *
FROM net._http_response
WHERE id = your_request_id_here;

Wrapping Up: Your Path to Smarter Automation

As we come to the end of this exploration into the world of automation and efficiency in app development, it's time to reflect on the journey we've taken. Throughout this article, we've teamed up Supabase and PostgreSQL with webhooks—a powerful trio that empowers you to create smarter, more responsive applications.

If you're hungry for more insights and want to delve deeper into enhancing your Supabase-powered apps, don't forget to check out some of our previous articles:

• Wondering how to make your Supabase setup even more reliable? Dive into our guide on Boosting Supabase Reliability with Postgres Foreign Data Wrappers.

• Exploring data relationships in Supabase and PostgreSQL? Learn the ropes with our article on Exploring Data Relationships with Supabase and PostgreSQL.

• Need to empower your users with secure password verification? Our insights on Secure Password Verification and Update with Supabase and PostgreSQL have got you covered.

With these resources at your fingertips, you're well-equipped to take your app development journey to new heights. Remember, the world of coding is full of possibilities, and webhooks are just the beginning. Keep innovating, keep learning, and keep coding!

Got any thoughts or questions? We'd love to hear from you. Drop a comment below and let's keep the conversation going!

Introduction

As the demand for efficient backend solutions continues to grow, Supabase has emerged as a game-changer. Offering features like real-time subscriptions, authentication, and database management, Supabase simplifies complex backend tasks. However, one unique challenge lies in customizing email templates for user engagement. In our previous blog post on Exploring Data Relationships with Supabase and PostgreSQL, we delved into the intricacies of data relationships. Building upon that foundation, we now tackle the challenge of creating a personalized authentication email system that also seamlessly supports i18n localization.

The Significance of i18n Localization in Emails

In today's global landscape, catering to diverse audiences is imperative for enhancing user engagement. Internationalization (i18n) ensures that emails resonate with users across various cultures and languages. By dynamically replacing content based on the user's preferred language, we not only enhance the user experience but also foster a sense of inclusivity.

Prerequisites

Before we dive into the technical intricacies, it's essential to be well-acquainted with Supabase, PostgreSQL, and have a grasp of the basics of Deno if necessary. Setting up your development environment, installing essential tools, and configuring dependencies based on your operating system will establish a solid foundation for a successful implementation.

Establishing a Solid Database Foundation

Our journey begins with the establishment of a robust database foundation. This involves the creation of an email_templates table within an internal schema. This table serves as a pivotal repository, storing vital information such as subject lines, content, languages, and template types.

CREATE SCHEMA internal;

CREATE TABLE internal.email_templates (
  id BIGINT GENERATED BY DEFAULT AS IDENTITY,
  subject TEXT NULL,
  content TEXT NULL,
  email_language TEXT NULL,
  email_type TEXT NULL,
  CONSTRAINT email_templates_pkey PRIMARY KEY (id)
);

By crafting this strong foundation, we lay the groundwork for a dynamic and versatile email system. This system will be powered by the forthcoming get_email_template function, which we'll explore in the following sections.

Crafting the Dynamic get_email_template Function

The core of our email system resides within the get_email_template function. This dynamic function retrieves email templates, utilizing inputs such as the template type, link, and language. Importantly, the function seamlessly integrates with the email_templates table, providing personalized email content.

CREATE OR REPLACE FUNCTION get_email_template(
  template_type TEXT,
  link TEXT,
  language TEXT DEFAULT 'en'
)
RETURNS JSON
SECURITY DEFINER
SET search_path = public, internal AS
$BODY$
DECLARE
  email_subject TEXT;
  email_content TEXT;
  email_json JSON;
BEGIN
  SELECT subject, REPLACE(content, '{{LINK}}', link) INTO email_subject, email_content
  FROM internal.email_templates
  WHERE email_type = template_type AND email_language = language;
  email_json := json_build_object('subject', email_subject, 'content', email_content);
  RETURN email_json;
END;
$BODY$
LANGUAGE plpgsql;
-- Protect this function to be only available to service_role key:
REVOKE EXECUTE ON FUNCTION get_email_template from public;
REVOKE EXECUTE ON FUNCTION get_email_template FROM anon, authenticated;

Customizing Email Templates for Common Authentication Scenarios

To enhance user experience and engagement, we'll be customizing email templates for several common authentication scenarios: password recovery, signup confirmation, invitation, and magic link.

These templates will be available in three languages: Portuguese, English, and Danish. You can seamlessly integrate these templates into the email_templates table within the internal schema. Below, you'll find the templates for each scenario:

--
-- Data for Name: email_templates; Type: TABLE DATA; Schema: internal; Owner: postgres
--

INSERT INTO "internal"."email_templates" ("id", "subject", "content", "email_language", "email_type") VALUES
    (1, 'Din Magisk Link', '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<meta http-equiv="Content-Type" content="text/html charset=UTF-8" />
<html lang="da">
<head></head>
<body style="background-color:#ffffff;font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,Roboto,Oxygen-Sans,Ubuntu,Cantarell,&quot;Helvetica Neue&quot;,sans-serif">
    <table align="center" role="presentation" cellSpacing="0" cellPadding="0" border="0" width="100%" style="max-width:37.5em;margin:0 auto;padding:20px 25px 48px;background-image:url(&quot;/assets/background-image.png&quot;);background-position:bottom;background-repeat:no-repeat, no-repeat">
        <tr style="width:100%">
            <td>
                <h1 style="font-size:28px;font-weight:bold;margin-top:48px">🪄 Din magiske link</h1>
                <table style="margin:24px 0" align="center" border="0" cellPadding="0" cellSpacing="0" role="presentation" width="100%">
                    <tbody>
                        <tr>
                            <td>
                                <p style="font-size:16px;line-height:26px;margin:16px 0"><a target="_blank" style="color:#FF6363;text-decoration:none" href="{{LINK}}">👉 Klik her for at logge ind 👈</a></p>
                                <p style="font-size:16px;line-height:26px;margin:16px 0">Hvis du ikke har anmodet om dette, bedes du ignorere denne e-mail.</p>
                            </td>
                        </tr>
                    </tbody>
                </table>
                <p style="font-size:16px;line-height:26px;margin:16px 0">Bedste hilsner,<br />- Contoso Team</p>
                <hr style="width:100%;border:none;border-top:1px solid #eaeaea;border-color:#dddddd;margin-top:48px" />
                <p style="font-size:12px;line-height:24px;margin:16px 0;color:#8898aa;margin-left:4px">Contoso Technologies Inc.</p>
            </td>
        </tr>
    </table>
</body>
</html>
', 'da', 'magiclink');

-- Check the full SQL file and all templates in the GitHub repo
-- https://github.com/mansueli/Supabase-Edge-AuthMailer

By offering tailored templates for these scenarios in multiple languages, you ensure that your email communications resonate with a broader audience. This personalization fosters stronger user engagement and interaction.

Developing the Deno Edge Function (index.ts)

In the upcoming section, we'll delve into the development process of the Deno Edge Function responsible for managing authentication email requests. Below, we'll provide an overview of the pivotal steps involved in this process:

1. Initializing Imports and Constants: We'll commence by importing essential modules and setting up constants that will facilitate the seamless development process.

2. Creating a Secure Supabase Client: Learn how to establish a secure connection to Supabase using admin credentials, ensuring authorized access to the required resources.

3. Handling Incoming HTTP Requests: Discover the utilization of the serve function to effectively handle incoming HTTP requests, enhancing the overall responsiveness of your system.

4. Extracting Vital Parameters: Understand the process of extracting crucial parameters from incoming requests, such as email, authentication type, language, password, and redirection URL.

5. Generating Secure Authentication Links: Explore the steps involved in generating secure authentication links using the Supabase admin API, facilitating secure user interactions.

6. Customizing Redirection Links: Learn how to customize redirection links to match specific requirements and elevate the user experience.

7. Invoking get_email_template Function: Dive into the usage of the Supabase rpc method to invoke the get_email_template function, enabling seamless retrieval of email content.

8. Integration of Resend API: Understand the seamless integration of the Resend API, allowing the delivery of personalized and informative emails to users.

For the complete code of the Deno Edge Function, refer to the provided index.ts file.

// Importing required libraries
import { serve } from 'https://deno.land/std@0.192.0/http/server.ts'
import { createClient } from 'https://esm.sh/@supabase/supabase-js@2'

// Defining CORS headers
export const corsHeaders = {
  'Access-Control-Allow-Origin': '*',
  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
}

// Log to indicate the function is up and running
console.log(`Function "auth-mailer" up and running!`)

// Creating a Supabase client using environment variables
const supabaseAdmin = createClient(
  Deno.env.get('SUPABASE_URL') ?? '',
  Deno.env.get('SUPABASE_SERVICE_ROLE_KEY') ?? ''
)

// Define a server that handles different types of requests
serve(async (req: Request) => {
  // Handling preflight CORS requests
  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  try {
    // Destructuring request JSON and setting default values
    let { email, type, language = 'en', password = '', redirect_to = '' } = await req.json();
    console.log(JSON.stringify({ email, type, language, password }, null, 2));

    // Generate a link with admin API call
    let linkPayload: any = {
      type,
      email,
    }

    // If type is 'signup', add password to the payload
    if (type == 'signup') {
      linkPayload = {
        ...linkPayload,
        password,
      }
      console.log("linkPayload", linkPayload);
    }

    // Generate the link
    const { data: linkResponse, error: linkError } = await supabaseAdmin.auth.admin.generateLink(linkPayload)
    console.log("linkResponse", linkResponse);

    // Throw error if any occurs during link generation
    if (linkError) {
      throw linkError;
    }

    // Getting the actual link and manipulating the redirect link
    let actual_link = linkResponse.properties.action_link;
    if (redirect_to != '') {
      actual_link = actual_link.split('redirect_to=')[0];
      actual_link = actual_link + '&redirect_to=' + redirect_to;
    }

    // Log the template data
    console.log(JSON.stringify({ "template_type":type, "link": linkResponse, "language":language }, null, 2));

    // Get the email template
    const { data: templateData, error: templateError } = await supabaseAdmin.rpc('get_email_template', { "template_type":type, "link": actual_link, "language":language });

    // Throw error if any occurs during template fetching
    if (templateError) {
      throw templateError;
    }

    // Send the email using resend
    const RESEND_API_KEY = Deno.env.get('RESEND_API_KEY')
    const resendRes = await fetch('https://api.resend.com/emails', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${RESEND_API_KEY}`,
      },
      body: JSON.stringify({
        from: 'rodrigo@mansueli.com',
        to: email,
        subject: templateData.subject,
        html: templateData.content,
      }),
    });

    // Handle the response from the resend request
    const resendData = await resendRes.json();
    return new Response(JSON.stringify(resendData), {
      status: resendRes.status,
      headers: {
        'Content-Type': 'application/json',
      },
    })
  } catch (error) {
    // Handle any other errors
    return new Response(JSON.stringify({ error: error.message }), {
      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
      status: 400,
    })
  }
})

Addressing Supabase Email Template Behavior

It's essential to acknowledge a particular behavior of Supabase when handling email templates. By default, Supabase removes HTML tags from email templates when using the platform's default templates. The approach we present here allows you to exercise control over the visual presentation of your email content. To effectively include HTML elements in your email templates, you can adhere to standard HTML practices.

Conclusion and Future Enhancements

Congratulations on successfully constructing a personalized authentication email system using Supabase Edge Functions, PostgreSQL, and the Resend service. By harnessing the capabilities of Supabase, you've streamlined the process of delivering tailored authentication emails to your users.

While this tutorial covers the foundational aspects, there's always room for growth. Consider expanding the range of email template customization or integrating additional third-party services to elevate user engagement. As you continue exploring Supabase's capabilities, share your insights and enhancements with the open-source community.

You can find the complete code used in this article on GitHub.

Further Learning Resources

For additional learning, we recommend exploring the following resources:

• Official Supabase Documentation

• PostgreSQL Documentation

• Deno Official Website

• Resend API Documentation

Prerequisites for Implementing FDWs

To embark on this journey, it's essential to have the following prerequisites in place.

1. Main Supabase Project: You should have your primary Supabase project set up and operational. This serves as the foundation upon which we'll build the enhanced system.

2. Foreign Supabase Project: Similarly, your separate foreign Supabase project needs to be ready. This distinct database will be integrated using the Foreign Data Wrappers approach.

Before proceeding, ensure these prerequisites are aligned to make the most of this guide.

Exploring the Process: The process we're about to undertake involves creating a bridge between your main Supabase project and the foreign Supabase project through the magic of Foreign Data Wrappers. This bridge facilitates communication and data sharing between the projects, offering enhanced reliability and isolation.

Create a User in the Foreign Database:

In this crucial step, we lay the foundation for secure communication. By creating a dedicated user 'foreign_user' and granting it specific privileges, we establish the necessary credentials to bridge the databases. The use of BYPASSRLS ensures controlled data access.

CREATE USER foreign_user WITH PASSWORD 'password' BYPASSRLS;

GRANT USAGE 
ON SCHEMA public 
TO foreign_user;

GRANT SELECT, INSERT, UPDATE, DELETE 
ON ALL TABLES IN SCHEMA public 
TO foreign_user;

GRANT USAGE, SELECT 
ON ALL SEQUENCES IN SCHEMA public 
TO foreign_user;

Configuration in the Main Database:

This step involves configuring your main Supabase database to communicate with the foreign server. We set up a new schema 'queue' to house the imported foreign data. Additionally, we establish a foreign server named 'foreign_server,' specifying connection details like host, port, and dbname. The user mapping ensures secure authentication, while the IMPORT FOREIGN SCHEMA command integrates the foreign schema into your main database.

CREATE EXTENSION postgres_fdw;
CREATE SCHEMA queue;

ALTER DEFAULT PRIVILEGES IN SCHEMA queue
GRANT ALL ON TABLES TO postgres;

CREATE SERVER foreign_server
    FOREIGN DATA WRAPPER postgres_fdw
    OPTIONS (host 'db.foreign.supabase.co', port '5432', dbname 'postgres');

CREATE USER MAPPING FOR postgres
    SERVER foreign_server
    OPTIONS (user 'foreign_user', password 'password');

IMPORT FOREIGN SCHEMA public
    FROM SERVER foreign_server
    INTO queue;

ALTER SERVER foreign_server 
    OPTIONS (fetch_size '50000');

Explaining fetch_size Adjustment: The ALTER SERVER command with the fetch_size option plays a vital role in optimizing data retrieval. By setting the fetch size to '50000,' we dictate how many rows of data the server fetches in a single request. Larger fetch sizes can enhance data retrieval efficiency, especially when dealing with substantial datasets.

Enhancing Queue Reliability: This approach not only boosts the reliability of your main Supabase project but also increases the robustness of your queue system. To understand more about creating a queue system using Supabase and PostgreSQL, refer to the article Building a Queue System with Supabase and PostgreSQL.

Conclusion

By meticulously following these steps, you pave the way for a robust, interconnected Supabase ecosystem. The integration of Foreign Data Wrappers fosters reliability, ensuring that the queue system remains resilient even in the face of challenges.

Don't hesitate to explore the Supabase documentation, which offers a wealth of knowledge on database extensions and their applications.

Supabase, the potent open-source platform, brings you real-time and secure backend-as-a-service capabilities, leveraging the power of PostgreSQL. Uncover the art of managing data relationships effectively using Supabase and PostgreSQL.

Utilizing Foreign Keys to Establish Table Links

The foundation of dynamic and efficient applications lies in robust and interconnected databases. One crucial technique for achieving this is harnessing the potential of foreign keys to establish relationships between database tables. Let's delve into how you can leverage foreign keys for linking tables and executing advanced JOIN queries.

Creating Tables for Demonstrating JOIN Queries

Before we plunge into data relationships, let's kick things off by setting up the required database tables. Our example involves five distinct tables: books, publishers, translations, teachers, and courses. Each table serves a unique purpose in our application. For instance, the books table stores book details, the publishers table holds publisher information, and the translations table tracks book translations.

CREATE TABLE books (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    title TEXT NOT NULL,
    author TEXT NOT NULL
);

CREATE TABLE publishers (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    book_id INTEGER,
    name TEXT NOT NULL,
    published_date DATE,
    FOREIGN KEY (book_id) REFERENCES books(id)
);

CREATE TABLE translations (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    book_id INTEGER,
    language TEXT NOT NULL,
    translator TEXT,
    FOREIGN KEY (book_id) REFERENCES books(id)
);

Here's a glimpse of example insert statements:

INSERT INTO books (title, author) VALUES
    ('The Great Gatsby', 'F. Scott Fitzgerald'),
    ('To Kill a Mockingbird', 'Harper Lee'),
    ('1984', 'George Orwell'),
    ('Pride and Prejudice', 'Jane Austen'),
    ('The Hobbit', 'J.R.R. Tolkien'),
    ('Harry Potter and the Sorcerer''s Stone', 'J.K. Rowling'),
    ('The Catcher in the Rye', 'J.D. Salinger'),
    ('Lord of the Flies', 'William Golding'),
    ('The Chronicles of Narnia', 'C.S. Lewis'),
    ('Brave New World', 'Aldous Huxley');
INSERT INTO publishers (book_id, name, published_date) VALUES
    (1, 'Scribner', '1925-04-10'),
    (2, 'HarperCollins', '1960-07-11'),
    (3, 'Secker & Warburg', '1949-06-08'),
    (4, 'T. Egerton, Whitehall', '1813-01-28'),
    (5, 'Allen & Unwin', '1937-09-21'),
    (6, 'Bloomsbury', '1997-06-26'),
    (7, 'Little, Brown', '1951-07-16'),
    (8, 'Faber and Faber', '1954-09-17'),
    (9, 'Geoffrey Bles', '1950-10-16'),
    (10, 'Chatto & Windus', '1932-06-23');
INSERT INTO translations (book_id, language, translator) VALUES
    (1, 'French', 'Maurice Ravel'),
    (1, 'German', 'Franz Kafka'),
    (2, 'Spanish', 'Gabriel García Márquez'),
    (2, 'Italian', 'Italo Calvino'),
    (3, 'Russian', 'Yevgeny Zamyatin'),
    (3, 'Chinese', 'Lu Xun'),
    (4, 'Japanese', 'Haruki Murakami'),
    (4, 'Korean', 'Shin Kyung-sook'),
    (5, 'Spanish', 'Jorge Luis Borges'),
    (5, 'Arabic', 'Naguib Mahfouz');

Performing JOIN Queries Using Supabase-JS

Unlock the ability to combine data from multiple tables with inner joins, using the Supabase-JS JavaScript library. This user-friendly tool simplifies database querying and inner join operations, ensuring a seamless experience.

To seamlessly perform an inner join using Supabase-JS, leverage the select method while specifying the desired columns for retrieval. Consult the Supabase documentation for comprehensive guidance on working with Supabase-JS.

With the groundwork laid for data relationships through foreign keys, let's delve into practical examples of executing JOIN queries using Supabase-JS.

Basic JOIN Operation: Connecting Books and Publishers Tables

Here's a fundamental JOIN operation between the books and publishers tables with this JavaScript code snippet:

const { data, error } = await supabase  
      .from('books')
      .select('*,publishers(*)');
/* Example response:
[
  {
    "id": 1,
    "title": "The Great Gatsby",
    "author": "F. Scott Fitzgerald",
    "publishers": [
      {
        "id": 1,
        "book_id": 1,
        "name": "Scribner",
        "published_date": "1925-04-10"
      }
    ]
  },
  {
    "id": 2,
    "title": "To Kill a Mockingbird",
    "author": "Harper Lee",
    "publishers": [
      {
        "id": 2,
        "book_id": 2,
        "name": "HarperCollins",
        "published_date": "1960-07-11"
      }
    ]
  }
]

The outcome of this query presents a unified view of books alongside their corresponding publishers.

Fine-Tuning Queries with Foreign Table Filters

Refine your queries by filtering based on attributes of the foreign table. Here's an illustrative example:

const { data, error } = await supabase
    .from('books')
    .select('*,publishers!inner(name,published_date)')
    .eq('publishers.name', 'Bloomsbury');

/* Example response:
[
  {
    "id": 6,
    "title": "Harry Potter and the Sorcerer's Stone",
    "author": "J.K. Rowling",
    "publishers": [
      {
        "name": "Bloomsbury",
        "published_date": "1997-06-26"
      }
    ]
  }
]

This query retrieves books published by "Bloomsbury" along with their corresponding details.

Uncover Insights with Foreign Table Count

You can also use JOINs to retrieve aggregate data from the foreign table. This example showcases counting translations for each book:

const { data, error } = await supabase
  .from('books')
  .select(`*, translations(count)`)
/* Example response:
[
  {
    "id": 1,
    "title": "The Great Gatsby",
    "author": "F. Scott Fitzgerald",
    "translations": [
      {
        "count": 2
      }
    ]
  },
  {
    "id": 2,
    "title": "To Kill a Mockingbird",
    "author": "Harper Lee",
    "translations": [
      {
        "count": 2
      }
    ]
  },
  {
    "id": 3,
    "title": "1984",
    "author": "George Orwell",
    "translations": [
      {
        "count": 2
      }
    ]
  }
]

This query returns the books along with the count of translations for each.

Anti-Joins by checking for nulls

It is possible to isolate the rows that are shared with the following approach:

supabase
  .from("books")
  .select("*,translations()")
  .is("translations", null)

Forging Relationships between Unrelated Tables

Discover a surprising capability: establishing connections between seemingly unrelated tables via the parent table:

const { data, error } = await supabase
    .from('books').select('publishers(*),translations(*)');
/* Example response:
[
  {
    "publishers": [
      {
        "id": 1,
        "book_id": 1,
        "name": "Scribner",
        "published_date": "1925-04-10"
      }
    ],
    "translations": [
      {
        "id": 1,
        "book_id": 1,
        "language": "French",
        "translator": "Maurice Ravel"
      },
      {
        "id": 2,
        "book_id": 1,
        "language": "German",
        "translator": "Franz Kafka"
      }
    ]
  },
  {
    "publishers": [
      {
        "id": 2,
        "book_id": 2,
        "name": "HarperCollins",
        "published_date": "1960-07-11"
      }
    ],
    "translations": [
      {
        "id": 3,
        "book_id": 2,
        "language": "Spanish",
        "translator": "Gabriel García Márquez"
      },
      {
        "id": 4,
        "book_id": 2,
        "language": "Italian",
        "translator": "Italo Calvino"
      }
    ]
  }
]

In this instance, we amalgamate data from the publishers and translations tables based on the intermediary books table, even without a direct link.

Exploring the Realm of Computed Relationships

Having mastered foreign keys and JOIN queries, let's elevate our understanding by venturing into computed relationships—a potent feature bestowed by Supabase and PostgreSQL. Computed relationships empower us to bridge gaps between tables and derive meaningful connections among data points.

Setting the Stage with Example Tables

To illustrate computed relationships, we'll create example tables planets and moons, showcasing how this advanced technique can enhance our data management.

-- Computed relationships:
CREATE TABLE planets (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name TEXT NOT NULL
);

CREATE TABLE moons (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    planet_id INTEGER,
    name TEXT NOT NULL
);

-- Relationship function (many to one):
CREATE FUNCTION planets(moons) RETURNS SETOF moons ROWS 1 AS $$
  SELECT * FROM moons WHERE id = $1.planet_id
$$ STABLE LANGUAGE SQL;

Let's add some rows to these tables to test out our computed relationships:

INSERT INTO planets (name) VALUES
    ('Mercury'),
    ('Venus'),
    ('Earth'),
    ('Mars'),
    ('Jupiter'),
    ('Saturn'),
    ('Uranus'),
    ('Neptune');
INSERT INTO moons (planet_id, name) VALUES
    (3, 'Moon'),
    (4, 'Phobos'),
    (4, 'Deimos'),
    (5, 'Io'),
    (5, 'Europa'),
    (5, 'Ganymede'),
    (5, 'Callisto'),
    (6, 'Titan'),
    (6, 'Enceladus'),
    (7, 'Titania');

Probing Computed Relationships

With the stage set, let's explore computed relationships using Supabase-JS. The following JavaScript snippet exemplifies querying a computed relationship between the moons and planets tables:

const { data, error } = await supabase
    .from('moons').select('*,planets(*)');
/* Example response:
[
  {
    "id": 1,
    "planet_id": 3,
    "name": "Moon",
    "planets": {
      "id": 3,
      "planet_id": 4,
      "name": "Deimos"
    }
  },
  {
    "id": 2,
    "planet_id": 4,
    "name": "Phobos",
    "planets": {
      "id": 4,
      "planet_id": 5,
      "name": "Io"
    }
  }
]
*/

The resulting response showcases the enhanced connections between moons and their parent planets.

Conclusion

We demonstrated the potential of Supabase-JS and PostgreSQL, propelling data management to new heights. From rudimentary JOIN queries to sophisticated computed relationships, these tools metamorphose serverless application data management. Armed with these techniques, developers wield the power to craft adaptable, efficient, and interlinked systems tailored to diverse data relationship scenarios.

Embark on your journey with Supabase and PostgreSQL, exploring further features, optimization tactics, and real-world application scenarios. The realm of data management awaits—harness its might with Supabase!

Stay tuned for more illuminating insights and enriching content in forthcoming blog posts.

Prerequisites

Before diving into this step-by-step tutorial, ensure you have the following prerequisites in place:

1. Deno: Deno is a secure runtime for JavaScript and TypeScript. Visit the official website for instructions on installing Deno.

2. Supabase Account: Create a free Supabase account if you haven't done so already. You'll require your Supabase URL and anonymous key for authentication.

3. PostgreSQL: Ensure you have PostgreSQL installed or set up a PostgreSQL database using Supabase.

To maximize your understanding of this tutorial, it's beneficial to have a basic grasp of Supabase, PostgreSQL, and HTTP requests.

Setting Up the Database

Let's begin by assuming you have one of the web app templates with a public.profile table. We'll specifically add a new column to the "profiles" table to indicate whether existing users are using magic links.

-- Setting the profiles table to indicate that existing users were using magic links
ALTER TABLE public.profiles 
ADD COLUMN auth_options text[] DEFAULT ARRAY['magiclink']::text[] NULL;

Implementing the Edge Function

The edge function plays a pivotal role in this integration as it verifies the user's authentication method (magic link or password) and updates the necessary information accordingly. Below is the Deno code for the edge function:

import { serve } from "https://deno.land/std@0.192.0/http/server.ts";
import { createClient } from "https://esm.sh/@supabase/supabase-js@2";

// CORS headers for allowing requests from any origin
const corsHeaders = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Headers":
    "authorization, x-client-info, apikey, content-type",
};

serve(async (req) => {
  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders });
  }

  // Creating a Supabase client with the provided authorization token
  const supabaseClient = createClient(
    Deno.env.get("SUPABASE_URL") ?? "",
    Deno.env.get("SUPABASE_ANON_KEY") ?? "",
    {
      global: { headers: { Authorization: req.headers.get("Authorization")! } },
      auth: {
        autoRefreshToken: false,
        persistSession: false,
        detectSessionInUrl: false
      }
    }
  );

  // Getting the user information from the provided authorization token
  const { data: { user }, error: userError } = await supabaseClient.auth.getUser();
  if (userError) {
    console.error("User error", userError);
    return new Response(JSON.stringify({ error: userError.message }), {
      headers: { ...corsHeaders, "Content-Type": "application/json" },
      status: 400,
    });
  }

  // Getting the current authentication options for the user from the profiles table
  const { data: auth_options, error: authError } = await supabaseClient.from('profiles').select('auth_options').eq('id', user.id);
  if (authError) {
    console.error("Auth options error", authError);
    return new Response(JSON.stringify({ error: authError.message }), {
      headers: { ...corsHeaders, "Content-Type": "application/json" },
      status: 400,
    });
  }

  // Checking if the user already has password-based authentication
  if (auth_options[0].auth_options.includes("password")) {
    console.error("Password update not allowed for users with password-based authentication");
    return new Response(JSON.stringify({ error: "Password update not allowed for users with password-based authentication" }), {
      headers: { ...corsHeaders, "Content-Type": "application/json" },
      status: 400,
    });
  }

  // Creating a separate Supabase client with the service role key for administrative tasks
  const supabaseAdmin = createClient(
    Deno.env.get("SUPABASE_URL") ?? "",
    Deno.env.get("SUPABASE_SERVICE_ROLE_KEY") ?? "",
    {
      auth: {
        autoRefreshToken: false,
        persistSession: false,
        detectSessionInUrl: false
      }
    }
  );

  // Updating the user's password using the administrative client
  const { newPassword } = await req.json();
  const { error: updateError } = await supabaseAdmin.auth.admin.updateUserById(user.id, { password: newPassword });
  if (updateError) {
    console.error("Update error", updateError);
    return new Response(JSON.stringify({ error: updateError.message }), {
      headers: { ...corsHeaders, "Content-Type": "application/json" },
      status: 400,
    });
  }

  // Updating the authentication options for the user in the profiles table
  const updatedAuthOptions = [...auth_options[0].auth_options];
  if (!updatedAuthOptions.includes("password")) {
    updatedAuthOptions.push("password");
  }

  const { error: updateAuthOptionsError } = await supabaseClient.from('profiles').update({ auth_options: updatedAuthOptions });
  if (updateAuthOptionsError) {
    console.error("Update auth options error", updateAuthOptionsError);
    return new Response(JSON.stringify({ error: updateAuthOptionsError.message }), {
      headers: { ...corsHeaders, "Content-Type": "application/json" },
      status: 400,
    });
  }

  // Returning a success message if everything went smoothly
  return new Response(
    JSON.stringify({ message: "Password updated successfully" }),
    {
      headers: { ...corsHeaders, "Content-Type": "application/json" },
      status: 200,
    },
  );
});

Testing the Integration

To ensure the seamless functioning of our integration, let's conduct some tests encompassing various scenarios:

1. Test with a user who has been using magic links and now wants to set a password.

2. Test with a user who already has a password set to ensure password updates are not allowed for such users.

Conclusion

Congratulations on successfully integrating password + email sign-in with Supabase and PostgreSQL! This integration provides users with the flexibility to switch from magic links to password-based authentication effortlessly, enhancing the overall user experience. By harnessing the power of Supabase's open-source backend-as-a-service capabilities and PostgreSQL's robustness, you can build secure and user-friendly applications more efficiently.

What is pg-safeupdate?

pg-safeupdate plays a crucial role in PostgreSQL, aiming to mitigate the risks linked with unintended data updates. Its primary goal is to prevent update queries lacking a WHERE clause, which can inadvertently update all rows in a table. Enforcing the presence of a WHERE clause, pg-safeupdate ensures explicit and targeted updates, significantly reducing the risk of accidental data alterations.

Enabling the Extension

Enabling pg-safeupdate can be done at two levels: on a per-connection basis or for all connections to the database. To enable it for a specific connection, you can use the following SQL command:

LOAD 'safeupdate';

For broader applications, you can enable pg-safeupdate for all connections to the database with the following command:

ALTER DATABASE my_app_db SET session_preload_libraries = 'safeupdate';

The choice between the two methods depends on the specific use case and the desired level of data protection.

How pg-safe update Works:

Once pg-safeupdate is enabled, it actively monitors all update queries issued against the database. If an update query is detected without a WHERE clause, indicating an attempt to update all rows in the affected table, pg-safeupdate it intervenes and returns an error message. This prompt reminds developers to include a WHERE clause, ensuring that updates are precise, deliberate, and confined to specific rows.

Usage Example: To better understand the functioning of pg-safeupdate, let's consider a real-world example involving a inventory table. This table contains columns such as product_id, product_name, quantity, and price_per_unit. Without pg-safeupdate, an unintentional update query might look like this:

LOAD 'safeupdate';

UPDATE inventory SET quantity = 100;

This query updates the quantity for all products to 100, which is certainly not what we intended. However, with pg-safeupdate enabled, the query will be intercepted, and an error message will be returned:

ERROR: UPDATE requires a WHERE clause.

To proceed with the update, we must provide a WHERE clause that specifies the product_id of the product we want to modify:

UPDATE inventory SET quantity = 100 WHERE product_id = 'ABC123';

This updated query now precisely modifies the quantity of the product with the product_id of 'ABC123', ensuring data integrity.

Real-world Use Cases: In real-world scenarios, pg-safeupdate becomes a powerful safeguard against accidental data alterations. It prevents catastrophic data corruption in production environments, where unintended updates could lead to substantial financial losses or erode user trust. Additionally, during development and testing, pg-safeupdate ensures that database changes are deliberate, minimizing debugging efforts caused by unintentional data modifications.

Comparisons with Alternative Methods: While several methods exist for ensuring data integrity, pg-safeupdate stands out for its simplicity and effectiveness. Database triggers can achieve similar outcomes, but they might require more complex configurations and can be less transparent. Application-level constraints depend on the application code's correctness, which introduces a higher risk of human error. In contrast, pg-safeupdate offers a direct and efficient approach to enforcing update restrictions.

Conclusion: In the world of web applications, data integrity is non-negotiable. PostgreSQL's pg-safeupdate extension, in collaboration with Supabase, presents a formidable solution to mitigate the risks of accidental data updates. Mandating the use of WHERE clauses in update queries pg-safeupdate ensures that updates are intentional and specific. When combined with Supabase's features, developers can create robust and reliable web applications, safeguarding data from inadvertent modifications.

Additional Tips and Best Practices:

• Enable pg-safeupdate during development and testing phases to catch unintended updates early in the development process.

• Always include a WHERE clause in update queries, even when the extension is not enabled, as a best practice for data safety.

• Consider enabling pg-safeupdate for all connections in production environments to enforce strict update restrictions consistently.

Geospatial Functionalities with PostGIS

When working with geospatial data in PostgreSQL, integrating PostGIS becomes essential. PostGIS is an open-source extension to PostgreSQL that enables the storage, management, and analysis of geographic data. It provides a wide range of geospatial functions and operators that can be utilized to perform complex spatial queries and manipulations. By incorporating PostGIS into your Supabase and PostgreSQL stack, you can leverage powerful capabilities such as distance calculations, spatial indexing, geometric operations, and spatial relationships. These functionalities enable efficient distance-based filtering and location data retrieval, making it easier to implement location-aware applications and services.

Retrieving Location Data

To obtain location data based on an IP address, we can create two PostgreSQL functions: get_records_within_distance_free for the free tier (60 requests per minute) and get_records_within_distance when you have an API key from the freeipapi service.

a. get_records_within_distance_free Function (Free Tier):

CREATE OR REPLACE FUNCTION get_records_within_distance_free(ip varchar, distance numeric)
RETURNS SETOF my_table AS
$$
DECLARE
    tlongitude float;
    tlatitude float;
    response jsonb;
BEGIN
    -- HTTP GET request to retrieve the latitude and longitude
    SELECT content::jsonb INTO response FROM http_get('https://freeipapi.com/api/json/' || ip);
    tlongitude := (response -> 'longitude')::float;
    tlatitude := (response -> 'latitude')::float;
    -- Call the get_entries_within_distance function
    RETURN QUERY SELECT * FROM get_entries_within_distance(tlongitude, tlatitude, distance);
END;
$$ LANGUAGE plpgsql VOLATILE;

The get_records_within_distance_free function retrieves the latitude and longitude by making an HTTP GET request to the freeipapi API. It then calls the get_entries_within_distance function using the obtained latitude, longitude, and distance parameters.

b. get_records_within_distance Function (API Key):

CREATE OR REPLACE FUNCTION get_records_within_distance(ip varchar, distance numeric)
RETURNS SETOF my_table AS
$$
DECLARE
    tlongitude float;
    tlatitude float;
    response jsonb;
    freeipapi_key TEXT;
BEGIN
    -- Get freeipapi_key from the vault
    SELECT decrypted_secret
    INTO freeipapi_key
    FROM vault.decrypted_secrets
    WHERE name = 'freeipapi_key';
    -- HTTP GET request to retrieve the latitude and longitude
    SELECT content::jsonb INTO response
    FROM http((
        'GET',
        'https://freeipapi.com/api/json/' || ip,
        ARRAY[http_header('Authorization', 'Bearer ' || freeipapi_key)],
        'application/json'
    )::http_request);
    tlongitude := (response -> 'longitude')::float;
    tlatitude := (response -> 'latitude')::float;
    -- Call the get_entries_within_distance function
    RETURN QUERY SELECT * FROM get_entries_within_distance(tlongitude, tlatitude, distance);
END;
$$ LANGUAGE plpgsql VOLATILE;

The get_records_within_distance function is used when you have an API key from the freeipapi service. It retrieves the API key from the vault and incorporates it into the HTTP GET request to retrieve the latitude and longitude. The obtained latitude, longitude, and distance parameters are then used to call the get_entries_within_distance function.

Leveraging PostgreSQL Function for Distance-Based Filtering

In this section, we will delve into the creation of a PostgreSQL function to enable distance-based filtering, leveraging the power of the PostGIS extension. This approach allows efficient retrieval of location data within a specified radius. Implementing this functionality with Supabase and PostgreSQL empowers your application with geospatial capabilities.

Let's explore an example of the PostgreSQL function, get_entries_within_distance, designed to facilitate distance-based filtering:

CREATE OR REPLACE FUNCTION get_entries_within_distance(tlongitude float, tlatitude float, distance numeric)
RETURNS SETOF my_table AS
$$
BEGIN
  RETURN QUERY SELECT * FROM my_table 
  WHERE ST_DistanceSphere(ST_MakePoint(longitude, latitude), ST_MakePoint(tlongitude, tlatitude)) < distance::float;
END;
$$ LANGUAGE plpgsql VOLATILE;

Executing the PostgreSQL Function

To retrieve records within a specific distance from a given IP address, we can execute the appropriate PostgreSQL function using SQL queries. Here are two examples:

a. Utilizing the Free Tier Function:

SELECT * FROM get_records_within_distance_free('138.186.111.34', 900000);

b. Employing the API Key Function:

SELECT * FROM get_records_within_distance('138.186.111.34', 900000);

Both queries retrieve records that fall within a distance of 900,000 units from the geographical location associated with the IP address '138.186.111.36'.

Invoking the PostgreSQL Function from a JavaScript Client

To integrate the PostgreSQL function into your JavaScript application using Supabase's JavaScript client library, you can utilize RPC (Remote Procedure Call) to make the necessary call. Here's an optimized code snippet:

const { data: ret, error } = await supabase
  .rpc('get_records_within_distance', { ip: '138.186.111.34', distance: 900000 });
console.log(JSON.stringify(ret));

In this example, the IP address and distance parameters are passed to the get_records_within_distance function, and the response is stored in the ret variable.

Security Considerations for Accessing the freeipapi.com API

When it comes to accessing external APIs like freeipapi.com, it's crucial to prioritize security and adhere to rate limits. By utilizing the get_records_within_distance function, which retrieves the freeipapi_key from the vault, you can effectively bypass the rate limit imposed by the API, which typically allows only 60 requests per minute. However, it's essential to implement rate limit handling tailored to your specific application requirements, ensuring a seamless and efficient user experience.

Conclusion: Leveraging Supabase, PostgreSQL, and Geospatial Capabilities for Location Data Retrieval

In this blog post, we explored the powerful combination of Supabase as a backend and PostgreSQL as the underlying database to implement distance-based filtering and retrieve location data. By incorporating the robust geospatial functionalities provided by PostGIS and leveraging the freeipapi.com API, we were able to achieve accurate distance calculations and obtain precise location information.

The integration of Supabase, PostgreSQL, and external APIs empowers developers to build highly sophisticated and location-aware applications. Whether you're working on mapping services, location-based search functionality, or geospatial analytics, this comprehensive stack equips you with the necessary tools and flexibility to deliver exceptional user experiences.

We highly encourage readers to continue exploring and experimenting with Supabase, PostgreSQL, PostGIS, and other cutting-edge geospatial technologies to unlock the full potential of location data in their projects. By leveraging these state-of-the-art technologies, you can create innovative applications that seamlessly integrate location awareness and provide valuable insights to your users. Including expanding on the user tracking mechanisms.

Stay up-to-date with the official documentation of Supabase, PostgreSQL, and PostGIS to leverage the latest features, enhancements, and security best practices. As you embark on your development journey, we wish you success in creating groundbreaking location-enabled applications that make a significant impact in your industry.

One crucial aspect of utilizing Supabase is testing its Edge Functions, which play a vital role in extending the functionality of your application while ensuring its reliability. In this blog post, we will explore the process of setting up Supabase, delve into the world of Supabase Edge Functions, and learn how to write and test a simple hello-world function and run Edge Functions locally for efficient development. I previously wrote about testing Supabase-JS in your terminal which can also help to build a foundation.

Setting up Supabase and PostgreSQL

To get started with Supabase, we must first install and set it up using the Command Line Interface (CLI). The CLI offers a convenient way to initialize and manage Supabase projects effortlessly. Let's walk through the steps to install Supabase CLI and set up a Supabase project:

1. Install Docker: Supabase relies on Docker for local development. Install Docker by following the instructions on the official Docker website.

2. Install Supabase CLI: Open your terminal and run the following command to install the Supabase CLI:

    npm install -g supabase
   

3. Initialize a Supabase project: In your terminal, navigate to the desired directory and run the following command to initialize a new Supabase project:

    supabase init
   

   This command sets up a new Supabase project and creates the necessary configuration files.

4. Start the Supabase server: Once the initialization is complete, start the Supabase server using the following command:

    supabase start
   

   This command starts the Supabase server locally on your machine, allowing you to interact with the Supabase backend.

5. PostgreSQL as the underlying database: Supabase leverages PostgreSQL as its underlying database. This powerful and reliable database management system ensures the stability and scalability of your backend. You can interact with PostgreSQL using Supabase's intuitive APIs and tools.

Overview of Supabase Edge Functions

Supabase Edge Functions are an integral part of the Supabase ecosystem, empowering developers to extend the functionality of their applications with serverless computing. These functions run at the edge of the Supabase infrastructure, ensuring optimal performance and reduced latency. Let's explore the advantages of using Supabase Edge Functions:

• Serverless computing: Supabase Edge Functions provide a serverless architecture, allowing you to focus on writing code without the need to manage server infrastructure. This results in reduced operational overhead and improved scalability.

• TypeScript support: Edge Functions can be written in TypeScript, a statically-typed superset of JavaScript. TypeScript brings type safety to your code, enabling early detection of potential errors and improving overall code quality.

• Seamless integration with Supabase client: Edge Functions seamlessly integrates with the Supabase client, enabling easy communication with your Supabase backend. This integration allows you to leverage the full power of Supabase's APIs and functionalities within your Edge Functions.

Understanding the hello-world Edge Function with CORS

Now, let's dive into the details of the "Hello-world" Edge Function written in TypeScript and explore its functionality along with Cross-Origin Resource Sharing (CORS) implementation. We'll break down the code step by step, providing a clear understanding of each section and its interaction with the Supabase client.

Here's the code snippet for the hello-world Edge Function:

// Import the serve function from the Deno standard library
import {
    serve
} from "https://deno.land/std@0.192.0/http/server.ts"

// Print a greeting message to the console
console.log("Hello from Functions!")

// Define the headers to handle CORS (Cross-Origin Resource Sharing)
const corsHeaders = {
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Headers": "authorization, x-client-info, apikey, content-type",
};

// Start the server and define the request handler
serve(async(req) => {
    // If the HTTP method is OPTIONS, return a response with CORS headers
    if (req.method === 'OPTIONS') {
        return new Response('ok', {
            headers: corsHeaders
        })
    }
    // Extract the name from the request body
    const {
        name
    } = await req.json()
    // Prepare the response data
    const data = {
        message: `Hello ${name}!`,
    }

    // Return a response with the data and headers
    return new Response(
        JSON.stringify(data), {
            headers: {
                ...corsHeaders,
                "Content-Type": "application/json"
            },
        }
    )
})

In this section, we'll analyze the different aspects and functionalities of the Hello-world Edge Function, providing insights into each segment's purpose and its seamless integration with the Supabase client.

• We import the serve function from the Deno standard library to create a server that listens for incoming HTTP requests.

• The console.log statement is for logging purposes and will be displayed in the console when the function is executed.

• We define the corsHeaders object to handle Cross-Origin Resource Sharing (CORS) headers, allowing requests from any origin and specifying the allowed headers.

• The serve function takes an asynchronous callback function as a parameter, which handles the incoming requests.

• In the callback function, we check if the request method is OPTIONS. If it is, we return a response with a status of 'ok' and the CORS headers.

• If the request method is not OPTIONS, we parse the JSON data from the request body and extract the name field.

• We construct a response object with a JSON payload containing a dynamic greeting message using the provided name.

• Finally, we return the response object along with the CORS headers.

Now, we need to run the function locally :

supabase functions serve

Testing Supabase Edge Functions

Testing is a crucial step in the development process to ensure the correctness and performance of your Edge Functions. Let's discuss the importance of testing and examining the code in the deno-test.ts file, which demonstrates how to test the Supabase client and the hello-world function.

// deno-test.ts
// This imported is needed to load the .env file:
import "https://deno.land/x/dotenv/load.ts";
// Import necessary libraries and modules
import {
  assert,
  assertExists,
  assertEquals,
} from "https://deno.land/std@0.192.0/testing/asserts.ts";
import {
  createClient,
  SupabaseClient,
} from "https://esm.sh/@supabase/supabase-js@2.23.0";
import { delay } from 'https://deno.land/x/delay@v0.2.0/mod.ts';

// Setup the Supabase client configuration
const supabaseUrl = Deno.env.get("SUPABASE_URL") ?? "";
const supabaseKey = Deno.env.get("SUPABASE_ANON_KEY") ?? "";
const options = {
  auth: {
    autoRefreshToken: false,
    persistSession: false,
    detectSessionInUrl: false
  }
};

// Test the creation and functionality of the Supabase client
const testClientCreation = async () => {
  var client: SupabaseClient = createClient(supabaseUrl, supabaseKey, options);

  // Check if the Supabase URL and key are provided
  if (!supabaseUrl) throw new Error('supabaseUrl is required.')
  if (!supabaseKey) throw new Error('supabaseKey is required.')

  // Test a simple query to the database
  const { data: table_data, error: table_error } = await client.from('my_table').select('*').limit(1);
  if (table_error) {
    throw new Error('Invalid Supabase client: ' + table_error.message);
  }
  assert(table_data, "Data should be returned from the query.");
};

// Test the 'hello-world' function
const testHelloWorld = async () => {
  var client: SupabaseClient = createClient(supabaseUrl, supabaseKey, options);

  // Invoke the 'hello-world' function with a parameter
  const { data: func_data, error: func_error } = await client.functions.invoke('hello-world', {
    body: { name: 'bar' }
  });

  // Check for errors from the function invocation
  if (func_error) {
    throw new Error('Invalid response: ' + func_error.message);
  }

  // Log the response from the function
  console.log(JSON.stringify(func_data, null, 2));

  // Assert that the function returned the expected result
  assertEquals(func_data.message, 'Hello bar!');
};

// Register and run the tests
Deno.test("Client Creation Test", testClientCreation);
Deno.test("Hello-world Function Test", testHelloWorld);

This is a test case with two parts. The first tests the client library and check that the database is connectable and returning values from a table (my_table). The second part is testing the edge function and checks if the value received is expected. Here's a brief overview of the code:

• We import various testing functions from the Deno standard library, including assert, assertExists, and assertEquals.

• We import the createClient and SupabaseClient classes from the @supabase/supabase-js library to interact with the Supabase client.

• We define the necessary configuration for the Supabase client, including the Supabase URL, API key, and authentication options.

• The testClientCreation function tests the creation of a Supabase client instance and queries the database for data from a table. It asserts that data is returned from the query.

• The testHelloWorld function tests the "Hello-world" Edge Function by invoking it using the Supabase client's functions.invoke method. It checks if the response message matches the expected greeting.

• We run the tests using the Deno.test function, providing a descriptive name for each test case and the corresponding test function.

Note: Please make sure to replace the placeholders (supabaseUrl, supabaseKey, my_table) with the actual values relevant to your Supabase setup.

Running Edge Functions Locally

To test and debug Edge Functions locally, you can utilize the Supabase CLI. Let's explore how to run Edge Functions locally using the Supabase CLI:

1. Ensure that the Supabase server is running by executing the following command:

    supabase start
   

2. In your terminal, use the following command to serve the Edge Functions locally:

    supabase functions serve
   

   This command starts a local server that runs your Edge Functions, allowing you to test and debug them in a development environment.

3. Create the environment variables file:

    # creates the file
    touch .env.local
    # adds the SUPABASE_URL secret
    echo "SUPABASE_URL=http://localhost:54321" >> .env.local
    # adds the SUPABASE_ANON_KEY secret
    echo "SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6ImFub24iLCJleHAiOjE5ODM4MTI5OTZ9.CRXP1A7WOeoJeXxjNni43kdQwgnWNReilDMblYTn_I0" >> .env.local
    #Alternatively, you can open in your editor:
    open .env.local
   

4. To run the tests, use the following command in your terminal:

    #Place the .env file in the same directory as deno-test.ts
    deno test --allow-all deno-test.ts
   

   Here's an example of what this would look like:

   

Conclusion

In this blog post, we covered the process of setting up Supabase and PostgreSQL for backend development. We explored the concept of Supabase Edge Functions and their advantages in extending the functionality of your application. We also walked through the process of writing a simple "Hello-world" function and discussed the importance of testing Supabase Edge Functions for ensuring their correctness and performance. Lastly, we learned how to run Edge Functions locally using the Supabase CLI. By incorporating Supabase and PostgreSQL into your backend stack and thoroughly testing your Edge Functions, you can maintain the reliability and functionality of your application.

To learn more about Supabase and its features, consult the official Supabase documentation. For information on Deno and its testing framework, refer to the Deno documentation. Additionally, you can explore the Supabase GitHub repository.