GraphQL

탄생 배경

• REST API보다 고성능 쿼리 언어
• REST API : 3개의 엔드 포인트
• GraphQL : 단일 엔드포인트 구조
• rest api의 문제점
  • under fetching
  • over fetching
  • 기존 API 필요한 데이터 필드 추가 + 새로운 엔드포인트 추가
• GraphQL
  • under fetching, over fetching 해결
  • 네트워크 대역폭 절약
  • client에서 데이터의 효율적인 처리
  • SQL의 select문과 비슷
  • 기존 API 필요한 데이터 필드 추가 + 새로운 엔드포인트 추가 → 쿼리만 변경

구성 요소

• 스키마
  • 데이터 구조와 API 형태 정의
  • Query : 조회
  • mutation : 변경
  • subscription : 알림
• 미들웨어
  • 트래픽 대부분이 가장 먼저 도착하는 곳
  • 사용자 인증 권한 검사
  • 보안에 대한 검사
• resolver

동작 과정

• 클라이언트 요청
• middleware
• 쿼리 파싱
  • query 문자열 파싱 → AST
• 유효성 검사
• 실행
  • resolver 함수 호출
• 요청 처리
• 데이터 반환
• 클라이언트 응답

CRUD, 반복적인 요청, 요청의 구조가 정해져있을 때

단점

• 클라이언트에 많은 권한을 부여(FE에서 복잡해짐) → 앱에서는 특히 클라이언트에 많은 권한 부여 ❌
• 스키마에 오류가 존재 → 구글 스토어 심사 어려움(엄격한 스키마)
• 일부를 가져오기 < 다 가져와서 안 쓰는 게 나음
  • REST API 설정이 더 간단함

<추가>

• HTTP 캐싱 활용 어려움
• 에러 핸들링 어려움
• 마이크로서비스에서의 복잡성이 증가됨
• 파일 업로드가 안된다.

client와의 연관성 더 찾아보기

graphql의 client 라이브러리가 아폴로 서버(entry)

postgre sql이랑 잘 쓰임

IAM

• 최소 권한 원칙

구성 요소

• user
  • 상호 작용하는 사람을 나타내는 엔티티
• group
  • 여러 명에게 동일한 권한을 한 번에 부여하기 위해 사용
• role
  • 특정 권한이 있는 계정에서 만들 수 있는 IAM ID
  • AWS 계정, AWS 리소스에 부여 ⭕
• policy
  • 권한들의 집합
  • 인라인 정책 : 해당 유저에 한해서만 적용되는 정책

그룹 정책과 사용자 정책은 동시 적용?

• 둘 다 허용되어야 최종적으로 허용
• 거부는 허용보다 우선 적용

리소스 기반 정책 vs IAM ROLE 차이?

• 리소스 기반 : 리소스에 접근 주체가 자기의 권한 그대로 유지한 채로 리소스의 정책을 따라 허용 권한을 얻게 되는 상황
• IAM ROLE : 원래 권한은 일단 포기
  • 이전 권한은 일시적으로 ❌
• EC2가 주기적으로 S3에 접근해야 한다면 IAM Role 사용 권장 → 액세스 키, 비밀 키 유출 ❌
• 인라인 정책은 user 소멸 시 같이 소멸됨

IAM Access Analyzer

• 실사용된 권한 추적해서 보여줌 → 실제 접근할 권한 확인