Today I Learned 날짜 2024년 9월 12일 목요일 내용 이름을 처음부터 잘 짓기 기존 인스타그램 코멘트의 기능을 떼오고, 새로 개발한 기능을 합쳐 새로운 서비스를 만들고 있다. 만들면서 계속 느끼는건, 처음 지을때 이름을 잘짓는 거다. 예를 들어 인스타그램에서 가져온 게시글을 저장하는 테이블은 최초에 InstagramCommentMedia 라고 지었다. 근데 두 서비스를 Instagram Comment와 Instagram Feed라는 이름을 가지긴 했지만, 변수명으로 사용하기엔 부적절하지 않나 생각이 들었다. 결국 인스타그램 코멘트는 인스타그램 비즈니스 계정과 연관된 서비스고, 인스타그램 피드는 인스타그램 일반 계정과 연관된 서비스니까. 서버쪽에선 이 뉘앙스를 풍기는게 유지보수에 유리할거라 생각했다. 그래서 InstagramBusinessAccountMedia라고 지었다. 인스타그램 비즈니스 계정에 속한 미디어라는 의미다. ...
3장 리소스와 표현 REST는 설계 제약 조건 모음이다. 무엇이든 리소스가 될 수 있다 사용자가 어떤 작업을 취하고 싶다면 그것을 리소스로 만들어야 한다. 리소스에는 딱 하나의 제약만 있다. 모든 리소스는 URL을 가져야 한다. 다시말해, 무언가에 URL을 부여하면 그건 리소스가 된다. 리소스의 기본 형태는 비트 스트림이다. 클라이언트는 URL과 리소스의 표현만 볼 뿐이다. 표현은 리소스의 상태를 설명한다 표현 : 클라이언트가 리소스에 GET 요청을 보내면 그 리소스를 유용한 방식으로 나타내는 문서를 제공해야 한다. “기계가” 읽을 수 있는 설명으로 나타낸 것 표현은 양방향으로 전송된다. 클라이언트도 POST 요청에서 리소스의 표현을 보낸다. 새 리소스가 어떻게 보여야 하는지에 대한 클라이언트의 생각이 나타난다. 서버는 그 표현을 추가하거나 변경하거나 일부 무시할 수 있다. 데이터베이스 필드에 항상 created_at 과 updated_at 을 남김 표현의 상태 전송 서버는 리소스의 상태를 나타내는 표현을 보낸다. 클라이언트는 그 리소스가 가졌을면 좋을 상태를 설명하는 표현을 보낸다. 많은 표현이 있는 리소스 하나의 리소스에 여러 표현이 있을 수 있다. 다양한 언어, 파일 형식 등 클라이언트가 원하는 표현을 지정하는 법 HTTP 헤더의 값 각 표현마다 별개의 URL 부여 HTTP의 프로토콜 의미 체계 클라이언트가 리소스에 원하는 행동에 대한 규칙이 있다. 미리 정의된 프로토콜을 따라 메시지를 보낸다. 웹 API에선 이 프로토콜이 HTTP다. GET: 리소스의 표현을 얻음 DELETE: 리소스를 제거 POST: 주어진 표현에 기반을 두고 이 리소스 아래 새 리소스를 생성 PUT: 이 리소스의 현재 상태를 주어진 표현으로 대치(전체) PATCH: 이 리소스의 일부 상태를 주어진 표현으로 변경(일부) HEAD: 이 리소스의 표현과 함께 주어질 헤더를 받음(표현은 X) OPTIONS: 이 리소스가 어떤 HTTP 메서드에 응답하는지 알아냄 LINK: 다른 리소스를 이 리소스에 연결 UNLINK: 다른 리소스와 이 리소스의 연결 관계를 제거 모든 요청은 프로토콜 의미 체계가 동일하지만, 애플리케이션 의미 체계는 다르다. GET 정보를 요청할 뿐이라 안전한 메서드여야 한다. 리소스 상태를 바꿀 것을 예상해서는 안된다. DELETE 삭제하는 메서드 멱등성(idempotence) DELETE 요청은 두 번 이상 보내도 한번 보낸것과 같은 결과가 나와야 한다. 지운걸 또 지우려는 요청을 보내도 처음 지웠을 떄와 동일하기 때문이다. 수학 0을 곱하는 것과 같은 이치 GET도 마찬가지다. 리소스가 변하지 않으므로 PUT도 마찬가지. 같은걸 계속 덮어써도 결과는 동일하므로 POST로 추가하기 새로운 리소스를 생성 PUT 덮어쓰기 PATCH 일부만 수정할 경우 멱등성이 없다. 예를 들어, 특정 값을 1 증가시키는 요청을 보내면 멱등성이 없다. PUT은 리소스 전체상태의 교체기 때문에 이러한 요청이 없다. 특히 PUT은 전체상태를 모르는 상태에서 이렇게 만들기 위해 쓰기도 한다. 반면 PATCH는 현재 상태를 알고 이를 일부 변화시키기 위한 요청 아직 HTTP 명세에 정의되지 않았다. LINK와 UNLINK 리소스 간 하이퍼미디어 링크를 관리 멱등하지만, PATCH와 마찬가지로 명세에 정의되지 않아 안전하지 않음 HEAD GET을 헤더에만 적용하는 느낌이라 안전함 GET 대신 쓰더라도 시간이 줄어들진 않지만, 대역폭 사용량은 줄어든다. OPTIONS 응답 헤더에는 HTTP Allow가 담겨, 해당 리소스가 지원하는 HTTP 메서드를 나열한다. 잘 설계된 API는 이 요청이 없어도 응답에 제공되는 하이퍼미디어 문서로 알게끔 해준다. 오버로드한 POST 사실 온갖 종류의 변화에 다 쓰이는게 POST다. ...
Today I Learned 날짜 2024년 9월 11일 수요일 내용 실서버 배포 여정 진행중인 인스타그램 기능을 실서버에 우선 올리기로 했다. 새 서비스로 사용자가 없는 서비스라 별 문제는 없을 듯 싶다. 데이터베이스 구조가 변경되어 마이그레이션이 필요했기 떄문에 실서버 코드가 반영된 EC2에 접속했다. 근데 터미널 bash창에 커서도 안뜨고 이런 오류가 계속 나타난다. 1 2 3 /usr/bin/sh: warning: shell level (1000) too high, resetting to 1 /usr/bin/sh: warning: shell level (1000) too high, resetting to 1 bash: warning: shell level (1000) too high, resetting to 1 쉘 레벨이 너무 높다는 경고라고 한다. 호출이 지나치가 많다는 의미인데, 쉘이나 스크립트에서 무한재귀에 빠졌을 때 발생하는 오류 메시지라고 한다. ...
Today I Learned 날짜 2024년 9월 10일 화요일 내용 비활성 샵과 삭제한 샵 비활성화된 스토어들을 캐시에서 삭제했었다. 리뷰서버에서 샵 데이터를 Redis 캐시에서 받아 쓰는데, 캐시에 올라가있지 않으면 애초에 처리하지 않을 거라고 생각했기 떄문이다. 그럼에도 불구하고 몇일 간격으로 오류가 발생한다. 처음 몇번은 비활성화 된 샵인데도 캐시에 남아있는 경우가 있었다. 왜인지는 모르곘으나, Redis 관련 요청이 성공률이 높지 않다. 그래서 기존 코드에도 3회 정도 반복하는 코드가 있었구나 싶었다. 별 수 없어서 열심히 처리했는데 또 난다. ...
Today I Learned 날짜 2024년 9월 9일 월요일 내용 샵 URL이 2개인 이유 쇼피파이에서 유저가 앱을 설치하면, 가장 먼저 알게 되는 샵 정보는 샵의 URL이다. 알파플러스에선 샵의 URL을 shop_url과 platform_shop_url 이라는 두 값으로 저장한다. 사실 왜 두 개인지 몰랐다. 뭐 레거시 인가 싶긴 했는데.. 그래서 인스타그램 코멘트를 만들때는 그냥 샵 URL을 하나만 가져왔다. 이게 모든 문제의 원인일 줄이여… 실제로 쇼피파이에서도 샵의 URL 관련 정보는 2가지이다. 하나는 “domain”, 다른 하나는 “myshopify_domain”이다. 전자는 유저가 설정에서 바꿀 수 있다. 스토어 이용 고객이 접속할 때 쓰는 URL이고 변경가능하다는 의미이다. 실제로 변경하는 스토어가 왕왕 있다. 반면 후자는 샵을 생성하면서 고정되는 값으로 변경되지 않는다. 각 스토어가 쇼피파이에서 가지는 고유한 ID가 있듯, 이 URL도 고유한 값이다. 따라서 스토어와 관련된 데이터를 쇼피파이에 요청할 때도 이 URL이 쓰인다. 우리가 테마를 조회하던, 메타필드를 조회하던, 주문 데이터를 조회하던 이 값이 없으면 아무것도 못한다. ...
Today I Learned 날짜 2024년 9월 6일 금요일 내용 나는 메타 혐오 개발자다. 페이스북 로그인한 계정의 페이지에서 연동된 인스타그램 비즈니스 계정을 가지고 오기 위한 사투는 계속되고 있다. 우선 되는 것부터 만들자는 생각에 비즈니스 계정이 아닌 일반 계정의 게시글을 불러오는 작업을 시작했다. Docs에 들어가보니.. 그저께 충격적인 발표가 있었다. 뭔 중대발표를 90일을 남기고 하냐… 내용을 설명하자면 다음과 같다. 페이스북의 API를 이용하기 위해선 페이스북의 앱으로 등록해야 한다. 이때 앱의 유형을 선택할 수 있는데 그 중 인스타그램 일반 계정에 관한 API 사용을 위해선 앱 유형이 “소비자” 여야하고, 인스타그램 비즈니스 계정에 관해선 “비즈니스” 타입이여야 한다. 유형이 소비자인 앱이 사용하는 인스타그램 API 가 인스타그램 기본 디스플레이 API고, 유형이 비즈니스인 앱이 사용하는 API는 인스타그램 그래프 API다. 이 중 인스타그램 기본 디스플레이 API가 90일 이후부터는 사용할 수 없다는 이야기다. ...
Today I Learned 날짜 2024년 9월 5일 목요일 내용 페이스북 권한의 종류 대참사났다.. 페이스북 로그인 후 댓글까지 가져오는 로직에서 도저히 연관된 비즈니스 계정이 가져와지지 않고 있었다. 로그인 후 부터 발생하는 로직은 다음과 같다. 유저가 페이스북 로그인 서버는 페이스북 계정이 가진 페이스북 페이지를 모두 불러와 저장 이때, 페이스북 페이지와 연동된 인스타그램 비즈니스 계정 정보도 저장 유저가 사용할 페이스북 페이지 선택 선택된 페이스북 페이지와 연동된 인스타그램 비즈니스 계정의 미디어 정보를 조회 해당 미디어들의 댓글 정보를 모두 조회 조회한 데이터를 저장 3번에서 어떤 경우에는 불러와지고, 어떤 경우에는 불러와지지 않았다. 심지어 같은 계정 내에서도 어떤 페이지는 불러와지는 반면 어떤 페이지는 분명 비즈니스계정과 연동되어 있음에도 불러와지지 않았다. 왜 그런지 도저히 모르겠어서 열심히 메타 개발자 Docs를 뒤져봤다… ...
1장 웹에서의 원칙 : 일반 사용자들이나, 자동화 소프트웨어 에이전트나 동일하게 작동한다. URL : 데이터 접근 경로 ⇒ 각 URL은 하나의 리소스를 식별한다. 브라우저가 리소스에 HTTP 요청을 보내면 서버는 응답으로 리소스의 표현(representation)을 반환한다. 주소 지정 가능성(addressability) 하나의 URL은 단 하나의 리소스만 식별한다. 플래시 인터페이스가 이를 어긴 대표적인 예시 이 원칙은 모든 리소스는 각각 자신의 URL을 가져야 한다는 말 짧은 세션 HTTP 세션은 하나의 요청 동안 유지된다. 요청이 발생하지 않으면 서버는 클라이언트의 존재를 모른다 ⇒ 무상태(statelessness) 자기 서술형 메시지 요청에서 받은 리소스의 표현에는 보통 다음에 해야할 것도 포함되어 있다. ...
Today I Learned 날짜 2024년 9월 4일 수요일 내용 기존 서비스 분리 알파플러스에 기생(?)시켜놨던 인스타그램 코멘트 기능을 분리했다. 사실 애초에 만들때도 같은 서버에 있을 뿐 서로 연관은 전혀 없도록 해놨기 떄문에 그냥 복붙하면 될줄 알았는데… 바로 다음 스프린트인 네이버 플랫폼 추가를 고려하느라 데이터베이스를 열심히 수정해놨더니 제대로 되는게 하나도 없다… 데이터베이스의 구조가 바뀐다는 로직도 변경되야 할 수 있음을 간과했다. 예를 들어, 현재는 페이스북 계정을 로그아웃 할 경우 기존에 게시해둔 댓글 위젯을 삭제하지 않는다. 다른 계정으로 로그인 했을 떄 연결이 남아있는 것이 있다면 삭제해주는 로직을 취하는데, 이번에는 그럴수가 없게 됐다. 페이스북 로그인, 인스타그램 로그인이 따로 존재하면서 둘 간의 서열이 존재해야 하기 때문이다. ...
Today I Learned 날짜 2024년 9월 3일 화요일 내용 서비스 초기 진입 구상 인스타그램 서비스의 초기 진입 부분을 구현하고 있다. 크게 어렵다거나 골치아픈 부분은 없는데 이것저것 따지고 세세하게 신경써야 할 부분이 많다… 유저의 인스타그램 계정이 비즈니스냐 아니냐에 따라 전혀 연관되지 않은 테이블로 나뉘어진다. 애초에 인스타그램 피드와 인스타그램 코멘트는 그렇게 구현된 서비스다 보니까… 인스타그램 기본 계정을 사용하다, 그 계정을 비즈니스 계정으로 바꾸었을 때 데이터를 어떻게 유지시켜 줄 것인가? 비즈니스 계정인지, 일반 계정인지 API 만으로 판단할 수 있는가? 계정이 다수가 되었을 때의 확장성은 어떻게 처리할 것인가? 로그아웃시에 데이터는 어떻게 처리하며 재 로그인시 데이터를 어떻게 찾아 연결해줄 것인가? 등등…. 이런 개발이 가장 어렵다. 온갖 경우의 수를 다 생각해봐야 하는 스프린트.. ...