same-origin 엔진 경계

"경계는 모든 게 그걸 지날 때만 지켜줘. 엔진 우회하는 편한 지름길 하나면 그 보초는 장식이야."

origin 하나, 문 하나

Pippa Go 는 빌드된 클라이언트랑 API 를 하나의 origin 위 단일 엔진에서 서빙해. 폰이 엔진에서 앱을 로드하고 모든 요청을 그 같은 엔진으로 되보내고, 엔진이 canonical Pippa 백엔드랑 얘기해. 그 간접이 의례가 아냐 — 엔진이 진짜 일이 일어나는 데야: remote/PIN 가딩, staged-image 검증, 성공 전용 요청 캐시, 재시도 경계. 모든 요청이 문 하나를 지나는 게 그 보호들을 의미 있게 만들어. 아무도 안 써도 되는 문의 보초는 그냥 장식이야.

왜 브라우저 직행 호출이 그걸 깨나

솔깃한 지름길은 브라우저가 canonical upstream 을 직접 부르게 하는 거야 — 홉이 적고, 빨라 보여. 근데 브라우저 직행 호출은 엔진을 우회하고, 그러면서 엔진이 강제하던 모든 보장도 우회해:

가딩 건너뜀: remote/PIN 확인이 엔진에 살아. 돌아가면 요청이 그거 없이 upstream 에 닿아.
검증 건너뜀: staged-image 검증이 엔진에서 일어나. 우회하면 검증 안 된 payload 가 다녀.
경계 건너뜀: 재시도랑 캐싱 규칙이 엔진에서 강제돼. 직행 호출은 아무 규칙도 안 따라.

그래서 규칙이 그렇게 무뚝뚝하게 적혀 있어: 엔진 경계를 우회하는 브라우저 직행 호출을 추가하지 마. 간접이 아름다워서가 아니라, 구멍 난 경계는 경계가 아니라서야.

저대역 배당금

same-origin 엔진은 현장에서만 드러나는 두 번째 배당금을 줘. 모듈을 조각조각 가져오는 개발 서버에 기대는 대신 빌드된 클라이언트를 엔진에서 서빙하는 게, 진짜 나쁜 링크에서 앱을 쓸 만하게 만들어. 개발 서버의 많은 작은 요청은 느린 연결에서 죽어; 하나의 origin 에서 서빙된 빌드 클라이언트는 도착해서 작동해. 이건 대역폭보다 산이 많은 데서 어렵게 배운 교훈이고, 신호가 얇을 때 개발 서버가 아니라 빌드 클라이언트를 집는 이유야. 개발 편의는 개발 거; 현장은 빌드를 받아.

Code

모든 요청이 문 하나를 지남 — 옆문 없음·text

맞음: origin 하나, 경계 하나, 모든 보호 적용
  폰 --> [ 엔진: PWA + API ]  --> canonical Pippa 백엔드
            ^ remote/PIN 가드
            ^ staged-image 검증
            ^ 재시도 + 캐시 경계

틀림: 엔진을 우회하는 브라우저 직행 지름길
  폰 ------------------------------> canonical Pippa 백엔드
         (가드 없음, 검증 없음, 재시도 경계 없음 — 전부 건너뜀)

// 엔진은 자기를 지나는 것만 보호해.
// 옆문 하나면 위의 모든 보장이 선택 사항이 돼.

Exercise

엔진 경계를 가진 클라이언트의 요청 경로를 그려. 이제 '무해한' 브라우저 직행 upstream 호출을 하나 더해 — 프록시할 가치 없어 보이던 빠른 읽기 정도. 그 호출이 조용히 건너뛰는 모든 보호를 열거해. 그다음 정해: 가드랑 검증이랑 재시도 경계를 건너뛸 만큼 싼 읽기가 있어? 미래 기여자한테 줄 규칙을 한 문장으로 써.

Hint

우회는 항상 '보호가 필요 없는' 요청에서 시작해 — 요구사항이 바뀌어 필요해질 때까지, 또는 누가 항상 필요했던 요청에 그 패턴을 복사할 때까지. 한 문장 규칙은 보통 '모든 upstream 호출은 엔진을 지난다, 예외 없음' 이야. 정확히 예외가 번식하니까.