Serverless With AWS
#
2021-07-06#
List- DynamoDB
- Notes App
- Create
#
DynamoDBAmazon DynamoDB는 어떤 규모에서도 10밀리초 미만의 성능을 제공하는 키-값 및 문서 데이터베이스입니다.
완전관리형의 내구성이 뛰어난 다중 리전, 다중 활성 데이터베이스로서, 인터넷 규모 애플리케이션을 위한 보안, 백업 및 복원, 인 메모리 캐싱 기능을 기본적으로 제공합니다. DynamoDB는 하루에 10조 개 이상의 요청을 처리할 수 있고, 초당 2,000만 개 이상의 피크 요청을 지원할 수 있습니다.
Lyft, Airbnb, Redfin 등과 같이 세계에서 가장 빠르게 성장하는 다수의 비즈니스뿐만 아니라 삼성, Toyota, Capital One과 같은 엔터프라이즈에서도 자사의 미션 크리티컬 워크로드를 지원하기 위해 DynamoDB의 규모와 성능을 활용하고 있습니다.
#
Setting DynamoDB- 각 DynamoDB 테이블에는 기본 키가 있으며 한 번 설정하면 변경할 수 없음
- 기본 키는 테이블의 각 항목을 고유하게 식별하므로 두 항목이 동일한 키를 가질 수 없음
DynamoDB는 두 가지 종류의 기본 키를 지원
- 파티션 키
- 파티션 키 및 정렬 키 (복합)
데이터를 쿼리 할 때 추가적인 유연성을 제공하는 복합 기본 키를 사용해본다.
예를 들어 사용자 아이디에 대한 값만 제공하면 userId 해당하는 사용자의 모든 메모를 검색할 수 있다. 또는 userId와 특정 noteId를 제공하여 특정 메모를 검색 할 수 있다.
#
Create Table#
Set Key#
Set Capacity#
Notes App#
ArchitectureHello World
Notes App
#
create notes function#
Configure API Endpoint#
Refactor CodeRefactor Create.js
#
Test#
폴더 구조#
2021-07-13#
List- Get API
- List API
- Update API
- Delete API
- Serverless Deploy
#
get.js#
Test#
list.js#
Test#
update.js#
Test#
delete.js#
Test#
serverless deploy#
폴더 구조#
참고#
2021-07-20#
List- Auth in Serverless APIs
- Cognito User Pool
#
Authenticated API Architecture- Sign Up
- Login
- Authenticated API Requests
#
Connect API- React 클라이언트는 IAM Auth를 사용하여 보안이 설정된 API Gateway에 요청
- API Gateway는 사용자가 사용자 풀로 인증되었는지 여부를 자격 증명 풀로 확인
- 인증 역할을 사용하여 이 사용자가 이 API에 액세스할 수 있는지 확인
- 모든것이 통과되면 Lambda 함수가 호출되고 자격 증명 풀 사용자 ID를 전달
#
Cognito#
Review Defaults 이메일로 인증 설정#
Set Default And Create Pool#
App Clients Create#
App Client Id#
Create Domain Name#
Fill Identity-pool-info#
Fill Authentication-provider-info#
Select edit-policy-document#
Select email-address-as-usernameCreate
SignUp
#
참고#
2021-07-27#
List- IAM Auth Set
- Handle CORS in Serverless APIs
- Handle API Gateway CORS Errors
#
IAM Auth Set인증없이 사용이 가능했던 API설정에 대해 cognito 인증이 완료된 유저만 호출할 수 있도록 변경
#
CognitoIdentityIdcreate, get, update, delete, list.js 에서 ID 인자 수정
#
Handle CORS in Serverless APIs#
CORS란?Cross-Origin Resource Sharing(CORS)은 추가적인 HTTP header를 사용해서 애플리케이션이 다른 origin의 리소스에 접근할 수 있도록 하는 메커니즘
다른 origin에서 내 리소스에 함부로 접근하지 못하게 하기 위해 사용되는 기법.
(브라우저가 리소스를 요청할 때 추가적인 헤더에 정보를 담는곳에 CORS관련 내용이 존재한다.)
#
요청 헤더- Origin
- Access-Control-Request-Method
- preflight요청을 할 때 실제 요청에서 어떤 메서드를 사용할 것인지 서버에게 알리기 위해 사용됩니다.
- Access-Control-Request-Headers
- preflight 요청을 할 때 실제 요청에서 어떤 header를 사용할 것인지 서버에게 알리기 위해 사용됩니다.
#
응답 헤더- Access-Control-Allow-Origin
- 브라우저가 해당 origin이 자원에 접근할 수 있도록 허용합니다. 혹은 *은 credentials이 없는 요청에 한해서 모든 origin에서 접근이 가능하도록 허용합니다.
- Access-Control-Expose-Headers
- 브라우저가 액세스할 수있는 서버 화이트리스트 헤더를 허용합니다.
- Access-Control-Max-Age
- 얼마나 오랫동안 preflight요청이 캐싱 될 수 있는지를 나타낸다.
- Access-Control-Allow-Credentials
- Credentials가 true 일 때 요청에 대한 응답이 노출될 수 있는지를 나타냅니다.
- preflight요청에 대한 응답의 일부로 사용되는 경우 실제 자격 증명을 사용하여 실제 요청을 수행 할 수 있는지를 나타냅니다.
- 간단한 GET 요청은 preflight되지 않으므로 자격 증명이 있는 리소스를 요청하면 헤더가 리소스와 함께 반환되지 않으면 브라우저에서 응답을 무시하고 웹 콘텐츠로 반환하지 않습니다.
- Access-Control-Allow-Methods
- preflight`요청에 대한 대한 응답으로 허용되는 메서드들을 나타냅니다.
- ccess-Control-Allow-Headers
- preflight요청에 대한 대한 응답으로 실제 요청 시 사용할 수 있는 HTTP 헤더를 나타냅니다.
Serverless API에서 CORS를 지원하려면 두 가지 작업을 수행해야
- 실행 전 OPTIONS 요청
특정 유형의 교차 도메인 요청(PUT, DELETE, 인증 헤더가 있는 요청 등)의 경우 브라우저는 먼저 요청 방법 OPTIONS를 사용하여 실행 전 요청을 만든다.
이러한 API는 이 API에 액세스할 수 있는 도메인과 허용되는 HTTP 메서드로 응답해야 한다.
- CORS 헤더로 응답
- 다른 모든 유형의 요청에 대해 적절한 CORS 헤더를 포함해야 한다.
- 위의 헤더와 마찬가지로 이러한 헤더에는 허용되는 도메인이 포함되어야 한다.
CORS에 더 자세한 내용은 -> Wikipedia 기사
위의 항목을 설정하지 않으면 HTTP 응답에 이와 같은 내용이 표시됨.
serverless.yml에 내용 수정
#
Lambda Function CORS Headerlibs/handler-lib.js reutrn 문 아래처럼 변경
변경 후 list.js로 테스트
!응답에 headers 정보가 같이 담겨있어야 한다.