Today I Learned

날짜

2024년 5월 9일 목요일

내용

샵 디테일 수정

새로운 브라우즈 부스터 앱에서 사용할 샵 테이블을 별도로 생성했었다. 이 앱에 앞으로 다양한 서비스가 추가될 테지만, 우선은 필요한 최소한으로 구현하는게 좋다고 클린 아키텍처에서 배웠다. 알파플러스 앱에선 쇼피파이에서 보내주는 데이터는 샵 테이블에, 우리 서비스에서 사용하기 위해 필요한 정보들을 담는데는 샵 디테일 테이블을 사용한다. 우선 브라우저 부스터 앱은 샵 디태일을 별도로 만들지지 않았다. 배운대로 했다는 뿌듯함을 느꼈다.

브라우저 부스터 앱을 설치해도, 알파플러스와 동일한 온보딩 및 회원가입 과정을 겪어야 해서 샵 데이테일 테이블이 필요하다는 것을 꺠달았다. 바로 샵 디테일을 만들었다. 난 생각의 범위가 참 좁다.

앱설치 딥링크

두 앱이 하나의 어드민 페이지를 사용한다. 아직 설치하지 않은 앱 메뉴로 접근하려고 하면, 설치하는 페이지로 리다이렉트 시켜주려한다.근데 그 링크를 도저히 모르겠다.

https://{Store의 Admin 페이지의 URL}/oauth/request_grant?access_change_uuid={앱의 접근 권한 확인을 위한 &client_id={앱의 client_id}

로 이루어져 있는데.. 저 uuid를 어떻게 받아올 수 있을지 모르겠다. 가장 중요한 태스크는 아니니 우선 쇼피파이 앱 스토어로 처리해 두고, 나중에 처리해야겠다.

역참조 이름 변경

알파 플러스와 브라우저 부스터 앱 모두 같은 온보딩 및 로그인 페이지를 공유하다 보니 얽히는 문제가 많다. 알파 플러스는 shop.shop_detail로 처리할 떄, 브라우저 부스터는 shop.browse_booster_shop_detail로 처리해야 하고.. 이미 각각의 함수 내에서 별개로 처리하기 위한 분기가 많아 무작정 if문만 무지성으로 추가하고 싶지 않았다.

우선은

1
2
3
4
5
6
7
8
9
10
11
class BrowseBoosterShop(Base):
    __tablename__ = "browse_booster_shop"
    
    ...
    
    shop_detail = relationship(
    "BrowseBoosterShopDetail",
    back_populates="browse_booster_shop",
    uselist=False,
    cascade="all,delete",
		)

이렇게 짰다. 브라우저 부스터앱에서 사용하는 shop_detail의 테이블 이름은 browse_booster_shop_detail로 설정했지만, shop과 join하여 가져올 떄는 shop.shop_detail로 역참조 할 수 있도록 처리했다. 헷갈릴려나…

회고

두 앱을 한 서버 내에 두는 것, 두 앱이 공통의 시작 처리 지점을 가지는게 맞는 건지 모르겠다…