Today I Learned 날짜 2024년 5월 24일 금요일 내용 테스트 코드 작성을 위한 DB 모델링 우리 서비스의 테스트 코드는 pytest로 작성되어 있고, 데이터베이스는 SQLite다. SQLite는 파일 형식이라 만들고 뚝딱 삭제해버리면 금방이다. 우리 데이터베이스인 Postgres 와 마찬가지로 SQL이긴 하나 약간의 기능 차이는 존재한다. 하나 꼽자면 jsonb 타입의 필드가 없다. jsonb는 json과 달리 내부의 키로 검색할 수 있는 나름 유용한 타입이다. 쇼피파이에서 넘어오는 스토어 데이터는 Shop 테이블에 담긴다. 가공없이 그대로. 스토어와 관련해서 우리가 필요하고 자주쓰는 데이터는 이 자식테이블 격인 shop_detail에 담긴다. 여기에 apps_log라는 이름으로, 그 스토어가 활성화한 서비스가 어떤 것인지를 담는데 이 필드가 jsonb 타입이다. ...
Today I Learned 날짜 2024년 5월 23일 목요일 내용 서비스 독스 작성 올해 회사에서 이룰 개인적인 목표 중 하나는 우리 팀의 서비스에 대한 Docs를 작성하는 것이다. 처음 계획은 어떤 기능이 어떤 함수, 어떤 파일에서 어떻게 데이터를 주고받는지를 기록하려고 했다. 내가 보기 위해서기도 하지만, 여러 사람이 협업하는 만큼 다른사람이 작성한 코드를 읽고 파악하는데 낭비되는 시간을 최소화하기 위해서였다. 문서를 작성하는 시간만큼 내가 코드 보는 눈도 좋아질 것이고.. 조언과 여러 생각 끝에 방향을 틀어 기능과 흐름에 대해 작성하는 걸로 수정했다. 이렇게 되면 코드와 언어 자체에 대한 해석은 부족할지라도 전체적인 흐름을 파악할 수 있어 큰 그림의 이해가 더 쉽다. 또한 문서를 읽을 수 있는 사람이 개발자로 한정되지 않는다. 아주 약간, 조금의 짬이 차면서 기능을 개발하면서 생기는 고민은 코드 퀄리티나 방식에 대한 고민도 있지만, 지금은 에러가 나거나 로직상 구멍이 나서 유저가 원치않는 상황에 직면하게 되는 것을 더 걱정하게 되었다. 지금 시점에서 더 깔끔하고 근사한 코드를 짜는 사람보다는 계획 수준에서부터 그림을 그릴 줄 아는 개발자, 내가 들여야 할 공수와 시간을 정확하게 계산해 낼줄 아는 개발자가 되고 싶다. ...
Today I Learned 날짜 2024년 5월 22일 수요일 내용 데이터 삭제 관리 서비스 내에 별개의 앱이 생성되면서 이것저것 분기 테스트를 진행중이다. 어떤 샵이 어떤 서비스를 사용하고 있는지, 어떤 앱을 설치했는지가 항상 정확하게 처리되어야 한다. 설치 과정에서 발생하는 문제들은 여러 테스트들에서 이상이 없었다. 샵을 삭제할 때, 연결된 계정의 삭제여부도 결정해야한다. 어떤 계정이 더이상 연결된 샵이 없으면, 그 계정은 삭제되어야 한다. 기존에는 알파플러스 앱에 있는 샵들만 확인하면 됐었는데, 이제 확인해야할 샵이 늘었다. 이 부분을 뒤늦게 파악하여 부랴부랴 추가해주었다. ...
Today I Learned 날짜 2024년 5월 21일 화요일 내용 사건사고(?) 백서 그동안 사내 다른 사버스들에서 발생했던 중대한 문제들에 대한 백서 공유 시간이 있었다. 자세히 이야기하자면 길지만 서버 문제로 고객사들의 스토어에 문제가 생겨서 발생한 문제들이었다. 사실 jsdeliver가 작동하지 않았을 때, FastAPI에서 자동으로 생성해주는 swagger UI 문서가 제대로 뜨지 않고, 내 개인 블로그도 고장나서 알게 되었다. 우리 글로벌 서비스의 위젯도 작동하지 않았지만 다행히 문제제기는 없었다. 문제가 있었던 오전 9시부터 11시는 미국 LA 기준으로 오후 5시부터 7시 쯤이니 잘 몰랐던 건 아닐까! 나중에 백서 쓸일이 없었으면 좋겠다. ...
Today I Learned 날짜 2024년 5월 20일 월요일 내용 앱 설치 링크 이제 우리 서비스는 2가지 앱을 같은 어드민 페이지에서 지원한다. 브라우저 부스터 앱을 사용하는 사람이 알파플러스 앱에 접근하려고 하면, 앱 설치 URL로 리다이렉트 시켜줘야 한다. 쇼피파이 앱 스토어에서 설치할 때, 바로 해당 앱을 설치하기 위한 권한을 묻는 페이지로 넘겨줬어야 했는데 저번주 내내 열심히 뒤져봤지만 못찾았다.. 분명 다른 앱에선 구현해놓은 건데… 이 부분을 해결했다! 쇼피파이와 우리 서버가 통신을 주고받는 엔드포인트는 3개다. ...
Today I Learned 날짜 2024년 5월 17일 금요일 내용 Shopify API 버전 웹훅이 안되는 이유를 알았다. 새로운 앱의 API 버전은 2024-04였다. 기존 우리앱은 버전이 2023-07이었는데, 웹훅 등 Shopify와 통신을 이것저것 주고받을 때 항상 API 버전을 Query Param으로 주어야 한다. 새로운 앱과 통신할때도, 환경변수로 설정된 이전 API 버전을 변수에 담아 주었으니 당연히 401이 떴다. 회고 한 주의 마무리는 오후반차.
Today I Learned 날짜 2024년 5월 16일 목요일 내용 서비스 시작 분기 앱이 2개로 분리되면서 앱을 설치할 때의 분기가 꽤나 복잡해졌다. 해당 쇼피파이 계정으로 알파플러스 서비스에 처음 가입하는 유저 해당 쇼피파이 계정의 다른 스토어로는 알파플러스 서비스를 이용하였으나 지금 스토어로는 처음 가입하는 유저 해당 스토어로 알파플러스 서비스를 가입하였으나 브라우저부스터는 처음인 경우 정도가 있다. 물론 브라우저부스터와 알파플러스가 반대인 경우도 있긴 하지만.. 2번과 3번 과정이 꽤나 헷갈렸다. 우리 서비스 로직으로는, 우선 설치하는 과정에서 샵 데이터를 생성한 후, 온보딩(혹은 계정 통합 과정)을 거치면서 이 샵 데이터가 계정 데이터와 연결된다. 3번은 바로 로그인 화면으로 이동해줘야 하므로 별도의 계정 연결 과정이 없다. 따라서 샵 데이터가 생성될 때 이뤄저야 한다. 따라서 샵을 만들때, 그 샵의 URL로 다른 앱 데이터를 탐색해서 존재하는지 확인했다. 존재한다면, 그 데이터와 연결된 계정에 이 샵도 바로 연결해주었다. ...
Today I Learned 날짜 2024년 5월 14일 화요일 내용 QA 제법, 아니 꽤 많이 미완성인채로 일정대로 QA가 진행됐다. 자질구레한 것 여러가지를 뜯어고쳤고, 앞으로도 뜯어 고칠게 참 많다. 앱 삭제 기능 쇼피파이에서 고객이 앱을 삭제하면 웹훅을 이용해 우리 서비스에 호출을 보낸다. 그럼 우리 서버 내에 데이터들을 삭제해주어야 한다. 이 기능이 작동을 안하고 있다. 따로 엔드포인트를 이용하면 기가막히게 삭제가 되는데… 주소가 잘못 되어있는 것 같아 수정하고, 기능이 새 앱에서는 작동되지 않도록 설정되어 있어 그 부분도 손봤는데 여전히 작동하지 않는다. elastic apm을 홗인해보니 웹훅을 처리하는 라우터 자체가 호출된 흔적이 없었다. 기존에 있던 웹훅 조회하는 함수를 조금 손봐서 새 앱에도 쓸 수 있게 해봤는데, 웹훅 조회자체가 안된다. 없을 거라 예상했는데 조회가 안되는건 예상 못했는데.. ...
Today I Learned 날짜 2024년 5월 13일 월요일 내용 1 스토어 2 앱 설치 하나의 스토어에 우리 앱 2개가 설치되지 않는다. 쇼피파이에게 문의한 결과는 “개발에 관련된 질문은 받지 않으니, 개발자 커뮤니티를 이용하거나 우리 디스코드에 들어와!” 내가 안찾아봤겠냐고… 거기도 이미 답변을 다는 사람에 비해 너무 많은 질문이 올라온지 한참되버렸을 뿐더러, 내가 원하는 질문은 찾을 수도 없었다. 별 수 있나? 열심히 짱구 굴려봐야지.. 답이 없을 것 같았던 문제는, 전지전능하신 선배님의 도움으로 해결되었다. 브라우저 부스터 앱 설치를 테스트 서버로 넘기기 전에, ngrok을 이용해 내 로컬로 설치할 수 있다. 더 쉽게 말하자면, 유저가 “앱 설치할래요!” 라고 요청을 보내면, 쇼피파이와 앱 서버(여기선 우리 테스트 서버)는 검증받은 앱인지, 올바른 URL인지 기타 등등을 검증하고, 데이터를 주고 받는다. 이 과정에서 우리 서버에는 설치한 스토어의 정보가 저장되고, 새로운 손님에겐 우리가 미리 설정한 주소(온보딩 or 로그인 페이지)로 리다이렉트 시켜준다. ngrok을 이용하면 쇼피파이가 테스트 서버 대신 내 로컬과 이야기를 주고받도록 설정하는 셈이다. ...
Today I Learned 날짜 2024년 5월 10일 금요일 내용 프로덕트바리언트 가격 리스트디자이너 위젯에서 할인 전후 가격이 바뀌어서 나타나고 있었다. 알고보니 쇼피파이에서 보내는 데이터 상으로 compare_at_price가 할인 전 가격(높은 가격)이고 price가 할인 후 가격(낮은 가격)인데 바꾸어서 데이터로 저장하고 있었다. 애초에 변수 이름을 좀 알아보기 쉽게 짓지 거참.. 온보딩 앱 두개가 하나의 시작점을 지니도록 처리하려니 신경써야 할 부분이 한 두개가 아니다. 예를 들어, 어떤 계정이 3개의 스토어에 우리 서비스를 설치했다고 가정해보자. A 샵은 알파플러스만 사용하고, B 샵은 브라우저 부스터만 사용, C 샵은 둘 다 사용한다. 계정은 두 서비스를 다 사용한다는 변수를 프론트에게 제공하고 있고, 세션에 저장된다. 그럼 각 샵은 어떻게 처리해야할까? 어드민 페이지에서 A샵이나 B샵을 선택하면 그 샵이 설치한 앱(A샵은 알파플러스, B샵은 브라우저 부스터)에만 접근하도록 해주어야 한다. C샵은 둘 다 접근할 수 있어야 한다. 로그인 시점에 이 정보가 프론트에게 주어져야 한다. 이런 부분이 한두 개가 아니다.. 기존 알파플러스 서비스를 망가뜨리지 않고 새로운 앱을 합치다 보니 머리가 너무 복잡하다ㅏㅏㅏㅏㅏㅏ…. ...