Today I Learned 날짜 2024년 6월 14일 금요일 내용 앱 메타필드(2) 어제 무사히(?) 앱 메타필드를 저장하는 방법을 알아냈다고 생각했으나, 오늘 왠지 또 잘 안됐다. 원인은 정확히 앱 메타필드가 어디에 어떤값으로 있는지 몰라서 발생한 일이었다. 우리야 “앱 메타필드”라고 부르지만, 정확하겐 appInstallation 이라는 객체 내에 있는 Metafield 안에 저장하는 것이다. 기존에 사용하던 샵 메타필드는 Shop 객체 안에있고.. 따라서 우리 앱의 appInstallation ID를 알아내기 위해, 고객이 우리 앱을 설치하자마자 currentappInstallation을 조회하여 저장하고, 이 객체 안 메타필드를 관리하면 된다. 이 ID값은 key나 namespace가 아닌 ownerID 라는 항목의 값으로 처리된다. ...
Today I Learned 날짜 2024년 6월 13일 목요일 내용 앱 메타필드 이번 스프린트는 인스타그램에서 댓글을 가져와 위젯으로 표시해주어야 한다. 기존처럼 쇼피파이에 있는 앱프록시를 이용해 서버쪽에서 처리하기보단, 앱 메타필드에 렌더링된 HTML 전체를 올려놓는 방식을 취해보기로 했다. 그동안은 샵 메타필드를 이용했었기 떄문에 그 샵이 설치한 다른 앱과 공유하는 메타필드였다. 앱 메타필드는 우리가 독점적으로 사용할 수 있으며, 앱을 삭제하면 자동으로 삭제된다는 장점이 있다. 다른 앱들은 유료화 기능에 이용한다고 하는데, 우린 이번 스프린트에 활용해보기로 했다. 단점이라면, 위젯의 HTML이 모두 올라가있기 떄문에 위젯과 관련된 데이터가 변경되는 즉시 메타필드에도 적용되야 한다. 이참에 앱 메타필드를 다루는 클래스를 만들어놓기만 하면 어렵진 않을것 같다. ...
Today I Learned 날짜 2024년 6월 12일 수요일 내용 개인정보 익명화하기 인스타그램 댓글을 위젯으로 만들때, 혹시나 댓글 내용에 개인정보가 있다면 익명화하는 기능을 추가하고자 한다. 집 주소, 계좌번호, 전화번호, 이름이 나타나면 별표처리를 해야했다. 개인정보를 내가 형태(글자 수 등)로 추적하는 것은 불가능했기 때문에 라이브러리를 찾았다. 영어로는 PII(Personally Identifying Information)라고 하는데, 개인을 식별할 수 있는 정보를 통칭한다. Presidio 무려 마이크로소프트에서 제공하는 오픈소스다. 언어 관련해선 Analyzer와 Anonymizer 2가지가 있는데, 전자는 nltk 처럼 글을 쪼개 분석해주는 기능이고 후자는 특정 키워드를 대체해준다. 예를 들어, ...
Today I Learned 날짜 2024년 6월 11일 화요일 내용 검색 쿼리 유저가 여러 댓글 중 무언가를 검색하거나, 데이터를 정렬하는 기능을 만들어야 했다. 기존 프로덕트 리뷰에 있는 건 너어어어무 복잡하고, 온갖 기능이 추가되어 유지보수가 힘들었다. 아예 다른 곳에서 쓰이는 것일 뿐더러 기능이나 검색 단위, 정렬 단위도 더 작은 범위라 최대한 깔끔하게 만들려고 했다. 정렬 방식이 조금 난해했는데, 정렬 기준이 2개인 경우가 있었기 떄문이다. 이번 인스타그램 댓글 가져오는 앱의 테이블 구조는 샵 → 페이스북 페이지 → 게시글 → 댓글 순서로 이루어졌으며 각각 일대다관계다. 댓글의 작성일자로 정렬할 때는 별 어려움이 없으나, 게시글 작성일자로 정렬할 떄는 꽤 어려웠다. 최근에 작성된 게시글 내의 댓글들을 먼저 가져오되, 같은 게시글 내에선 최근에 작성된 댓글이 먼저와야 했다. ...
Today I Learned 날짜 2024년 6월 10일 월요일 내용 페이스북과 인스타그램은 하나인듯 하나가 아님. 진짜다. 내가 페이스북을 끊은지 오래되었고, 인스타그램을 계정만 만들어놔서 혼나는건지 모르겠으나 얘네는 자기들 맘대로 공유하고, 분리하고 난리부르스를 친다. 상당히 맘에 들지 않으나 내가 뭘 할수 있겠는가. 그저 열심히 Docs를 읽고 만들었다. 이번 기능은 “인스타그램 비즈니스 계정”에서 게시글에 달린 댓글을 가져와야 한다. 그래서 난 인스타그램 계정에 접근하는 법을 열심히 알아봤고 기능을 구현했다. 그리고 인스타그램 비즈니스 계정과 그냥 계정은 다르다는 사실을 깨달아버렸다. 그래도 언젠가 쓰지 않을까? 하는 마음으로 한구석에 조용히 쑤셔넣어놨다. ...
Today I Learned 날짜 2024년 6월 8일 금요일 내용 에러 알람 휴일에 쉬는데, 실서버에서 에러가 난다고 온갖 알람이 오두방정을 떤다. 다행히(?) 서버 트래픽의 문제라던가, 기능상의 문제는 아니였고 크론이 실행되는 도중 발생하는 문제였다. 자동적으로 업데이트 되야할 데이터가 원할하게 돌아가지 못했다는 뜻이다. 쉬는데 참 마음이 찝찝해서 금요일이 되자마자 실서버에서 처리해주었다. 원인은 크게 두가지였다. Orphan Data 직역하면 고아 객체긴 한데.. 관계된 데이터가 없다는 뜻이다. 예를 들어, 우리 서비스에선 Shop 데이터가 존재하면 이 하위 개념으로 shop_detail 데이터가 존재하게 된다. 영속성 전이(CASCADE)를 설정해놓으면 shop이 삭제될때 연관된 shop_detail도 따라없어져야 한다. 그럼에도 불구하고 아주 낮은 확률로 혼자 남아있는 shop_detail이 발견된다면 연관된 shop이 없는 이 shop_detail 데이터를 고아 객체라고 부르는데, 이것 떄문에 발생하는 오류들이 꽤 있었다. 버그나 로직의 구멍이 있다기 보단, 초기 개발때 로직이 불완전한 상황에서 만들어진 데이터들로 인해 생긴듯 하여 커맨드를 작성해서 지워줬다. ...
Today I Learned 날짜 2024년 6월 5일 수요일 내용 실서버 배포 드디어 브라우즈부스터가 출시됐다! 그리고 처음으로 나 혼자 실서버를 배포했다. 슨배임의 기가 막힌 문서작성능력으로 아무 탈없이 배포를 완료했다. 혹시나 뭔일 날까 싶어 벌벌 떨긴했는데 큰 이상은 없었다. 미리미리 실서버 배포할 때 돌려야할 커맨드, 추가해야할 크론, 마이그레이션 내용을 작성해놓은 덕분인 듯. 임베디드 앱 다음 앱은 기존과 달리 쇼피파이 어드민 페이지 내에서 임베디드 형태로 출시하기로 했다. 서버는 그대로 유지하지만, 기존과는 전혀 엮이지 않도록 처리하려고 한다. 브라우저 부스터도 병렬적으로 별개의 앱이긴 했으나 결국 최상위단에서 계정을 기준으로 묶였으므로 아예 별개라고 하긴 어려웠으나, 이번 앱은 전혀 겹치는 부분이 없도록 만들려고 한다. 나중에 사용자가 늘어서 트래픽을 많이 소모한다면 서버를 분리하는 작업을 해야겠지만.. 그랬으면 좋겠다. ...
Today I Learned 날짜 2024년 6월 4일 화요일 내용 쇼피파이 임베디드 앱 임베디드 앱이라 하면, 쇼피파이 어드민 내에서 작동하는 앱을 의미한다. 기존 우리 앱을 실행할 경우 우리가 별도로 구현한 서비스 페이지로 이동한다. 임베디드 앱은 아이프레임을 이용해 쇼피아이 어드민 내에서 내부의 창을 통해 접속한다. 쇼피파이 어드민에서 접근하기 때문에 별도로 계정을 처리해야 할 스트레스가 없다는 것이 장점이다. 이 장점은 나에겐 별도의 스트레스가 되었다. 우리 서비스는 2개의 서버로 구성된 MSA 방식이라 샵과 리뷰를 기준으로 구분되어 있다. 이번 스프린트에서 만들 기능은 별도의 앱이긴 하나 매우 작은 기능이라 데이터가 거의 없다. 테이블도 하나면 충분하고, 거기서도 shopify에서 주는 access_token 만 저장하면 된다. Redis에 데이터를 저장하지 않기 떄문에, 분리할 경우 불필요한 리뷰서버와 샵서버 간 통신이 많아 질거라고 생각해 이 서비스는 리뷰서버에서만 처리되도록 구현할 계획이다. ...
Today I Learned 날짜 2024년 6월 3일 월요일 내용 인스타그램은 인생의 낭비가 아니다. 다음 스프린트로 인스타그램에서 댓글들을 가져오는 기능을 추가하게 되었다. API를 이용하면 크게 어려울 것 없다고 생각했는데 이것저것 코드를 끄적이다보니 생각대로 잘 안되는 부분이 있다. 결국 서버는 유저의 access token으로 각 요청을 다뤄야 한다. 이 토큰이야 로그인을 통해 인스타그램 내에서 우리 앱을 허용하면 우리가 받게 될 거라고 생각한다. 테스터 계정을 등록해서, 임의의 액세스 토큰을 가지고 여러 요청들을 처리해 볼 수 있는데, 원하는 데이터가 안가져와진다! 이번 스프린트 상당히 쉽지않아 보인다. ...