fonctions de supabase (pas de bord)

Supabase

Une alternative open source à l'offre Firebase

• base de données
• temps réel
• authentification
• fonctions
• fonctions de bord

Mais attendez, s'ils ont déjà des fonctions, pourquoi ont-ils besoin de fonctions de pointe ?

Fonctions Supabase : votre boîte à outils PostgreSQL

Les fonctions Supabase, également appelées fonctions de base de données, sont essentiellement des procédures stockées PostgreSQL. Ce sont des blocs exécutables de code SQL qui peuvent être appelés à partir de requêtes SQL.

Fonctions Edge : au-delà de la base de données

En revanche, les fonctions Edge sont des fonctions TypeScript côté serveur qui s'exécutent sur le runtime Deno. Elles sont similaires aux Firebase Cloud Functions mais offrent une alternative plus flexible et open source.

Supabase : une plateforme PostgreSQL

Au-delà de son rôle d'alternative open source à Firebase, Supabase a évolué vers une plateforme PostgreSQL complète. Il fournit un support de premier ordre pour les fonctions PostgreSQL, les intégrant de manière transparente dans ses utilitaires intégrés et vous permettant de créer et de gérer des fonctions personnalisées directement à partir du tableau de bord Supabase.

Structure d'une fonction postgres de base

CREATE FUNCTION my_function() RETURNS int AS $$
BEGIN
    RETURN 42;
END;
$$ LANGUAGE sql;

Répartition :

1. CRÉER UNE FONCTION : Ce mot-clé indique que nous définissons une nouvelle fonction.
2. my_function() : C'est le nom de la fonction. Vous pouvez choisir n'importe quel nom significatif que vous préférez.
3. RETURNS int : Ceci spécifie le type de retour de la fonction. Dans ce cas, la fonction renverra une valeur entière.
4. AS $$ : Ceci commence le corps de la fonction, entouré de doubles signes dollar ($$) pour le délimiter.
5. BEGIN : Ceci marque le début du code exécutable de la fonction.
6. RETURN 42;: Cette instruction spécifie la valeur que la fonction renverra. Dans ce cas, il s'agit de l'entier 42.
7. END;: Ceci marque la fin du code exécutable de la fonction.
8. $$ LANGUAGE sql;: Ceci spécifie la langue dans laquelle la fonction est écrite. Dans ce cas, c'est SQL.

Objectif :

Cette fonction définit une fonction SQL simple nommée my_function qui renvoie la valeur entière 42. C'est un exemple de base pour démontrer la structure et la syntaxe d'une définition de fonction dans PostgreSQL.

Points clés à retenir :

• Vous pouvez remplacer my_function par n'importe quel nom de fonction souhaité.
• Le type de retour peut être n'importe quel type de données valide, tel que texte, booléen, date ou un type défini par l'utilisateur.
• Le corps de la fonction peut contenir une logique complexe, notamment des instructions conditionnelles, des boucles et des appels à d'autres fonctions.

• Les délimiteurs $$ sont utilisés pour délimiter le corps de la fonction de manière indépendante de la langue.

• Les fonctions Postgres peuvent également être appelées par des TRIGGERS postgres qui sont comme des fonctions mais réagissent à des événements spécifiques comme l'insertion, la mise à jour ou la suppression sur une table

• pour exécuter cette fonction
  

SELECT my_function();

• pour lister cette fonction

SELECT
    proname AS function_name,
    prokind AS function_type
FROM pg_proc
WHERE proname = 'my_function';

• pour supprimer cette fonction

DROP FUNCTION my_function();

Fonctions postgres Supabase

Fonctions intégrées

Supabase utilise les fonctions postgres pour effectuer certaines tâches au sein de votre base de données.

La courte liste d'exemples comprend

--  list all the supabase functions
SELECT
    proname AS function_name,
    prokind AS function_type
FROM pg_proc;

--  filter for the session supabase functions function
SELECT
    proname AS function_name,
    prokind AS function_type
FROM pg_proc
WHERE proname ILIKE '%session%';

--  selects the curremt jwt
select auth.jwt()

-- select what role is callig the function (anon or authenticated)
select auth.role();

-- select the session user
select session_use;

Vue des fonctions Supabase sur le tableau de bord
Pour afficher certaines de ces fonctions dans Supabase, vous pouvez vérifier sous base de données > fonctions

Fonctions Supabase PostgreSQL utiles

Création d'une table user_profile lors de l'inscription de l'utilisateur

Supabase stocke les données utilisateur dans la table auth.users, qui est privée et ne doit pas être consultée ou modifiée directement. Une approche recommandée consiste à créer une table d'utilisateurs publics ou user_profiles et à la lier à la table auth.users.

Bien que cela puisse être fait à l'aide de SDK côté client en enchaînant une demande de création d'utilisateur avec une demande d'inscription réussie, il est plus fiable et efficace de la gérer du côté Supabase. Ceci peut être réalisé en utilisant une combinaison d'un TRIGGER et d'une FONCTION.

--   create the user_profiles table
CREATE TABLE user_profiles (
  id uuid PRIMARY KEY,
  FOREIGN KEY (id) REFERENCES auth.users(id),
  name text,
  email text
);

-- create a function that returns a trigger on auth.users
CREATE 
OR REPLACE FUNCTION public.create_public_user_profile_table() 
RETURNS TRIGGER AS $$ 
BEGIN INSERT INTO public.user_profiles (id,name,email) 
VALUES 
  (
    NEW.id,
    NEW.raw_user_meta_data ->> 'name',
    NEW.raw_user_meta_data ->> 'email'
    -- other fields accessible here 
--     NEW.raw_user_meta_data ->> 'name',
-- NEW.raw_user_meta_data ->> 'picture',

);
RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

