Server Driven Design 요소 및 템플릿화

서론

개인적으로 진행하던 프로젝트 중 축제와 관련이 있는 웹 프로젝트가 있었다.

축제의 디자인 포맷은 대부분 동일하고 변경되어지는 것은 시간표, 장소, 일정, 문구, 이미지 등등... 이 있었는데

한번의 개발을 통해서 여러 축제에 사용 될 수 있는 범용적인 웹 어플리케이션을 구축해야했다.

 

그런데 그때 당시에 읽었던 글 중 요기요에서 어플리케이션 Server Driven UI 를 보고 영감을 받았고 그것을 참고해서 진행했다. https://techblog.yogiyo.co.kr/%EC%9A%B0%EB%8B%B9%ED%83%95%ED%83%95-server-driven-ui-%EA%B0%9C%EB%B0%9C%EA%B8%B0-b1b80f47760b

우당탕탕 Server Driven UI 개발기

 

설계

일단 설계를 하기 이전에 사람이 필수적으로 할 수 밖에 없는 작업을 생각했다.

도메인 연결, 검색 엔진 관련, 프론트 배포 등등이 존재했고 이러한 부분을 제외하고는 시스템 설계 부분에 다 녹여서 진행했다.

프론트

프론트의 설계는 간단했다.

1. 서버로부터 축제정보를 가져와서 렌더링(기본정보, 축제이름, 일시, 장소 등등...)

2. 서버로부터 디자인정보를 가져와서 렌더링(표 정보, 이미지, 설명 글 등등...)

3. 서버로부터 백오피스 정보를 가져와서 렌더링 상호작용(수정, 제거, 등록, 등등... )

4. 모든 API 는 백엔드로 부터 초기에 발급되어진 토큰으로 이루어진다.

예시로

 table: {
        ths: [
            { ...thProps, children: '종목' },
            { ...thProps, children: '순위' },
            { ...thProps, children: '시상' },
            { ...thProps, children: '비고' }
        ],
        trs: [
            [
                { ...tdProps, children: '하프코스 부문', rowSpan: '4' },
                { ...tdProps, children: '1위' },
                { ...tdProps, children: '20만원, 상장, 트로피' },
                { ...tdProps, children: `1-3위 현장 시상\n상금은 계좌이체`, rowSpan: '4' },
            ]
        ]
}

이런 형태의 Json 이 온다면 해당하는 표를 자동적으로 만들어준다.

 

해당 Json 이 javascript (...)같은 경우는 초기 데이터의 경우에는

프론트에서 제공되어지는 것을 기반으로 하고 그 이후에 서버에서 제공되어지는 data를 기반으로 rendering 이 되어지기 때문이다.

 

백엔드

백엔드의 경우에는 해당 축제에 대한 정보 및 디자인 정보, 백오피스 정보 및 사이트 관리를 중점을 두어서 설계를 했다.

1. 프론트에 해당하는 축제 토큰 등록 후 축제 정보 API, 축제 디자인 정보 API 제공

2. 토큰 기반을 통한 축제 별 백오피스 기능 구현(A축제, B축제 축제별 참여인원 관련 API 제공)

 

구현

구현의 경우에는 어렵지 않았고 특별하게 한 것만 적으면

 

위의 Json을 손수 적는 것은 비효율이었기에 Json Generator 라는 함수를 만들어서 간단하게 정보만 입력하면 Json 형식이 나오도록 함수를 제공해줬다.(폰트 관련, 축제 정보 관련)

 

그리고 이메일 관련해서 단일 Thread 로 진행시 Blocking 이 되어 전체 서비스의 영향을 끼쳐 멀티 Thread 를 통해서 진행하도록 변경하여 서비스의 영향을 덜 끼치도록 변경했다.

 

백엔드의 경우에는 서버 하나만 올리면 되어서 끝났으며 프론트의 경우에는 build 이후에 토큰만 발급받아서 S3 를 통해서 올리는 형태로 

백엔드(1) - 프론트(N) 의 형태로 구현이 되었다.

 

후기

Server Driven Design 이라고 말하고 뒤돌아봐서 생각해보니 단순 작업을 줄이는 역할로 치우쳐져서 사용했다는 것을 조금은 느꼈다.

 

현재 설계로 했을 때 가장 큰 장점은 사용자 측면에서 개발과 관련된 수정, 배포 관련을 모르고도 진행을 할 수 있다는 점이다.

축제 관련자 수정 요청 -> 개발자 수정 요청 사항 반영 및 재배포 -> 축제 관련자 확인

이러한 순서를 갖추는데

지금의 장점은 축제 관련자가 문구 수정이나 테이블 수정 간단한 부분은 본인이 할 수 있다는 점이고 재배포랑 관계없이 서버에서 수정만 일어나는 경우 해당하는 부분을 바로 확인이 가능하다는 것이다.

 

그런데 이러한 부분도 있지만 어떻게 보면 중점이 템플릿화에 초점이 맞추어지다보니 프로젝트가 약간의 성향이 벗어난 감이 없지않아있다.