글 쓰게된 계기
velog에 글을 쓰고 있던 중 갑자기 궁금해진 한가지!! 포스트가 임시저장되었습니다 며 toast가 뜨는데, '어떤 기술을 쓰는거지?;' 싶었다. SSE를 쓰기에는 Server 쪽에 부담이 클 것 같다는 생각이 들었기 때문에 F12를 누르고 당장 확인해보았다.
F12를 누른 결과 (!!!)
포스트가 임시저장되었습니다는 메시지가 뜰 때마다 이 두가지 Request 가 반복적으로 발생하는 것을 발견할 수 있었다. 자세하게 확인해보니..
1. OPTIONS 요청
첫번째 request는 위와 같았다. OPTIONS라.. 응답값도 없는데 왜 발생하는걸까??
OPTIONS 요청이 발생하는 이유
OPTIONS 요청은 preflight라고도 불라며, 브라우저가 서버에게 지원하는 옵션들을 미리 요청하고 허가된 요청에 한해서 전송하기 위해 발생한다. 다만 모든 경우에 발생하는 것은 아니고, CORS 상황에서 주로 발생한다.
1. 왜 CORS 상황에서 주로 발생하는가?
CORS를 간단히 설명하면 현재 웹페이지가 웹페이지를 받은 서버와 다른 서버의 릿고스를 요청하는 것을 의미한다. 다른 API 서버로 요청을 하는 것을 예시로 들 수 있다. 이는 유용하지만 악의적으로 외부로 정보를 보낼 수 있는 치명적인 단점이 있다. 그래서 OPTIONS를 사용해 서버에서 허용하는 옵션인지 미리 확인을 하는 것이다.
2. OPTIONS 요청이 발생하지 않는 조건
- GET, POST, HEAD 요청일 경우
- user agent에 의해 자동으로 설정되는 헤더외에 CORS-safelisted request-header로 명시된 헤더들만 포함된 경우
: Accept, Accept-Language, Content-Language, Content-Type - 가능한 Content-Type
: application/x-www-form-urlencoded, multipart/form-data, text/plain
2. POST 요청 (with GraphQL)
REQUEST가 있어야 RESPONSE가 있다, 이는 REST API가 동작하는 방식이다. 따라서 클라이언트에서는 아무것도 하지 않았는데 알아서 요청을 한다는 건 말이 안된다. 음 그러면 VELOG에서는 어떤 매직을 부렸길래 알아서 임시저장 API를 호출했는가!!?? 하면 Request URL에 주목했다.
graphql??, 얼핏 듣기만 했던 기술이었는데, 여기에 핵심이 있었다!
GraphQL 이란?
GraphQL은 API를 위한 쿼리 언어로서, 클라이언트가 데이터를 서버로부터 효율적으로 가져오는 것이 주목적이다. 예시는 아래와 같다.
// query : 요청할 때 사용
query {
person {
name
age
gender
school {
middle
university
}
}
}
// 응답받는 형식
{
"data": {
"person": {
"name": "eunivverse",
"age": 100,
"gender": "women",
"school": {
"middle": "js",
"university": "inha"
}
}
}
}- 장점
- 오버페칭과 언더페칭 해결
GraphQL은 클라이언트에서 필요한 필드를 정의하여 API 요청을 하므로 Rest API에서 발생하는 오버페칭과 언더페칭을 개선한다. - 간결한 클라이언트 로직
GraphQL은 필요한 필드만 정의하여 응답받기 때문에 데이터를 그대로 사용할 수 있다. 그러나 백엔드 쪽에서는 요청 쿼리 핸들링을 위한 추가 로직이 필요해질 수 있다.
- 단점
- 복잡한 캐싱
GraphQL은 단일 엔드포인트를 사용하므로 HTTP 캐싱의 이점을 누리기 어렵다. - 까다로운 파일업로드
GraphQL은 application/json 형식만 받을 수 있으므로, multipart/form-data 를 json 으로 바꿔 전달해주는 미들웨어나 패키지를 사용해야한다.
GraphQL vs REST
GraphQL 관련 내용을 읽다보면 비교할 수 있는 대상이 REST이다. 둘다 프론트엔드와 백엔드 간의 소통 창구와 관련되어 있어서 그런 거 같다. 그렇다면 GraphQL 과 REST는 어떻게 다를까?
바야흐로 2012년, 고정적인 구조의 데이터 형식과 오버페칭 및 언더페칭의 REST 한계를 극복하고자 GraphQL 이 부상하기 시작했다. 그럼 어떤 점이 다른 것일까?
REST와 비교했을 때 GraphQL이 가지는 차이는 다음과 같다.
-
하나의 엔드포인트를 가진다.REST API GraphQL 사용자 전체조회 example.com/api/user example.com/graphql 사용자 A 조회 example.com/api/user/{idx} 위의 예시를 봤을 때, REST API는 사용자 전체조회와 A 조회의 엔드포인트가 다르지만, GraphQL은 동일하다.
-
요청할 때 사용하는 쿼리에 따라 다른 응답을 받을 수 있다.사용자 A의 이름, 나이, 학교만 보여주는 클라이언트가 있다면?
- REST API
request https://example.com/api/user/A response { "name": "A", "age" : 20, "school": "inha", "gender": "women", "birth": "1992-03-21", "height": "170", ... } - GraphQL
request query { person(id: 'A') { name, age, school } } response { "data": { "person": { "name": "A", "age": 20, "school": "inha" } } }
- REST API
-
위의 예시처럼 GraphQL은
원하는 데이터만 받을 수 있다.
Velog는 GraphQL을 어떻게 썼을까?? (나의 예측일뿐..)
이건 사실 나의 예측(?)이라서 틀릴 수도 있다. 그러나 방법 구현에 가장 가까운 건 GraphQL의 Subscription이 아닐까 싶다. GraphQL에는 실시간 애플리케이션을 구현하기 위한 Subsription이 있다. 이는 발행/구독 모델을 따르고 Websocket을 기반으로 실시간 양방향 통신 기능을 제공한다. 아무래도 클라이언트에서 변경이 일어날 것이고, 서버 쪽에서는 실시간으로 임시저장을 하는 것이 아닌가하는 생각이다!
마지막 딴소리
+) 유튜브를 보다가 velog 개발자 분의 유튜브에서 임시저장 기능 구현 유튜브 영상을 발견했다!! 나중에 한번 확인해 보려고 기록.. (https://www.youtube.com/watch?v=dtScc6oZFVo)
친구들과 하는 프로젝트에서 GraphQL을 다뤄보게 되었는데, 좀 신난다ㅎ 이렇게 기술을 알아가는건 재미있는 거 같다 ㅎㅎㅎ
SSE 관련 내용은 나중에 자세하게 다뤄봐야겠당!!! 알고 있고 구현해본 개념이지만 블로그에 한번도 써본적이 없기 때문에...
