GraphQL은 페이스북에서 만든 데이터 질의어이며, 'gql'이라고 한다. gql은 서버에 작성된 쿼리를 통해 데이터를 조회하는 방식이 아니라, 클라이언트에서 쿼리를 작성하여 필요한 데이터만 조회하는 방식을 제공한다. 또한, 하나의 EndPoint를 가지기 때문에 개발 규모에 따라 EndPoint의 복잡도가 증가하는 REST API보다 개발이 간편하다. 여러 데이터 집합에서 데이터를 조회하는 경우 gql은 하나의 쿼리로 조회가 가능하지만, REST API는 Request를 여러번 시도해야 한다. REST API도 한번의 Request로 처리가 가능하지만, 매번 여러개의 데이터 집합을 조회하기 때문에 자원의 낭비를 초래한다.
GraphQL은 데이터의 구조를 정의하는 스키마(Schema)와 데이터 조회를 위한 쿼리(Query), 데이터 위한 뮤테이션(Mutation), 조회 결과에 대한 구현을 위한 리졸버(Resolver)로 구성되며, 이 외에 API명세서의 기능을 하는 인스로펙션(Instropection)으로 구성된다.
혼자서 공부하며 내린 정의 :
기존 rest api에서 발생하는 문제는 크게 2가지 였습니다.
overfetch와 underfetch
그 중 overfetch는
user의 정보를 요청하는 api를 보냈을 때, 내가 필요한 정보보다 훨씬 많은 정보들이 넘어오는 것이었습니다.
보통 프론트에서는 현재 user의 name만 필요로 하겠지만, 보통 rest api에서 고객 정보를 요청하면 해당 고객의 모든 정보를 보내주도록 구현되어 있어서, 더 많은 리소스 낭비로 이어졌습니다.
그리고 underfetch의 경우,
만약 고객의 장바구니 정보, 혹시 좋아요한 물품 정보를 모두 함께 보고 싶다고 했을 경우,
user/cart/ 뿐만 아니라 user/wish/ 등 여러가지 api를 요청해야 하는 이슈가 있습니다. 무엇보다 중요한 것은 이게 점점 서비스의 규모가 커져감에 따라서 관리해야 하는 endpoint들이 기하급수적으로 늘어날 수 있다는 것입니다. 이는 개발자나 클라이언트에게 부담이 될 수 있습니다.
GRAPHQL은 위에서 설명한 것처럼 REST API의 한계를 극복하기 위해 나왔습니다.
endpoint는 통상 1개만 생성하고, 클라이언트에서 필요한 데이터는 클라이언트에서 직접 쿼리를 작성하여 호출 반환하도록 합니다.
도메인 네임서버는 IANA(IANA(Internet Assigned Numbers Authority)는 인터넷 할당 번호 관리기관의 약자로 IP 주소, 최상위 도메인 등을 관리하는 단체이다. 현재 ICANN이 관리하고 있다. 처음에는 서던캘리포니아 대학교정보 과학 학회의 존 퍼스텔이 서던캘리포니아 대학교 정보 과학 학회와 미국 국방부 간에 맺어진 계약 아래 관리했으며, 퍼스텔은 미국 상무부 계약으로 ICANN이 설립 될 때까지 이 업무를 수행했다.)
라는 곳에서 실제 도메인 주소를 가지고 오나
이러한 요청을 계속 주게 되면 네트워크상에 부하가 가중되기 때문에,
한 번 가져온 주소는 DNS server에 저장하고
호스트의 요청시 그 안에 정보를 가지고 온 후 반환해준다.
test
궁금증 :
그럼 해당 Address로도 접근이 가능해야 하는데 왜 접근이 불가능할까?
=> 원래는 접근 가능해야 하나, 요즘은 보안상의 이슈로 직접 IP접속을 차단한 경우가 많아,
일단 CRUD를 알아야 할텐데 Create, Read, Update, Delete의 줄인 말이다. 사실 우리가 통신할 때 하는 행동은 대부분 위의 4가지 이다. 이거는 조금만 고민해 보면 아는데, 게시판에 글을 적는다는 것은 Create하는 행위 일 것이고, 다른 게시판으로 이동하는 것은 Read하는 행위, 게시글을 수정하는 것은 Update, 게시글을 지우는 것은 Delete이다.
그럼 이 CRUD한 요청을 보내기 위한 "약속"이라고 볼 수 있는데 REST API에는 3가지의 구성 요소가 있다.
URI : product/32(id) => 서버는 요청에 대한 고유 id의 값을 가지고 있고, 해당 id로 요청을 보낸다는 것 1가지
METHOD : GET/POST/PUT/DELETE => 여기 드디어 나왔다. GET과 POST!
Representation of Resource : Json, XML, TEXT => Json은 여기에 숨어 있었다. JSON!
API의 효율적 통신을 위해 다시 한번 약속을 한 것이 REST API라고 했다. 이제 하나씩 보자.
여기 제일 위에 code= 와 같이 조회할 영화 정보를 넣는다는 것이 REST API 약속 중 한 가지이다.
그럼 2번 째 드디어 나온.. 우리가 너무 자주쓰고 있는 GET과 POST가 나왔다.
"정보를 요청할 때는 GET 요청을 보내고, 정보를 입력할 때는 POST로 요청을 보낸다." 이렇게 약속을 해놓은 것이다. 이렇게 되면 서버에서는 프론트에서 GET 요청이 올 때는 DB에서 데이터를 조회해서 보내주는 로직으로 구성하면 되고, POST 요청이 오면 작성에 대한 로직을 구성하면 되기 때문에 굉장히 효율이 높아지게 된다.
이렇듯 REST API는 API 통신이 원활하기 위해 또 한번 약속을 해놓은 것이라고 볼 수 있다.
실제 REST에 대한 백과사전을 찾아보면 REST(REpresentational State Transfer) :
“Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개됨. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표”
와 같은 글을 볼 수 있다.
그럼 이제 마지막 Representation of Resource :Json, XML, TEXT 을 보자.
서버에서 프론트로 값을 줄 때 항상 JSON 형태로 전달을 하고 있어서 그냥 그런가 보다 생각을 했었는데, 이것도 REST API의 일부였다..!!
서버에서 프론트로 결과 값을 줄 때 JSON/XML/TEXT 등의 값으로 반환한다는 것을 정의 해놓은 것인데, 이렇게 되면 프론트엔드 쪽에서도 어떤 형태로 값이 넘어올지 미리 예상할 수 있어 이렇게 맞추어 코딩을 하면 된다.
현재는 JSON 위주로 쓰이고 있어서 우리는 보통 서버에서 프론트로 반환 값을 줄 때 JSON형태로 전달하고 있다. JSON은 key와 value로 이루어진 값의 모임인데 간단하게 형태를 예시로 들어보면 아래와 같다.
와 이제 정말 다 설명했다.
정리를 다시 해보자면 API 사용하기 위해서는 약속이 다시 한번 필요했고! 이 약속을 효율적으로 한 것이 REST API라는 것. RESTFUL하게 구성하였냐는 이 REST의 구성요소 들을 잘 지키면서 API를 작성했는지에 대한 것이다.
MVC와 다르게 컨트롤러 대신에 Presenter가 View와 Model 사이를 중계해주고 있다. 따라서 Model과 View는 서로를 알 필요가 전혀 없이 Presenter만 가리키게 된다. 따라서 View와 Model의 의존성은 사라지게 된다.
모델은 위 MVC패턴과 동일하며 뷰와 프리젠터에서 구성 요소의 변화가 있다.
V(View) 기본적으로는 MVC와 같이 화면에 보여지는 요소를 맡는 것은 동일하나 Controller가 사라짐에 따라서 이제 사용자의 입력을 받는 역할을 겸하게 된다. MVC에서 Controller의 역할의 일부를 얻게 되었다고 이해하면 좋다.
P(Presenter) View에서 요청한 정보로 Model을 가공하여 View에 전달해주는 부분이다. 본질적으로는 MVC의 컨트롤러와 같지만 뷰에 연결되는 것이 아니라 그냥 인터페이스라는 점이 다르다.
MVP패턴의 장/단점
장점 MVC와 달리 View와 Model의 의존성이 사라졌다.
단점 View와 Model 사이의 의존성은 해결되었지만 대신에 View와 Presenter 사이에 높은 의존성을 가지게 되었다. 이는 MVC와 마찬가지로 어플리케이션이 복잡해질수록 View와 Presenter 사이의 의존성이 더욱 강해지고 복잡해진다.
MVVM 패턴
Model , View, ViewModel
VM(ViewModel) 뷰에 필요한 데이터를 준비하고 모델에 필요한 이벤트를 전달한다. 그러면서도 뷰에 종속되지 않는 뷰만을 위한 모델이라고 할 수 있다.
어떻게 뷰와 뷰모델, 뷰모델과 모델간에 의존성이 사라지게 되느냐. 그것은 바로 Command패턴과 Data Binding 덕분인데, 이 패턴과 라이브러리로 인해서 의존성이 완전히 사라지게 된다.
Command패턴과 Data Binding은 각각 또 하나의 문서를 할애해서 설명이 필요할 만큼이나 긴 설명이 필요해서 해당 포스팅의 목적과 엇나갈 수 있으므로 간략하게만 짚고 넘어가자.
Command패턴은 앞서 설명한 여러가지 디자인 패턴들 중에 하나이며 요청을 객체의 형태로 캡슐화하여 저장, 로깅, 취소를 할 수 있는 패턴이다.
Data Binding은 XML에 만든 View들을 자동으로 알아서 만들어주는 안드로이드 라이브러리이다.
요약하자면 여전히 MVP패턴처럼 View를 통해 사용자의 입력이 들어오게 되면 Command패턴으로 ViewModel에 요청한다. ViewModel은 Model에게 필요한 데이터를 요청하고 Model은 응답한뒤 ViewModel에서 다시 가공해서 저장한다. 여기서 View로 다시 안돌려주냐고 할 수 있는데, View는 Data Binding을 통해 자동으로 갱신하게 된다.
MVVM 패턴의 장/단점
장점
Command 패턴과 Data Binding을 사용하여 View와 Model, 심지어 View와 View Model 사이의 의존성 또한 없앴다.
테스트와 모듈화가 쉽다
뷰와 모델을 연결하기 위해 사용해야 하는 연결 코드를 줄일 수 있다.
단점
View Model의 설계가 쉽지 않다.
뷰가 변수와 표현식 모두에 바인딩될 수 있어서 시간이 지남에 따라 관계없는 프리젠테이션 로직이 늘어나 유지 관리하기 번거롭다.
NoSQL은 "Non Relational Operation Database SQL"의 줄인말로서 관계형 데이터베이스가 아닌 SQL이다.(SQL은 Structured Query Language로 관계형 데이터베이스 관리 시스템의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어이다.)
일반적인 관계형 데이터베이스에서는 데이터의 중복을 제거하고 무결성을 보장하기 위해서 정규화를 하게 되는데, 이러한 정규화가 과도한 JOIN으로 인해 성능 저하가 있을 수 있다.
그동안 지속적으로 관계형 데이터베이스만을 보아왔는데, 그런 형태가 아닌
Nosql 예시(출처 :[01. MongoDB(몽고디비) Study - NoSQL 이란? 그리고 MongoDB 소개](https://cionman.tistory.com/44))
위와 같은 형태로 DB가 구성될 수 있다는 것이다.
이런 형태로 DB가 구성된다는 것부터가 이미 굉장히 신기했다.
NoSQL의 장점은
1. 불필요한 JOIN의 최소화
2. 데이터 분산에 용이
3. 복제 및 장애대응에 용이
4. 데이터를 고속으로 처리할 필요가 있는 경우
등 굉장히 많은 장점들이 올라와 있는데, 아직까지 직접 사용해보지 않아서 잘 와닿지 않는다.
추가적으로 비정형 데이터로 인해 관계형 데이터베이스보다 1.5배 정도 용량을 많이 차지한다는 것도 신기했다. (Nosql이라고 해서 아예 데이터를 쌓지 않는다고 생각한 무식이 슬프다..)
NoSQL에도 종류가 여러가지 있고 그 중에서 이번에는 MongoDB를 처음 접해보았는데, 조금 더 공부하면서 배운 것들을 다시 정리해야 되겠다.
Webhook 혹은 API, 2가지 모두 그 서비스에서 제공을 해줘야지만 가지고 와서 쓸 수 있다.
webhook과 api의 가장 큰 차이는 api는 우리가 요청했을 때 해당 서비스에서 요청한 자료를 주는 것이고 webhook의 경우에는 해당 서비스에서 우리가 설정해놓은(또는 제공해주는) 특정 변화가 있을 때 해당 정보들을 보내준다.
웹훅의 이점에 대해 atlassian에서 잘 정리해놓아서 가지고 와본다.
Advantages of webhooks
Without webhooks, if you want to detect when events occur in Bitbucket Cloud, you need to poll the API. However, polling the API is inconvenient, inefficient, and error-prone. Consider how SMS messages work on mobile phones. You don't have to check your messages every 5 minutes to see if you have a text because your phone sends you a notification. In the same way, webhooks work like the notification so that the API does not have to check for the same activity every minute.
즉 우리의 휴대폰에서 5분마다 메시지가 왔는지 확인하는 것은 매우 비효율적이다. 따라서 우리는 메시지가 올 때만 알람을 듣고 확인하게 하는데, 5분마다 폰을 켜서 메시지가 왔는지 확인하는 것은 api, 그리고 그 메시지가 왔을 때 알람을 주는 것은 webhook이다.
=> 해당 글은 현재까지의 이해도를 바탕으로 작성하고 있어, 틀린 부분이 많을 수 있습니다. 댓글 적어주시면 앞으로 고쳐가도록 하겠습니다!
