01. API 서버 마이그레이션의 결심

EZC·2024년 8월 2일
0
post-thumbnail

목차

프로젝트 진행 배경

  • pure PHP 코드로 인해 뒤엉켜있는 FE / BE 코드
  • n(n>15)n(n > 15)년 간의 코드 누적 : 미사용 코드 다수, 실제 사용되는 로직은 극히 일부
    • 수기처리 코드 : 공통로직을 찾아내 최대한 모듈화, 객체화를 하여도 기존 수기처리로 인해 이전 코드와 큰 차이가 없었다.
    • 몇 만 줄의 한 파일 : 한 파일 당 한 기능을 하지 않고, 기본적인 절차/객체지향의 코드 형태를 따르지도 않았다.

따라서 부분적으로 마이그레이션을 하는 것이 가장 현실적이고 실현 가능한 방법이 아닐까, 하는 생각이 들었다.

초기 사용 스택

최대한 오래 갈 수 있는 스택을 선택했으며, 다른 모듈이나 라이브러리도 많지만 일단은 초기 구성을 최소화 하고 추후 고도화 시킬 수 있는 방향으로 셋팅했다.

  • node.js 20.10.0 LTS + express 4.19.2 (+ dotenv등 기타 npm 모듈)
  • sentry
  • typescript 5.5.3
  • 기존 DB : My SQL, MS SQL (SQL Server), Oracle 모두 사용

선정 이유

기재해둔 내용이 상당히 적다. compact한 틀을 만드는 것이 첫번째 목표였기 때문이다.
그 외에도 아래의 목표들이 해당 스택 선정의 이유가 되었다.

  1. 범용성, 커뮤니티 규모 : 프레임워크를 사용하지 않고 pure PHP를 사용하던 팀원들이 접할 수 있는 자료가 충분한가?
  2. 정규화 : DB에서 정규화가 되어있는 편이 아니다. API단에서 이를 보완할 수 있는가?
  3. 확장성 : 기존 서비스는 많은 기능이 동작 중이다. 내가 알지 못하는 영역이 분명히 존재할 것이기 때문에 초기엔 최대한 컴팩트하게, 그리고 이후 기능 추가는 쉬워야 한다.
  4. 빌드 용이 : CI/CD, 미러링이 구축된 환경이 아니기 때문에 빌드가 하나의 변수로 작용할 수 있다.
  5. 영구성 : 오래 유지/사용할 수 있는 버전or환경인가?
  6. HTTP2 프로토콜 사용

탈락했던 후보군

  • java 계열 : Spring boot + kotlin

    • 장점
      • 정규화, 객체/인스턴스 관리가 용이하며 강제성을 띄며, 이에 대한 자료도 많다.
      • annotation의 활용 : 타 언어에 비해 annotaion의 역할과 명시성이 확실하다.
    • 반려 사유
      • 기존 인력의 낮은 친숙도 : 정적 언어의 특성, Java / Gradle syntax를 알고 있어야 접근성이 좋다.
      • 빌드
  • python : Django rest framework

    • 장점 : PHP와 가장 비슷한 언어적 특성, 친절한 템플릿
    • 반려 사유 : RESTful 할 수 있지만 이후 설명할 정규화가 흠이 되었다.
  • javascript : Next.js API Routes

    • 반려 사유 : 빠르게 변화하는 프레임워크, 파일 구조 기반 url라는 리스크, 비교적 적은 자료(14), 검색엔진을 따로 사용하지 않는 환경
    • 결정적인 반려 사유 : FE / BE 서버가 분리되지 않은 입장이라면 유용하겠지만, 분리 목적으로 넥스트를 바라보니 장점이 떠오르지 않았다.
    • 그 외에도 JS기반 프레임워크는 수 없이 존재하지만 가장 자료가 많고, 확장성이 큰 express를 선정하게 되었다.

PHP 기반 프레임워크의 반려

php is dead 밈이 나올 정도로 수십년간 건재한 PHP.. 때문에 PHP라는 언어 자체를 피하고 싶다는 강박은 없었다. (오히려 앞서 언급한 '영구성'에 가장 잘 부합하는 것이 PHP가 아닐까 싶다.)
tellme_yes

다만 PHP를 기반으로 하는 Laravel과 Composer, CodeIgniter 등은 아래의 이유로 배제하였다.

  1. 범용성
  • 압도적으로 적은 자료 수 : 자료 자체의 수가 타 프레임워크 (spring 계열, node.js 계열)과 차이가 컸다.
  • PHP 버전 종속성 : 찾은 자료가 있어도 PHP가 버전에 민감하다 보니, syntax 지원이 안돼 페이지가 먹통이 되는 일이 잦았다.
  1. 동적 언어 PHP
  • 입출력 / 배열 관리를 중점해 처리할 수 있는 환경이 아니었다.
  • 한 페이지에서 여러 형태의 데이터 입출력이 처리되는 경우가 많음
  • 모든 페이지에서 일정한 데이터를 사용하지 않음 : 비슷한 형태는 많지만, 동일한 형태는 희소함

앞으로의 계획

스크래치부터 시작하고자 한다. 개발환경 구축부터
1. VS Code 환경 구축하기 : express + eslint + dotenv 환경 구축
2. docker 환경 구축 : node 설치, git 연결
3. alias, HTTP2 설정 : localhost에서 테스트
4. sentry 로깅 설정
5. auth 관련 구현 : 이 부분은 벨로그에 기재하지 않을 예정이다.
6. DI 이용하여 커넥션 / 모델 구현 및 테스트

여태까지 겪은 pure PHP 스파게티 코드들에게 안녕을 고할 수 있기를 바라며! 글을 마친다.

PHP_still_alive

profile
코딩하는 햄스터

0개의 댓글