[Serverpod] Dart 로 서버 개발을?

서론

Serverpod 소식을 처음 듣게된 건 한 달 정도가 되지 않았을까싶다. Flutter 개발자인 나로서는 Dart 로 서버를 개발할 수 있다는 Serverpod 에 대해 구미가 돋지 않을 수 없었달까.

업무가 너무 바빠서라는 직장인들의 좋은(?) 변명거리에 힘입어 Serverpod 알아보기를 미루고 미루다가 마침 시간이 나 짬짬히 튜토리얼을 진행해보았다.

한때 서버 개발자였던 나로서는 꽤 적지 않은 부분을 지원하지 않는다는 점으로, 아 아직 1.2 버전이라 그런가? 싶은 생각이 들었다. Serverpod 의 튜토리얼을 진행하며 들었던 보잘 것 없는 의문은 다음과 같았다.

그럼 이건 어떻게 하지?

• 엔드포인트를 플러터에서 매우 간단하게 호출할 수 있다는 점에 대해서는 매우 편리하나, HTTP Method(POST, GET, PUT, DELETE 등..) 를 어떻게 정의하지?

• 200번대, 400번대와 같은 상태 코드는 클라이언트에게 어떻게 담아서 전달해줄 수 있을까?

• 응답전문의 일반화(statusCode, message, data 등의 프로퍼티를 지닌 Base Response DTO)를 만들어 클라이언트에게 제공하기 위한 Response Interceptor 는 어떻게 정의할 수 있을까? (억지로 구현해본다면 가능이야 하겠지만, Serverpod 에서 실제 HTTP Status Code 와 Base Response DTO 내에 담긴 Status Code 의 불일치의 이슈가 발생할 수 있을 것 같다.)

• Swagger 와 같은 API 문서화 지원 여부

그리고 찾은 내용

서버 개발자의 입장에서는 프로젝트 초기화 시 이러한 기본적인 작업은 짚고 넘어가면 후에 이롭기 때문에 관련 자료를 찾아보았다.

공식 깃헙의 Discussion 을 열심히 찾아보니 REST API 보다는 RPC(원격 프로시저 호출)에 더 초점이 맞춰져 있다는 메인테이너의 답글을 보고서는 이러한 의문이 풀렸달까..

Serverpod is more aiming to be a RPC (remote procedure call) over a REST API. That being said, it's, of course, possible to call your serverpod using REST methods, but the preferred way is to use the generated client.
(Serverpod 은 REST API 보다는 RPC 에 더 초점이 맞춰져있습니다. 당연히 REST API 로도 호출이 가능하지만, Generated Client 를 사용하는 것이 권장됩니다.)

당연히 이러한 의문을 가졌던 건 비단 나뿐만이 아니라 다른 개발자분들도 꽤나 많았나보다. Discussion 을 찾아보니 HTTP Method 정의나, Middleware 지원 여부, 커스텀 Response 등에 대한 글들을 나름 심심치 않게 찾아볼 수 있었다.

서버의 목적이 기존의 전통적인 클라이언트-서버 간 API 호출보다는 Serverpod 에 의해 제네레이트된 엔드포인트의 함수형 호출에 가깝다보니 어떻게 보면 API 도큐먼트 정의만 잘 되어있다면 이러한 문제는 어느 정도 상쇄할 수 있겠구나 싶었다.

그러나... 이러한 API 독스를 를 자동으로 생성해준다거나 하는 기능은 아직까지는 없고 수동으로 작성해야하나보다. HTTP Method 나 응답 전문까지는 바라지는 않더라도 어떤 API 들이 있는지 정도는 한 눈에 나열할 수 있다면 좋기는 할 것 같다.

사용해봤는데..

프로젝트 세팅만 해도 DB부터 Redis, 서버/클라이언트 보일러플레이트까지 원큐에!

Serverpod 프로젝트를 생성하기 위해서 Docker 는 필수다. Docker Compose 를 통해 Serverpod/Flutter/PostgreSQL/Redis 까지 자동으로 생성해준다.

