문제

처음엔 기능에 맞춰서 Node.js로 서버 짜다가, 중간에 일부 처리로직이 맘에 안들어서 Python으로 짠 서버를 옆에 딱 뒀다가, 나중엔 GraphQL이 대세지! 하면서 Rust로 서버 짜다가 클라이언트를 리팩토링하려고 해 봤더니…

(-) 일단 클라 코드가 똥코드

대충 되게만 만들어놓고 묻어뒀던 코드를 리팩토링하려니 손이 많이 간다

(+) 그나마 모듈화는 해 놔서 다행

Store라는 이름의 클래스에 전반적인 외부 통신 영역을 모두 넣어놨기 때문에 이것만 고치면 될 것 같은 희망이 있었다.

(+) 일단 기존 코드는 지우지 마

결론부터 얘기하자면 리팩토링할 때 일단 기존 코드는 건드리지 않고, 건드릴 일이 있으면 바로 fork를 하라는 것이다. 이를테면 Store 클래스를 바로 고치지 말고, Store2를 만들고 다시 구현한 다음에 기존 Store 클래스의 사용자들을 점진적으로 옮기는 방법이 낫다는 것.

(-) 그럼 기존 코드는 언제 지워?

못지워. 지울 생각 마. 코드 지우기가 코드 쓰기보다 10배는 더 어려운듯. 그나마 내부 로직은 find reference 해봐서 없으면 아 이제 지울 수 있구나 할 수라도 있지, 서비스 API는 이런 방식으로는 절대 못지운다.

더 뒤쪽의 데이터베이스로 가면 거기부턴 그냥 안지운다. 처음부터 데이터베이스를 모듈로 감싸놓지 않는 한, 누가 어떻게 데이터베이스를 접근하는지 추적하기가 어려워서 못지운다.

생각보다 별 문제가 아니었던 부분: REST와 GraphQL의 차이

아직 GraphQL도 별로 복잡한 쿼리같은건 구현하지 않아서, 그냥 REST와 호출 자체는 별로 다르지 않다. 어차피 쌈마이 CLI툴 혹은 야매 Frontend라서 쿼리 두개 이상 날려가면서 UI를 복잡하게 그리는 일 자체가 없어…

다만 Apollo client를 사용하는 경우, 별 생각 없이 기본 quickstart를 따라서 설정하는 경우 InMemoryCache를 적용하기 때문에 기존 REST의 동작과 달라지는 점을 주의해야 한다. 데이터를 새로 쓰고 이제 바뀌었겠지? 하고 다시 쿼리를 했는데 새로 쓴 값이 안보이는 것처럼 보이면… 다만 best practice는 데이터를 쓰는 시점에서 로컬 캐시도 변경하거나 invalidate하고, 쿼리할 때도 기존에 아는 값은 그대로 두고 새로 모르는 값만 불러오는 것이 효율적인 사용법이라는 것은 염두해 둬야 한다.