Shopify

Today I Learned 날짜 2024년 6월 4일 화요일 내용 쇼피파이 임베디드 앱 임베디드 앱이라 하면, 쇼피파이 어드민 내에서 작동하는 앱을 의미한다. 기존 우리 앱을 실행할 경우 우리가 별도로 구현한 서비스 페이지로 이동한다. 임베디드 앱은 아이프레임을 이용해 쇼피아이 어드민 내에서 내부의 창을 통해 접속한다. 쇼피파이 어드민에서 접근하기 때문에 별도로 계정을 처리해야 할 스트레스가 없다는 것이 장점이다. 이 장점은 나에겐 별도의 스트레스가 되었다. 우리 서비스는 2개의 서버로 구성된 MSA 방식이라 샵과 리뷰를 기준으로 구분되어 있다. 이번 스프린트에서 만들 기능은 별도의 앱이긴 하나 매우 작은 기능이라 데이터가 거의 없다. 테이블도 하나면 충분하고, 거기서도 shopify에서 주는 access_token 만 저장하면 된다. Redis에 데이터를 저장하지 않기 떄문에, 분리할 경우 불필요한 리뷰서버와 샵서버 간 통신이 많아 질거라고 생각해 이 서비스는 리뷰서버에서만 처리되도록 구현할 계획이다. ...

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월 8일 수요일 내용 Shopify session 새로 추가될 앱을 같은 서버에 만들었다. 앱이 설치되는 방식은 대략 다음과 같다. 쇼피파이에 설정해둔 우리 서버의 엔드포인트로 요청이 들어오면(/shopify) 우리 서버는 shopify_session을 이용해 허용 URL을 만들고 redirect시킨다. 앱을 설치하는 고객은 앱이 요청하는 권한(고객 데이터 접근, 주문 데이터 접근 등등)에 대해 확인하고 허가하는 창으로 안내되고, 허용하면 다시 우리 서버로 요청이 넘어온다. 이후로 온보딩 플로우로 넘어가든, 로그인으로 넘어가든 우리 코드대로 처리된다. ...

Today I Learned 날짜 2024년 4월 9일 화요일 내용 고객들의 기능 활성화 여부를 체크하는 기능을 만들었다. 코어스크립트 고객이 위젯을 스토어에 설치하기 위해선, “코어 스크립트”를 활성화 해야한다. 위젯이 정상적으로 작동하도로록 해준다. 우리 서비스에서 위젯은 핵심적인 부분이기 떄문에 코어스크립트가 활성화되어 있지 않다는 의미는 우리 서비스를 제대로 활용하지 못하는 뜻이다. 각 서비스(알파리뷰, 리스트 디자이너)는 제각각 코어스크립트를 가지는데 이를 활성화했는지를 알아봐야한다. 스토어가 사용하고 있는 메인 테마를 찾아야 한다. Shopify로 요청을 보내면 된다. 이렇게 목록들이 나타나니 원하는 값을 찾으면 된다. 한번도 활성화한 적이 없는 항목은 나타나지 않는다. 따라서 없거나, “disabled”가 true일 떄가 비활성화인 상태다. ...

Today I Learned 날짜 2024년 4월 5일 금요일 내용 개발보단, 팀이 나아갈 방향에 대해 하루종일 고민했다. 리퀴드 쇼피파이에서는 리퀴드를 쓴다. 리퀴드는 루비를 기반으로한 HTML 템플릿 언어이다. 쇼피파이에 올라간 데이터들을 주고 받는게 Liquid로 작성된 앱블록에서 이루어지는데, 정말 놀랍게도 Shopify 정책상 1개의 앱이 사용할 수 있는 앱블록의 총 용량은 고작 100KB로 정해져있다. WOW 그리고 수 많은 위젯을 구현한 우리 서비스는 한계에 봉착했다. 더이상 여유 용량이 없다. 해결을 위한 여러 고민들을 더 자세히 쓰고 싶은데, 들은걸 100% 이해하지 못해서 못쓰곘다! 결론은, 새로운 앱을 만들되, 서버와 DB는 같이 쓰고, 어드민 페이지도 하나로 유지하기로 했다. 별개의 앱 사용자들이 하나의 서버와 어드민으로 들어오기 떄문에 이에 대한 여러 장치가 필요하다. 그리고 앱을 출시하는 과정 자체에 대한 공수도 필요하고.. 자연스레 할 일이 많아졌다! ...

Today I Learned 날짜 2024년 4월 4일 목요일 내용 고객 체크 계속 고민했던대로, 고객에 대한 데이터를 얻기 위해 수정이 필요했다. 다른쪽에서도 비슷한 결의 문제가 발생했는데, 프론트에서 유저가 받아야 할 쿠폰이 무엇인지 알 수 없었다. 쿠폰을 받기위한 이벤트의 진행 과정은 프론트에서 개별적으로 발생하는 반면, 쿠폰은 서버에서만 처리하니 둘의 싱크가 안맞아서 발생하는 문제 같았다. 결국 쿠폰을 발급할 때, 고객이 로그인하도록 과정을 추가해야 했다. 테스트 코드 약 2시간을 투자해서 테스트 코드를 작성했다. 무려 몇개월 전에 만들었던 AI 관련된 기능들에 대해서 작성했다. 리뷰의 키워드를 분석하고 횟수를 계산하는 것, 긍정과 부정을 분류하는 것, 요약을 만드는 것 3가지를 만들어주었다. ...