-- create the trigger that executes the function on every new user rowcteation(signup)
CREATE TRIGGER create_public_user_profiles_trigger 
AFTER INSERT ON auth.users FOR EACH ROW WHEN (
        NEW.raw_user_meta_data IS NOT NULL
    )
EXECUTE FUNCTION public.create_public_user_profile_table ();

let { data: user_profiles, error } = await supabase
  .from('user_profiles')
  .select('*')

• Ajouter des revendications personnalisées lors de la création de jwt (RBAC) supabse a un article détaillé et une vidéo à ce sujet.

nous avons besoin de 2 tables

• public.roles et public.role_permissions

-- Custom types
create type public.app_permission as enum ('channels.delete', 'channels.update', 'messages.update', 'messages.delete');
create type public.app_role as enum ('admin', 'moderator');

-- USER ROLES
create table public.user_roles (
  id        bigint generated by default as identity primary key,
  user_id   uuid references public.users on delete cascade not null,
  role      app_role not null,
  unique (user_id, role)
);
comment on table public.user_roles is 'Application roles for each user.';

-- ROLE PERMISSIONS
create table public.role_permissions (
  id           bigint generated by default as identity primary key,
  role         app_role not null,
  permission   app_permission not null,
  unique (role, permission)
);
comment on table public.role_permissions is 'Application permissions for each role.';

exemple de rôle utilisateur

example of a role permission table

user with user_id = user-1 will have admin and moderator roles and can delete channels and messages

users with user_id = user-2 can only update channels and messages with the moderator role

-- Create the auth hook function
create or replace function public.custom_access_token_hook(event jsonb)
returns jsonb
language plpgsql
stable
as $$
  declare
    claims jsonb;
    user_role public.app_role;
  begin
    -- Fetch the user role in the user_roles table
    select role into user_role from public.user_roles where user_id = (event->>'user_id')::uuid;

    claims := event->'claims';

    if user_role is not null then
      -- Set the claim
      claims := jsonb_set(claims, '{user_role}', to_jsonb(user_role));
    else
      claims := jsonb_set(claims, '{user_role}', 'null');
    end if;

    -- Update the 'claims' object in the original event
    event := jsonb_set(event, '{claims}', claims);

    -- Return the modified or original event
    return event;
  end;
$$;

grant usage on schema public to supabase_auth_admin;

grant execute
  on function public.custom_access_token_hook
  to supabase_auth_admin;

revoke execute
  on function public.custom_access_token_hook
  from authenticated, anon, public;

grant all
  on table public.user_roles
to supabase_auth_admin;

revoke all
  on table public.user_roles
  from authenticated, anon, public;

create policy "Allow auth admin to read user roles" ON public.user_roles
as permissive for select
to supabase_auth_admin
using (true)

then create a function that will be called to authorize on RLS policies

create or replace function public.authorize(
  requested_permission app_permission
)
returns boolean as $$
declare
  bind_permissions int;
  user_role public.app_role;
begin
  -- Fetch user role once and store it to reduce number of calls
  select (auth.jwt() ->> 'user_role')::public.app_role into user_role;

  select count(*)
  into bind_permissions
  from public.role_permissions
  where role_permissions.permission = requested_permission
    and role_permissions.role = user_role;

  return bind_permissions > 0;
end;
$$ language plpgsql stable security definer set search_path = '';

--  example RLS policies
create policy "Allow authorized delete access" on public.channels for delete using ( (SELECT authorize('channels.delete')) );
create policy "Allow authorized delete access" on public.messages for delete using ( (SELECT authorize('messages.delete')) );

Improved Text:

Creating RPC Endpoints

Supabase functions can be invoked using the rpc function. This is especially useful for writing custom SQL queries when the built-in PostgreSQL APIs are insufficient, such as calculating vector cosine similarity using pg_vector.

create or replace function match_documents (
  query_embedding vector(384),
  match_threshold float,
  match_count int
)
returns table (
  id bigint,
  title text,
  body text,
  similarity float
)
language sql stable
as $$
  select
    documents.id,
    documents.title,
    documents.body,
    1 - (documents.embedding <=> query_embedding) as similarity
  from documents
  where 1 - (documents.embedding <=> query_embedding) > match_threshold
  order by (documents.embedding <=> query_embedding) asc
  limit match_count;
$$;

and call it client side

const { data: documents } = await supabaseClient.rpc('match_documents', {
  query_embedding: embedding, // Pass the embedding you want to compare
  match_threshold: 0.78, // Choose an appropriate threshold for your data
  match_count: 10, // Choose the number of matches
})

Improved Text:

Filtering Out Columns

To prevent certain columns from being modified on the client, create a simple function that triggers on every insert. This function can omit any extra fields the user might send in the request.

-- check if user with roles authenticated or anon submitted an updatedat column and replace it with the current time , if not (thta is an admin) allow it
CREATE
or REPLACE function public.omit_updated__at () returns trigger as 
$$ BEGIN 
IF auth.role() IS NOT NULL AND auth.role() IN ('anon', 'authenticated') 
THEN NEW.updated_at = now();
END IF; 
RETURN NEW; 
END; $$ language plpgsql;

Summary

With a little experimentation, you can unlock the power of Supabase functions and their AI-powered SQL editor. This lowers the barrier to entry for the niche knowledge required to get this working.

Why choose Supabase functions?

• Extend Supabase's API: Supabase can only expose so much through its API. Postgres, however, is a powerful database. Any action you can perform with SQL statements can be wrapped in a function and called from the client or by a trigger.
• Reduce the need for dedicated backends: Supabase functions can fill the simple gaps left by the client SDKs, allowing you to focus on shipping.
• Avoid vendor lock-in: Supabase functions are just Postgres. If you ever need to move to another hosting provider, these functionalities will continue to work.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!