Supabase에서는 PostgreSQL 데이터베이스를 사용하는데, 각 프로젝트는 하나의 데이터베이스를 가지며 이 안에 여러 스키마와 테이블을 포함할 수 있다.

Supabase에서는 기본적으로 public 스키마를 제공하며, 필요에 따라 추가 스키마를 생성하여 데이터를 논리적으로 분리할 수 있다. 마치 서랍장에서 옷의 종류별로 서랍을 나누는 것처럼, 관련된 테이블들을 하나의 스키마로 묶어서 관리하는 거라고 생각하면 된다.

각 테이블은 특정 엔티티(예: 사용자, 게시물)를 나타내며, 관련된 데이터를 체계적으로 저장한다.

예를 들어, 사용자 테이블에서 각 행은 개별 사용자의 정보를 포함한다.

각 열은 고유한 데이터 타입(문자열, 숫자, 날짜 등)을 가지며, 해당 속성에 대한 제약조건을 설정할 수 있다.

Supabase에서는 Oragnization 즉 조직 아래에 여러 개의 프로젝트를 만들 수 있다. 하나의 프로젝트는 독립적인 데이터베이스 환경을 제공한다.

프로젝트를 생성할 때는 지역, 데이터베이스 비밀번호, 가격 정책 등을 설정할 수 있으며, 생성이 완료되면 프로젝트의 대시보드에서 데이터베이스 관리를 시작할 수 있다.

https://supabase.com/docs/guides/api/using-custom-schemas

기본적으로 public이라는 schema가 존재한다. 하지만 이번에는 새로운 스키마를 만들어 관리해보자.

Supabase에서 데이터베이스를 관리할 때 대시보드의 GUI를 사용해도 된다. 하지만 조금 더 유연하고 간편하게 관리하기 위해서는 SQL을 사용하는 것도 좋은 방법이다.

좌측 네비게이션 바의 SQL Editor에 들어가 SQL을 생성하고, 관리하고, 실행할 수 있다.

CREATE SCHEMA test;

스키마를 생성하는 명령어다.

API Settings > Exposed schemas에 2번에서 생성한 커스텀 스키마 추가한다.

그리고 SQL에서 아래 명령문을 실행한다.

GRANT USAGE ON SCHEMA test TO anon, authenticated, service_role;
GRANT ALL ON ALL TABLES IN SCHEMA test TO anon, authenticated, service_role;
GRANT ALL ON ALL ROUTINES IN SCHEMA test TO anon, authenticated, service_role;
GRANT ALL ON ALL SEQUENCES IN SCHEMA test TO anon, authenticated, service_role;
ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA test GRANT ALL ON TABLES TO anon, authenticated, service_role;
ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA test GRANT ALL ON ROUTINES TO anon, authenticated, service_role;
ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA test GRANT ALL ON SEQUENCES TO anon, authenticated, service_role;

위에서 test는 내가 생성한 스키마의 이름이며 이를 각자가 만든 스키마 이름으로 수정하면 된다.

이 명령어들이 하는 일을 간단히 설명하자면, 생성한 스키마에 대한 권한을 설정하는 것이다. anon(미인증 사용자), authenticated(인증된 사용자), service_role(서비스 역할)에게 스키마의 모든 테이블, 루틴, 시퀀스에 대한 접근 권한을 부여한다. 이는 클라이언트 애플리케이션에서 해당 스키마의 데이터에 접근할 수 있도록 하기 위해 필요한 설정이다.

이제 내가 만든 스키마를 선택할 수 있다.

이제 스키마 내에 테이블과 칼럼을 자유롭게 생성하고 수정할 수 있다.

만약 RLS를 활성화하지 않았다면 SQL문에서 아래 스크립트를 실행해 RLS를 활성화하자.

alter table "table_name" enable row level security;

RLS를 활성화할 시 policy를 만들기 전까지 public anon키로는 API를 이용한 어떤 데이터도 접근할 수 없다. 여기서 anon은 인증되지 않은(즉, 로그인하지 않은) 요청을 의미한다.

위와 같이 (( SELECT auth.uid() AS uid) = user_id)로 설정할 경우 현재 로그인한 사용자의 ID와 데이터의 user_id 필드가 일치하는지 확인해 사용자가 자신의 데이터만 접근할 수 있도록 제한할 수 있다. 여기서 auth.uid()는 요청을 한 사용자의 ID를 반환하는 Supabase의 헬퍼 함수다.

