StudyDad

기술 실무 설계 시리즈 5/8API Gateway는 종종 Lambda 앞에 붙이는 프록시처럼 여겨진다.요청을 받아 Lambda로 넘겨주는 역할 말이다.하지만 브라우저 기반 운영 콘솔에서는 API Gateway를 단순 프록시로 보면 부족하다.CORS, 라우팅, 스로틀링, 로그, 인증 확장성, 백엔드 교체 가능성까지 포함한 운영 경계로 보는 편이 더 맞다.API 앞단에는 정책이 필요하다프론트엔드가 API를 호출할 때 단순히 백엔드 함수만 있으면 되는 것이 아니다.운영 중에는 다음 정책이 필요하다.어떤 path를 허용할 것인가어떤 method를 허용할 것인가어떤 origin에서 호출할 수 있는가preflight는 어디서 처리할 것인가요청이 너무 많으면 어떻게 제한할 것인가어떤 로그를 남길 것인가나중에 백엔드를..

AWS 실전 운영 시리즈 5/12브라우저에서 API를 호출할 때 CORS 오류를 만나면 당황스럽다.서버는 멀쩡한 것 같은데 브라우저가 요청을 막는다. Postman에서는 되는데 화면에서는 안 된다.운영 콘솔처럼 React SPA와 API 도메인이 분리된 구조에서는 CORS가 설계 요소다.특히 JSON 요청이 많다면 preflight OPTIONS 요청을 어떻게 처리할지 정해야 한다.CORS preflight란 무엇인가브라우저는 다른 origin으로 특정 요청을 보내기 전에 OPTIONS 요청을 먼저 보낼 수 있다.이 요청을 preflight라고 한다.예를 들어 다음 조건에서는 preflight가 발생한다.Content-Type: application/jsonAuthorization 헤더 사용PUT, DE..

AWS 실전 운영 시리즈 4/12AWS API Gateway에는 크게 REST API와 HTTP API가 있다.HTTP API는 더 가볍고 저렴하고 빠르다. 그래서 새로 만들 때는 HTTP API가 먼저 떠오를 수 있다.하지만 항상 HTTP API가 정답은 아니다.운영 콘솔처럼 브라우저 기반 SPA, 여러 endpoint, CORS preflight, API Key, 요청 검증, MOCK 응답 같은 요소가 중요하다면 REST API가 더 나을 수 있다.문제 상황운영 콘솔의 프론트엔드는 별도 도메인에서 동작했다.API는 Lambda를 통해 제공되었고, 여러 path와 method가 있었다.필요한 것은 단순히 Lambda를 HTTP로 호출하는 것만이 아니었다.path별 라우팅CORS preflight 처리O..

데이터와 리포트 설계 시리즈 2/8처음 리포트 다운로드 기능을 만들 때 가장 쉬운 방식은 동기 API다.사용자가 버튼을 누르면 API가 데이터를 조회하고, 엑셀을 만들고, 바로 파일을 응답한다.작은 데이터라면 이 방식도 괜찮다.하지만 데이터 범위가 넓어지고 생성 시간이 길어지면 동기 API 방식은 여러 문제를 만든다.가장 단순한 구조동기 방식은 이렇게 생겼다.사용자 클릭-> POST /api/reports-> DB 조회-> 엑셀 생성-> 파일 응답구현은 단순하다.프론트엔드도 요청 하나만 보내면 된다.서버도 파일을 만들어 바로 응답하면 된다.하지만 이 구조는 "작업이 짧게 끝난다"는 전제를 가진다.그 전제가 깨지면 문제가 시작된다.브라우저 대기 UX동기 API는 사용자가 요청이 끝날 때까지 기다려야 한다...