🔧 작업 배경 및 개요
어떤 이유로 이 작업을 하게 되었고, 무엇을 개선하려고 하는지 설명해주세요.
현재 Supabase DB에 접근할 때, SupabeDBRequestBuilder라는 클래스를 통해서 쿼리를 구성하게 됩니다. 현재 이 클래스는 RemoteDBRequestBuildable이라는 단일 프로토콜로 추상화 되어있지만, 쿼리 종류에 상관 없이 모든 메소드에 접근하려는 문제를 해결하려고 합니다.
protocol RemoteDBRequestBuildable {
func setTable(_ table: String) -> Self
func setData(_ data: Data) -> Self
func setQuery(_ parameter: SupabaseQueryParameter) -> Self
@discardableResult func request() async throws -> Data
}
만약 Fetch 작업을 수행할 때, setData와 같은 메소드는 접근하면 안되는데, 접근이 가능한 문제가 있습니다. 따라서 각 쿼리의 종류에 따라 필요한 메소드만 접근할 수 있도록, 프로토콜을 세분화 해서 ISP 원칙을 좀 더 잘 지키게 하는 것이 목적입니다.
✅ 예상 작업 범위
예상되는 변경 영역을 적어주세요.
Core/Supabase/Database 그룹 내부 파일 전체
쿼리를 구성하는 방식 자체가 바뀔지는 예상이 잘 되지 않습니다. PR에 상세한 내용을 작성하겠습니다.
💬 기타 논의 사항
구현 방식에 대해 논의하고 싶은 점, 기술적 고민 등이 있다면 자유롭게 작성해주세요.
한 가지 문제가 남을 수 있는데, 쿼리가 다 완성되지 않았음에도 request()에 접근할 수 있는 문제는 어떻게 해결해야 할까요?
🔧 작업 배경 및 개요
현재 Supabase DB에 접근할 때,
SupabeDBRequestBuilder라는 클래스를 통해서 쿼리를 구성하게 됩니다. 현재 이 클래스는RemoteDBRequestBuildable이라는 단일 프로토콜로 추상화 되어있지만, 쿼리 종류에 상관 없이 모든 메소드에 접근하려는 문제를 해결하려고 합니다.만약 Fetch 작업을 수행할 때,
setData와 같은 메소드는 접근하면 안되는데, 접근이 가능한 문제가 있습니다. 따라서 각 쿼리의 종류에 따라 필요한 메소드만 접근할 수 있도록, 프로토콜을 세분화 해서 ISP 원칙을 좀 더 잘 지키게 하는 것이 목적입니다.✅ 예상 작업 범위
Core/Supabase/Database그룹 내부 파일 전체쿼리를 구성하는 방식 자체가 바뀔지는 예상이 잘 되지 않습니다. PR에 상세한 내용을 작성하겠습니다.
💬 기타 논의 사항
한 가지 문제가 남을 수 있는데, 쿼리가 다 완성되지 않았음에도
request()에 접근할 수 있는 문제는 어떻게 해결해야 할까요?