이로써 각자 사용자는 각자의 메모 데이터만 접근을 할 수 있게 된다.

create policy "Individuals can view their own todos."
on todos for select
using ( (select auth.uid()) = user_id );

select *
from todos
where auth.uid() = todos.user_id;
-- Policy is implicitly added.

create policy "Public profiles are visible to everyone."
on profiles for select
to anon         -- the Postgres Role (recommended)
using ( true ); -- the actual Policy

create policy "Authenticated users can view data"
on table_name for select
to authenticated
using ( auth.role() = 'authenticated' );

create policy "Only admins can update"
on table_name for update
to authenticated
using ( auth.jwt() ->> 'role' = 'admin' );

이런 정책은 관리자 대시보드를 만들 때 유용하다. JWT 토큰에 저장된 role 정보를 확인해 admin인 경우에만 데이터 수정을 허용하는 방식이다.

create policy "Users can delete their own data"
on table_name for delete
to authenticated
using ( auth.uid() = user_id );

create policy "Users can only insert active status"
on table_name for insert
to authenticated
with check ( status = 'active' );

insert 정책에서는 with check 절을 사용한다는 점이 select나 update와 다른 부분이다. 이는 새로 삽입되는 데이터가 특정 조건을 만족하는지 검증하는 역할을 한다.

create policy "Users can update their own data"
on table_name for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

update 정책에서 짚고 넘어갈 부분이 있다. update는 using과 with check를 둘 다 써야 한다는 점이다. using은 '어떤 행을 수정 대상으로 삼을 수 있는가'를 거르는 조건이고, with check는 '수정한 결과가 이 조건을 만족하는가'를 검사하는 조건이다. 만약 using만 걸면 내 데이터만 수정 대상으로 잡히긴 하지만, 수정하면서 user_id를 남의 값으로 바꿔치기하는 걸 막지 못한다. 반대로 with check만 걸면 애초에 수정 대상을 거르지 못한다. 그래서 '내 것만 골라서, 내 것인 상태로만 저장되게' 하려면 둘 다 필요하다.

npx supabase gen types --lang=typescript --project-id ${프로젝트 ID} --schema ${스키마명} > packages/shared/src/types/supabase.ts

// package.json
{
	"scripts":{
		"generate-supabase-type": "supabase gen types --lang=typescript --project-id ${프로젝트 아이디} --schema ${스키마명} > ${타입을 저장할 위치} && prettier --write ${타입을 저장한 위치}"	
		// ..
	}
}

이렇게 설정해두면 데이터베이스 스키마를 수정한 후 npm run generate-supabase-type 명령어 하나로 타입을 최신 상태로 동기화할 수 있다. 특히 팀 프로젝트에서는 이 스크립트를 공유해두면 모든 팀원이 동일한 타입을 사용할 수 있어서 협업하기 훨씬 수월해진다.

supabaseClient.from(SUPABASE.table.memo).insert(request).select()

export class MemoService {
  supabaseClient: MemoSupabaseClient;

  constructor(supabaseClient: MemoSupabaseClient) {
    this.supabaseClient = supabaseClient;
  }
  // ..
}

생성자 메서드 내부에서 Supabase Client를 인자로 전달받아 이를 클래스의 멤버 변수로 저장한다. 이렇게 저장된 클라이언트는 다른 메서드에서 데이터베이스 작업을 수행할 때 사용된다. 의존성 주입 패턴을 사용한 건데, 이렇게 하면 나중에 테스트할 때 mock 클라이언트를 주입하기도 쉽고, 클라이언트 설정이 변경되어도 서비스 코드를 수정할 필요가 없다.

async insertMemo(request: MemoTable['Insert']) {
    return this.supabaseClient.from(SUPABASE.table.memo).insert(request).select();
  }

  async upsertMemos(request: MemoTable['Insert'][]) {
    return this.supabaseClient.schema(SUPABASE.table.memo).from(SUPABASE.table.memo).upsert(request).select();
  }

  async getMemos() {
    return this.supabaseClient
      .schema(SUPABASE.table.memo)
      .from(SUPABASE.table.memo)
      .select('*,category(name)')
      .order('created_at', { ascending: false });
  }
  // ..
}

