프로젝트가 끝나고 KPT 회고까지 작성했는데, 이제서야 트러블 슈팅을 쓰는 사람이 있다? 그건 바로 나! 팀프로젝트 일정 때문에 미뤄두었던 트러블 슈팅 내용을 다 잊어버리기 전에 미리 작성하고자한다.
supabase에서 데이터를 가져올 때 사용할 함수는 재사용성이 있다고 판단하여, 여러 곳에서 사용할 수 있도록 유틸리티 함수로 만들고자 했다.
supabase의 메서드를 처음 써본 프로젝트였기에, 제대로 작동하는지 확인하고자 feeds
테이블의 데이터를 console로 찍어보았다.
어라? 분명 feeds
테이블에 테스트 데이터를 넣어 놓았는데, console에 빈 배열이 찍혔다.
console에 에러가 아닌 빈배열이 찍힌 것은 테이블 접근 방법이 잘못된 것이 아닐텐데...라는 생각에 어디가 문제일지 구글링도 해보고, 여러 값을 바꿔보기도 해보았다. 그러다 갑자기 머릿속을 스쳐지나간 특강 속 " RLS "가 기억나서 급하게 구글링을 해보았다.
Row-Level Security로, 데이터베이스 보안 기능 중 하나이다. 각 사용자가 자신의 데이터(row)만 접근할 수 있도록 제한하는 정책이다. 즉, 한 사용자는 본인의 데이터만 추가/조회/수정/삭제가 가능해야하며, 다른 사용자의 데이터에 접근하지 못하도록 한다.
단순한 SQL 로직을 사용하여 각 테이블에 원하는 정책을 설정할 수 있다.
CREATE POLICY "정책을 설명하는 이름"
ON 테이블명
FOR 동작 (SELECT(선택)/UPSERT(없으면 추가, 있으면 수정)/DELETE(삭제))
USING 조건 지정
supabase RLS 공식 문서
supabase 참고 사이트
문제 해결에 대해 작성하기 전, 내 상황에 대해 간단하게 설명하자면... 이전에 코딩을 전혀 경험해보지 못한 비전공자로서, SQL이나 백엔드 언어에 대해 저어어언혀 아는 것이 없었다. 보통 프론트엔드는 데이터베이스를 직접 구축하기보다는, 구축된 데이터 서버에 접근해 데이터를 받아와 화면 UI에 표시하는 역할이다. 그래서 백엔드 언어에 대해 깊게 알 수도, 알 필요도 없다고 생각했다. 이번 프로젝트가 막막하게 느껴졌던 이유도 BaaS인 supabase를 활용하는 부분이었다.
*BaaS란? : Backend as a Service. 웹 또는 모바일 애플리케이션의 백그라운드 측면을 아웃소싱하는 클라우드 서비스 모델로, 프론트엔드 개발자가 애플리케이션 코드 작성에 집중할 수 있음
다행히 supabase는 테이블 생성 뿐만 아니라 RLS 등 다양한 기능에 대해 GUI와 템플릿을 제공한다. 나는 이 템플릿에 큰 도움을 받아 테이블 생성부터 RLS 설정까지 손쉽게 해낼 수 있었다. 이것이 BaaS의 장점이다. BaaS를 활용하여 백엔드 언어를 전혀 알지 못해도 데이터 베이스를 쉽게 구축하고 연결할 수 있다.
feeds
테이블에 데이터 접근/추가/삭제/수정에 대한 각 RLS를 추가해주었다. 데이터 조회는 화면 UI 구성과 데이터 CRUD를 위해 all users
로 정책을 설정해주었고, 데이터 추가/수정/삭제는 회원가입한 회원만 접근 가능하도록 user_id
가 필요하도록 설정해주었다.
auth 스키마의 user id는 feeds
테이블의 writer_id와 FK로 연결되어 있기 때문에 USING문을 위 사진처럼 작성해주었다.
*FK란? : Foreign Key. 외래키 혹은 참조키로, 테이블 간 관계를 유지하고, 데이터의 일관성을 유지한다.
데이터가 console에 잘 찍히는 것을 확인할 수 있었다!
재사용성과 활용성(table join 등)을 더 높이기 위해 함수의 인자를 추가하여 최종 코드를 작성하였다.