데이터베이스에 접근하기 위한 비밀번호도 환경 별로 난수로 생성해준다.

개발/스테이징/프로덕션 콘피그까지 생성!

위의 사진에서 확인할 수 있었겠지만, 운영환경별로 콘피그까지 생성해준다. 다음 사진은 개발 환경일 경우에 대한 콘피그이다.

자동 생성되는 API 호출 메소드

오 편하다! 아주 편하다. 아직까지는 튜토리얼까지만 진행해보았는데, RPC의 가장 큰 장점은 뭐니뭐니해도 외부에 존재하는 함수를 마치 내장된 함수처럼 자유롭게 사용할 수 있다는 점 아니겠는가!

Serverpod 에 의해 자동으로 생성된 엔드포인트 파일은 Flutter 내에서 메소드 호출하듯이 자유롭게 호출이 가능하다!

이러한 엔드포인트 메소드는 서버 단에서 다음과 같이 간단히 구현할 수 있다.

편리한 ORM

서버 내에서 엔티티 생성과 이를 통한 CRUD 지원까지 아주 편리하다.

엔티티 생성의 경우, .yaml 파일을 통해 만들어야하는데, 나중에는 자동 완성도 지원될련지 모르겠다.

일단 엔티티 생성 같은 경우는 다음과 같이 이루어진다.

간결하다. class 는 Serverpod 에 의해 자동으로 생성될 클래스명이고, table 은 데이터베이스에 실제 생성될 테이블명이다. fields 는 테이블 내에 생성될 필드이다. 상기 사진에서는 text 필드를 String 타입으로 생성하였다. 각 필드에 지정될 자료형은 Dart 의 자료형을 그대로 따른다.

이렇게 함으로써 플러터 클라이언트에서는 해당 인스턴스를 활용하여 서버에 데이터를 담아 엔드포인트를 호출하여 데이터를 서버에 전달할 수 있다. 서버에서는 해당 인스턴스를 활용하여 CRUD 작업을 수행할 수 있다.

즉, 서버 단에서는 다음과 같이 생성된 모델에 접근하여 CRUD 작업을 수행할 수 있다.

클라이언트 단에서는 다음과 같이 생성된 모델에 값을 담아 인스턴스화하고 엔드포인트 메소드를 호출하여 값을 담아 전달할 수 있다.

이렇게 .yaml 파일을 통해 생성된 클래스는 데이터베이스 Migration 커맨드를 통해 간편하게 데이터베이스에 새 테이블을 생성할 수 있다.

결론

아직까지 Serverpod 에 대해서 깊숙한 부분까지는 알아보지 못해서 Serverpod 이 지닌 강력한 기능들에 대해서는 더 알아보아야할 것으로 보인다. Authorization 도 매우 편하게 구현할 수 있고 OAuth2 와도 간단하게 구현이 가능하다고는 하니, 좀 더 알아보아야겠다.

간단하게 Serverpod 튜토리얼을 진행해보고 든 생각은 "1인 개발 하기에는 편하겠다" 와 내 생각을 빠르게 검증해보고 싶을 때, 또는 MVP 제품으로 아이디어 검증 등 빠른 구현이 필요할 경우에 매우 유용할 것으로 보인다.

RPC 인만큼 REST API 의 활용과는 약간 거리가 멀어보여 전통적인 앱-서버 간 API 통신 및 이를 활용한 클라이언트 구현 플로우가 조금 달라 낯설기는 하지만, 충분히 토이 프로젝트용으로 갖고 놀기에는 매우 재미있어 보인다.

이 글을 쓸때까지만 해도 Serverpod 1.2 버전이었지만 최근 확인해보니 2.0 버전이 런칭이 된듯하다.

2.0도 구경해보러 가야지..

귀찮지만 않다면 다음 포스팅에는 Serverpod 2.0 을 활용한 간단한 TODO 앱을 구현하는 과정을 작성해봐도 재미있을 것 같다.