여기서 간결한 코드 작성을 위해 화살표 함수를 사용할 수 있지만 그럼에도 위와 같이 일반 메서드를 사용할 것을 권장한다. 왜냐하면 클래스 내 화살표 함수로 메서드를 등록할 경우 이는 인스턴스 속성으로 저장되어 프로토타입 체인에 등록되지 않는다. 다시말해 인스턴스를 생성할 때마다 메서드를 새롭게 생성하는 것을 의미한다. 이는 메모리 사용량을 증가시키고 상속을 통한 메서드 재사용을 어렵게 만든다. 반면 일반 메서드는 프로토타입 체인에 등록되어 메모리를 효율적으로 사용하고 상속을 통한 재사용이 가능하다.

❗ 주의할 점

여기서 주의할 점이 있다. 위와 같이 일반 메서드로 선언후 react-query를 사용할 때 함수 그 자체를 넘겨주면 안된다는 것이다.

return useMutation<MemoSupabaseResponse, MutationError, MemoTable['Insert']>({
  mutationFn: new MemoService(supabaseClient).insertMemo,
	// ..
}

함수 자체를 넘겨줄 경우 이 함수를 실행하는 주체는 react-query의 useMutation가 된다. 다시말해 new AuthService(supabaseClient).getUser 함수가 useMutation의 인자로 넘어가 아래 함수가 useMutation에 의해 실행된다는 것을 의미한다.

async insertMemo(request: MemoTable['Insert']) {
  return this.supabaseClient.from(SUPABASE.table.memo).insert(request).select();
}

useMutation에 의해 insertMemo가 실행될 때 this는 어디를 가리킬까?

그렇다. 전역 객체이다. 왜냐하면 함수 자체가 콜백 함수로 전달되었기에 함수를 실행하는 주체인 useMutation이 this를 결정하고, 이 때 인스턴스의 메서드가 아닌 일반 함수로 실행이 되기에 this는 전역 객체가 된다.

그럼 이를 어떻게 해결할까?

1. 함수를 새롭게 생성해 전달한다.

   return useMutation<MemoSupabaseResponse, MutationError, MemoTable['Insert']>({
     mutationFn: (...request) => new MemoService(supabaseClient).insertMemo(...request),
   	// ..
   }

   기존 방식의 문제점은 함수를 실행하는 주체가 useMutation이라는 것이었다. useMutation 내에서 함수를 직접 실행하기에 this가 바뀐 것이다.

   위와 같이 함수를 새롭게 생성해 전달할 경우 insertMemo메서드는 MemoService라는 클래스의 인스턴스 메서드로써 호출이 된다. 즉 useMutation내부에서 이 함수를 실행할 때 메서드로 호출이 되어 this가 클래스 인스턴스에 바인딩이 된다는 말을 의미한다.

2. 클래스 내에서 일반 메서드가 아니라 화살표 함수로 선언한다.

   class MemoService {
     constructor(private supabaseClient: SupabaseClient) {}
   
     // 화살표 함수로 선언
     insertMemo = async (request: MemoTable['Insert']) => {
       return this.supabaseClient.from(SUPABASE.table.memo).insert(request).select();
     }
   }

   화살표 함수는 일반 메서드와 달리 함수를 호출할 당시 this바인딩을 하지 않는다. 그렇기 때문에 화살표 함수로 선언할 경우 this는 상위 실행 컨텍스트인 클래스 인스턴스를 가리키게 된다.

3. bind를 사용해 명시적으로 this를 바인딩한다.

   const memoService = new MemoService(supabaseClient);
   return useMutation<MemoSupabaseResponse, MutationError, MemoTable['Insert']>({
     mutationFn: memoService.insertMemo.bind(memoService),
     // ..
   });

   bind 메서드를 사용하여 함수의 this를 명시적으로 바인딩할 수도 있다. 이는 함수를 전달할 때 this의 컨텍스트를 유지하는 방법이다. 여기서 주의할 점은 인스턴스를 딱 하나만 만들어 그 인스턴스를 bind 대상으로 넘겨야 한다는 것이다. 위처럼 new MemoService(...)를 두 번 부르면 실제로 호출되는 인스턴스와 this로 묶인 인스턴스가 서로 다른 객체가 되어버린다.

// useMemosQuery.ts
const query = useSuspenseQuery<QueryFnData, QueryError, QueryData>({
  queryFn: new MemoService(supabaseClient).getMemos,
	// ..

// src/app/memos/layout.tsx
const isUserLogin = await new AuthService(supabaseClient).checkUserLogin();