Skip to main content

Jest JS, Rest API & GraphQL

2021-02-02#

List#

  • Jest JS
  • What is Unit, e2e Test
  • TDD
  • Nest JS Unit Test

Jest JS#

Jest JS

Jest는 단순성에 중점을 JavaScript 테스트 프레임 워크입니다.

Babel, TypeScript, Node, React, Angular, Vue 등을 사용하는 프로젝트에서 모두 작동합니다.

// 모든 테스트 실행 전
beforeAll(() => {
return initializeCityDatabase();
});
// 모든 테스트 실행 후
afterAll(() => {
return clearCityDatabase();
});
// 각 매서드&함수 실행 전
beforeEach(() => {
initializeCityDatabase();
});
// 각 매서드&함수 실행 후
afterEach(() => {
clearCityDatabase();
});
describe('matching cities to foods', () => {
// describe 스코프 안에서만 적용
beforeEach(() => {
return initializeFoodDatabase();
});
test('today is cold?', () => {
temp = getTemp(today);
expect(temp < 0).toBe(true);
});
test('get seoul temp', () => {
expect(getCityTemp('seoul')).toBeInstanceOf(Number);
});
});

Unit, e2e Test#

Why Unit Test?#

단위 테스트는 코드를 “어떻게” 작성하는지 생각하는데 도움을 줍니다. 게다가 “무엇”을 해야하는지에 있어서 구현 선택을 검토하는데 해가 되지 않고 그 선택들이 적절한지 아닌지 알아낼 수 있다.

  • 단위 테스트를 하는동안 코드들이 다르게 보일 수 있음
  • 주된 효과로 단위 테스트를 추가하는 것은 애플리케이션의 유닛(함수/메소드)를 더 작게 만드는게 가능해진다.
  • 코드를 이해하고 테스트 하기 쉽게 만드며, 따라서 변화시키는 것 또한 쉽도록 도움을 준다.

많은 일을 하는 테스팅 코드는 어렵다.
많은 일을 하는 디버깅 코드는 어렵다.

이 두 가지 문제의 해결법은 많은 일을 하지 않도록 코드를 작성하는 것이다. 각각의 함수를 단 한가지만의 일을 하도록 작성해야 한다. 이렇게 하면 단위 테스트로 쉽게 테스트할 수 있다. (하나의 함수에 대해 많은 단위 테스트가 필요하지 않는다.) 내 동료가 메소드를 더 작게 분리해야 하는지에 대해 판단할 때 사용하는 문구가 있다. 만약 코드의 역할을 다른 프로그래머에게 설명할 때 ‘and’라는 단어를 사용했다면 그 메소드는 적어도 하나 이상의 부분으로 나눠야 한다는 것이다.

StackOverflow

Unit Test#

모든 Function을 단위마다 테스트

Nest JS 에서는 보편적으로 서비스에서 분리된 유닛을 테스트 함

e2e Test(end to end)#

모든 시스템을 테스트

Nest JS에서 컨트롤러 -> 서비스 -> 뷰 등의 예로 사용자가 동작한 큰 흐름을 하나 테스트 함 즉 사용자가 취할만한 액션들을 처음부터 끝까지 테스트

번외 TDD#

TDD(Test-Driven Development) 테스트 주도 개발

미래에 대한 예측을 최대한 하지 않고, 지속적으로 프로토타입을 완성하는 애자일 방법론 중 하나이다. 이 방법론은 추가 요구사항이 생기더라도, 실시간으로 반영할 수 있다.

TDD 개발 흐름

  • 위의 그림은 TDD의 개발주기를 표현한 것

Red 단계에서는 실패하는 테스트 코드를 먼저 작성한다.
Green 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
Yellow 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.

일반 개발

🔸 일반적인 개발 방식

보통의 개발 방식은 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포의 형태의 개발 주기를 갖는데 이러한 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다.

  • 소비자의 요구사항이 처음부터 명확하지 않을 수 있다.
  • 처음부터 완벽한 설계는 어렵다.
  • 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다.
  • 자체 테스트 비용이 증가할 수 있다.

❌ 결론적으로 이러한 코드들은 재사용이 어렵고 관리가 어려워져 유지보수를 어렵게 만든다.

TDD 개발

🔸 TDD 개발 방식

  • TDD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 점
  • 디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고, 또 무엇을 테스트해야 할지 미리 정의(테스트 케이스 작성)해야 함
  • 테스트 코드를 작성하는 도중에 발생하는 예외 사항(버그, 수정사항)들은 테스트 케이스에 추가하고 설계를 개선함
  • 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성함

🔆 이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고, 소스코드는 간결해진다. 또한, 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감된다.

namelanguage
CUnitC
CppUnitC++
PHPUnitPHP
PyUnitPython
JUnitJava

장점

  • 보다 튼튼한 객체 지향적인 코드 생산
  • 재설계 시간의 단축
  • 디버깅 시간의 단축
  • 테스트 문서의 대체 가능
  • 추가 구현의 용이함

단점

  • 가장 큰 단점은 바로 생산성의 저하

단순한 어플리케이션을 개발하는 경우 경험에 의해 어떤 예외상황이 발생할지 눈에 뻔히 보이는 경우가 많다. 특히 이러한 단발성 개발은 개발 기간이 타이트하게 잡히는 경우가 많은데, 이럴 때 TDD를 적용해 뻔한 테스트 코드를 작성하고 그에 통과하기 위한 코드를 작성한다면 마치 답을 알고 푸는 문제집처럼 따분하고 비효율 적일 것이다.

참고 개발개발 울었다

Nest JS Test#

Nest JS Test

HINT

Keep your test files located near the classes they test. Testing files should have a .spec or .test suffix.

2021-02-09#

List#

  • Nest JS e2e Test
  • Web of E2E Test FrameWork

Nest JS End-to-end testing#

Nest JS e2e Test

애플리케이션이 성장함에 따라 각 API 엔드 포인트의 엔드-투-엔드 동작을 수동으로 테스트하기가 어려워집니다. 자동화 된 종단 간 테스트는 시스템의 전반적인 동작이 정확하고 프로젝트 요구 사항을 충족하는지 확인하는 데 도움이된다.

  • 엔드-투-엔드 (e2e) 테스트는 최종 사용자가 프로덕션에서 가질 수있는 상호 작용의 종류에 더 가까운보다 총체적인 수준에서 클래스 및 모듈의 상호 작용을 테스트
  • e2e 테스트를 수행하기 위해 방금 단위 테스트 에서 다룬 것과 유사한 구성을 사용
  • Nest를 사용하면 Supertest 라이브러리를 사용하여 HTTP 요청을 쉽게 시뮬레이션 할 수 있음

Mind Set#

e2e Test는 최종 사용자의 경험에 입각하여 테스트를 진행하자

Unit Teste2e Test
테스트는 하나의 코드 또는 애플리케이션으로 제한됩니다.테스트는 여러 응용 프로그램과 사용자 그룹에 걸쳐 있습니다.
테스트 된 소프트웨어가 허용 기준을 충족하는지 확인합니다.변경 후에도 프로세스가 계속 작동하도록합니다.
단일 사용자가 애플리케이션에 참여하는 방식을 테스트합니다.여러 사용자가 여러 응용 프로그램에서 작업하는 방식을 테스트합니다.
입력 및 출력에 대한 각 테스트의 결과를 확인합니다.프로세스의 각 단계가 완료되었는지 확인합니다.

E2E Test FrameWork#

Web 환경에서는 Cypress, Selenium, TestCafe.. 등등 테스트 프레임워크가 존재

Cypress#

  • OpenSource Project(MIT License)
  • Browser Support: Electron, Chrome
  • Element 접근: Iframe에 Target Web을 올린 뒤 Browser 내부에서 접근
  • Headless Support: 지원
  • CLI Support: 지원
  • ScreenShot: 지원
  • Video Record: Electron만 지원
  • 심플한 API 제공
  • Mocha 기반이기 때문에 Nodejs 개발자들에게 익숙
  • 내부적으로 queue를 사용 sync인것 처럼 동작

단점#

  • multi tab 미지원
  • popup: 미지원
  • Cypress 내부 에러 핸들링이 쉽지 않음
  • 완성도가 낮음

참고자료 웹 환경 e2e-test 프레임워크

Nest JS Supertest#

!!테스팅시 실제 서버환경처럼 구성해주는것이 중요함

app.e2e-spec.ts#

import { Test, TestingModule } from '@nestjs/testing';
import { INestApplication, ValidationPipe } from '@nestjs/common';
import * as request from 'supertest';
import { AppModule } from './../src/app.module';
describe('AppController (e2e)', () => {
let app: INestApplication;
beforeAll(async () => {
// 여기서 실제 어플리케이션의 환경을 설정해줘야함
const moduleFixture: TestingModule = await Test.createTestingModule({
imports: [AppModule],
}).compile();
app = moduleFixture.createNestApplication();
app.useGlobalPipes(
new ValidationPipe({
whitelist: true, // 데코레이터에 없는 속성값은 제외 후 저장
forbidNonWhitelisted: true, // 데코레이터에 없는 속성이 있을경우 Exception
transform: true, // url 인자를 타입에 맞게 자동변환
}));
await app.init();
});
it('/ (GET)', () => {
return request(app.getHttpServer())
.get('/')
.expect(200)
.expect('Hello World!');
});
})
});

Nest JS...?#

  • Nestjs 는 효율적이고 확장 가능한 Node.js Server side application
  • Typescript 을 완벽히 지원 OOP, FP, FRP 를 지원한다.
  • Express 에 비해 NestJS 는 Framework 단에서 구성해주는 것이 많음
    • Cli 를 사용하면, 코드 구조, Test Framework, Prettier, ESLint 를 생성해줌
    • 초기에 프로젝트를 구성할 때 비용을 줄여주고 편리하다.
  • Annotation 기반 프로젝트 구성이 가능해 코드를 깔끔하고 가독성 높게 유지할 수 있음
  • 서드파티와 결합의 지원이 좋음
  • 내부적으로는 다른 HTTP Framework 를 추상화 해서 사용하고 있음

어떻게 생겨난걸까..?#

등장하게 된 계기는, Front Level 에서는 React, Vue, Angular 3대장과 같은 좋은 프레임워크가 등장함

Node.js 진영에서는 아키텍처를 효과적으로 해결해주는 기술이 등장하지 않아 만들어졌다고 함

NestJS 는 AngularJS 개발자들이 만들었다. 따라서 비슷한 점이 많다.

2021-02-16#

List#

  • API
  • SOAP
  • REST

API#

API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다. 주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.

나무위키 API

API 정책#

프라이빗(Private)#

API를 내부에서만 사용할 수 있도록 하며, 기업이 API를 최대한으로 제어

파트너(Partner)#

API를 특정 비즈니스 파트너와 공유하며, 품질 저하 없이 추가 수익원을 창출

퍼블릭(Public)#

API가 모두에게 제공되며, 제 3자가 API와 상호 작용하는 애플리케이션을 개발하여 혁신을 이끔

Interface#

인터페이스(interface)는 컴퓨터 시스템끼리 정보를 교한하는 공유 경계를 의미한다, 터치 스크린과 같은 일부 컴퓨터 하드웨어 장치들은 인터페이스를 통해 데이터를 송수신 할 수 있으며, 마우스나 키보드 같은 장치들은 오직 시스템에 데이터를 전송만 하는 인터페이스를 제공한다.

API란 어떤 사이트, 소프트웨어, 서비스 등등에서 특정 기능이나 데이터를 공유할 경우 어떠한 방식으로 정보를 요청해야 하는지, 그리고 어떠한 데이터나 기능을 제공 받을 수 있을지에 대한 규격들을 API라고 정의한다.

Why Use API#

  • API를 사용하면 구현 방식을 알지 못해도 제품 또는 서비스가 서로 커뮤니케이션 가능
  • 애플리케이션 개발을 간소화하여 시간과 비용을 절약
  • 새로운 툴과 제품을 설계하거나 기존 툴과 제품을 관리하는 경우 API는 유연성을 제공하고 설계, 관리, 사용 방법을 간소화하며 혁신의 기회를 제공

Advantage#

  • 새로운 수익 채널을 확보하거나 기존 수익 채널을 확장
  • 브랜드 인지도를 확대
  • 외부 개발을 활용하고 협업을 수행하여 오픈 혁신을 촉진하거나 효율성을 높임

혁신?#

퍼블릭 API는 파트너와의 연결 방식을 간소화하고 확대할 수 있을 뿐만 아니라 보유한 데이터를 활용해 수익을 창출할 수 있기 때문에 고유의 비즈니스 가치를 지닐 수 있다. (예: Google Maps API, Daum Map API)

Google Maps API를 이용하여 전세계 여행에 대항 좋은 루트를 공유하는 어플리케이션을 만들어 규모가 커진다면 혁신 및 수익을 창출할 수 있다.

But We Need Managed API#

API FLOW!

Web API#

API가 유비쿼터스형 웹 API로 발전하면서 설계 편의성과 구현 유용성을 높이기 위한 노력이 다각도로 이루어지고 있습니다.

유비쿼터스 - 언제 어디에서나 존재하는 것

웹의 발전 주기를 분석한 연구에 의하면 웹 1.0, 웹 2.0 그리고 웹 3.0 및 웹 4.0으로 나뉜다. 학자에 따라 의견이 분분하지만 웹 3.0을 시맨틱웹으로 본다. 웹 4.0은 유비쿼터스 웹이라고도 볼 수 있다.

SOAP#

웹 API가 확산됨에 따라, 정보 교환을 표준화하기 위해 SOAP(Simple Object Access Protocol)라는 프로토콜 사양이 개발되었습니다. SOAP로 설계된 API는 XML 메시지 형식을 사용하며 HTTP 또는 SMTP를 통해 요청을 수신합니다. SOAP를 사용하면 더 간편한 방법으로 애플리케이션을 다양한 환경에서 실행하거나 다양한 언어로 작성하여 정보를 공유할 수 있습니다.

Wiki XML

잠깐 HTTP? SMTP?#

응용 계층의 통신 HTTP, SMTP

OSI 7 LAYER

osi-7

HTTP(HyperText Transfer Protocol) 텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜

HTTPS (HyperText Transfer Protocol Secure) HTTP와 HTTPS의 차이점은 SSL(Secure Sockets Layer)를 사용해 데이터를 한쪽에서 다른 한 쪽으로 안전하게 보낼 수 있는지 여부

SMTP(Simple Mail Transfer Protocol) email 전송에 직접적으로 쓰이는 응용 계층의 프로토콜

osi-table

참고자료

REST#

REST(Representational State Transfer) REST 아키텍처의 제약 조건을 준수하는 웹 API를 RESTful API라고 합니다. SOAP는 프로토콜이지만 REST는 아키텍처 스타일이라는 근본적인 차이가 있으며 따라서 RESTful 웹 API에는 공식적인 표준이 없습니다. Roy Fielding의 논문인 '네트워크 기반 소프트웨어 아키텍처의 구조적 스타일과 설계 rest_arch_style 에 정의된 것처럼 RESTful 시스템의 다음 6가지 주요 제약 조건을 준수했을 때 RESTful API라고 간주할 수 있음

  • 클라이언트 서버 아키텍처
  • 스테이트리스
  • 캐시 가능성
  • 계층화된 시스템
  • 코드 온디맨드(옵션)
  • 통합된 인터페이스(이 제약 조건은 RESTful API 설계의 핵심이며 다음과 같은 4가지 측면을 포함)
    • 요청에서 리소스 식별
    • 표현을 통한 리소스 조작
    • 자기 기술적(Self-descriptive) 메시지
    • 애플리케이션 상태 엔진으로서의 하이퍼미디어

제약 조건이 많아 보이지만 규정된 프로토콜보다는 간단하다. 이 때문에 RESTful API가 SOAP보다 더 많이 사용되는 추세

최근 몇 년간 OpenAPI 사양은 REST API를 정의하는 공통 표준으로 부상했으며 OpenAPI는 언어 독립적인 방식으로 개발자들이 REST API 인터페이스를 구축하여 사용자가 별다른 추측 없이도 이를 사용할 수 있도록 함

참고자료 RedHat

REST API를 구현할때 기본은 지키자#

  1. URI는 정보의 자원을 표현해야한다.
  2. 자원의 이름은 동사보다는 명사를 사용한다.
  3. URI는 자원을 표현하는데 중점을 두어야 하기 때문에 행위에 대한 표현은 금지한다. (URI에 HTTP METHOD와 행위에대한 동사 표현은 사용하지 않음) GET /users/321
  4. 자원에 대한 행위는 HTTP METHOD로 표현한다. (GET, POST, PUT DELETE)
  5. URI에 자원의 행위에 대한 표현이 들어가지 않는 대신 HTTP METHOD를 통해 대신한다.
GET /users/321
DELETE /users/321
POST /users
  1. 슬래시 (/)는 계층 관계를 나타내는데 사용한다.
http://restapi.test.com/users/rooms
http://restapi.test.com/users/board
  1. URI 마지막은 슬래시(/)를 사용하면 안된다.
  2. 하이픈 (-)은 URI의 가독성을 높이는데 사용한다. (ex: 불가피하게 긴 URI를 사용하게 될 경우 하이픈을 이용하여 가독성을 높임)
  3. 언더바(_) 혹은 밑줄은 URI에 사용하지 않는다.
  4. URI는 경로에는 소문자를 사용하자 (RFC3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문)
  5. 파일 확장자는 URI에 포함하지 않는다.
  6. REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
  7. Accept header를 사용 (ex: HTTP 요청 헤더에 accept string 요청 및 응답 유형 "application/json"을 지정)
  8. 요청에 따른 올바른 응답을 반환

HTTP 응답 코드#

  • 2xx 성공
    • 200: 클라이언트의 요청을 정상적으로 수행함.
    • 201: 클라이언트에게 생성 작업을 요청 받았고, 생성 작업을 성공함.
    • 204: 요청은 성공 했지만 응답할 콘텐츠가 없음.
  • 3xx 리다이렉션
    • 301: 클라이언트가 요청한 리소스에 대한 URI가 영구적으로 변경되었을 때 사용함.
    • 302: 301과 같으나 임시적으로 주소가 바뀌었을 경우 사용함.
    • 304: 이전에 방문했을 때의 요청 결과와 다르지 않을 경우 사용함. 캐시된 페이지를 그대로 사용.
    • 307: 임시 페이지로 리다이렉트.
  • 4xx 클라이언트 오류
    • 400: 클라이언트가 올바르지 못한 요청을 보냄.
    • 401: 로그인을 하지 않아 페이지를 열 권한이 없음.
    • 403: 금지된 페이지, 로그인을 하든 안하든 접근할 수 없음. (관리자 페이지)
    • 404: 찾을 수 없는 페이지, 주소를 잘 못 입력했을 때 사용함.
    • 403 대신에 사용할 수도 있음.(해커들의 공격을 방지하고자 페이지가 없는 것처럼 위장함)
    • 408: 요청 시간이 초과됨.
    • 409: 서버가 요청을 처리하는 과정에서 충돌이 발생한 경우. (회원가입 중 중복된 아이디인 경우)
    • 410: 영구적으로 사용할 수 없는 페이지.
  • 5xx 서버 오류
    • 501: 해당 요청을 처리하는 기능이 만들어지지 않음.
    • 502: 서버로 가능 요청이 중간에서 유실된 경우.
    • 503: 서버가 터졌거나 유지 보수 중(유지 보수 중일때는 유지 보수중이라는 것을 알려주는 페이지로 전송해주는 것이 좋음)
    • 504: 서버 게이트웨이에 문제가 생겨 시간 초과가 된 경우.
    • 505: HTTP 버전이 달라 요청이 처리할 수 없음

HTTP_CODE Wiki

2021-02-23#

List#

  • GraphQL
    • Introduce
    • Why Use GraphQL
  • Not Only For React

Introduce#

GraphQL 은 REST에 대한보다 효율적이고 강력하며 유연한 대안을 제공하는 새로운 API 표준입니다. Facebook에서 개발하고 오픈 소스 로 개발했으며 현재 전 세계의 대규모 기업 및 개인 커뮤니티에서 관리하고 있습니다. (2012년부터 사용하기 시작)

GrahpQL

GrahpQL Company

넷플릭스도 자체적으로 Query Language인 falcor를 자체적으로 개발했다.

API#

API는 소프트웨어 인프라의 유비쿼터스 구성 요소가되었습니다.

간단히 말해 API 는 클라이언트가 서버에서 데이터를 로드하는 방법을 정의 합니다.

핵심은 GraphQL은 클라이언트가 API에서 필요한 데이터를 정확히 지정할 수있는 선언적 데이터 가져 오기를 지원합니다. 고정 데이터 구조를 반환하는 여러 엔드 포인트 대신 GraphQL 서버는 단일 엔드 포인트 만 노출하고 클라이언트가 요청한 데이터로 정확하게 응답합니다.

Why Use GraphQL#

Prisma Top5 Reason

💡 이 블로그 게시물 에서 GraphQL을 사용하는 주요 이유?

  1. GraphQL API에는 강력한 형식의 스키마가 존재
  • GraphQL 스키마를 정의하여 모든 GraphQL의 API의 중추가 됨
  • 입력 인수 및 가능한 응답을 포함하여 API에서 지원 하는 작업을 명확하게 정의
  1. 오버 페치언더 페치 방지
  • GraphQL을 사용하면 클라이언트가 API에서 반환하는 응답 객체의 모양을 지정할 수 있음
  1. GraphQL로 신속한 제품 개발 가능
  • GraphQL은 프런트 엔드 개발자의 삶을 쉽게 만듦
  • GraphQL 클라이언트 라이브러리 (예 : Apollo , Relay 또는 Urql ) 덕분에 프런트 엔드 개발자는 캐싱, 실시간 또는 낙관적 UI 업데이트 와 같은 기능을 무료 및 기본적으로 구성 가능
  1. GraphQL API 구성
  • 스키마 스티칭을 사용하면 여러 GraphQL API 를 결합 및 연결 하고 하나의 API 로 병합 할 수 있음
  1. 풍부한 오픈 소스 생태계와 놀라운 커뮤니티

오버 페치: 클라이언트가 페치되는 순간에 실제로 필요하지 않은 데이터를 검색하고 있음을 의미
언더 페치: 오버 페치 의 반대이며 API 응답에 포함 된 데이터가 충분하지 않음을 의미

FaceBook Develope GraphQL?#

REST 개념이 개발되었을 때 클라이언트 애플리케이션은 상대적으로 단순했고 개발 속도는 현재와 거의 같지 않았습니다. 따라서 REST는 많은 애플리케이션에 적합했습니다. 그러나 API 환경은 지난 몇 년 동안 급격하게 변화했습니다. 특히 API 설계 방식에 어려움을 겪고있는 세 가지 요소가 있습니다.

  1. 모바일 사용 증가로 인해 효율적인 데이터로드가 필요

Facebook이 GraphQL을 개발 한 초기 이유는 증가 된 모바일 사용, 저전력 장치 및 조잡한 네트워크였습니다. GraphQL은 네트워크를 통해 전송해야하는 데이터의 양을 최소화하여 이러한 조건에서 작동하는 애플리케이션을 크게 개선합니다.

  1. 다양한 FrontEnd FrameWork & Flatform

클라이언트 애플리케이션을 실행하는 FrontEnd FrameWork & Flatform 이 기종 환경으로 인해 모든 요구 사항에 맞는 하나의 API를 구축하고 유지 관리하기가 어렵습니다. GraphQL을 통해 각 클라이언트는 필요한 데이터에 정확하게 액세스 할 수 있습니다.

  1. 빠른 기능 개발을 위한 빠른 개발 및 기대

지속적인 배포는 많은 기업의 표준이되었으며 빠른 반복과 빈번한 제품 업데이트는 필수 불가결합니다. REST API를 사용하면 클라이언트 측의 특정 요구 사항 및 디자인 변경을 고려하여 서버에서 데이터를 노출하는 방식을 종종 수정해야합니다. 이는 빠른 개발 관행과 제품 반복을 방해합니다.

GraphQL!?#

API를위한 쿼리 언어

오늘날 대부분의 애플리케이션은 데이터가 데이터베이스에 저장된 서버에서 데이터를 가져와야합니다. 애플리케이션의 요구에 맞는 저장된 데이터에 대한 인터페이스를 제공하는 것은 API의 책임입니다.

GraphQL은 종종 데이터베이스 기술과 혼동하지말자. GraphQL은 데이터베이스가 아닌 API를위한 쿼리 언어 입니다. 그런 의미에서 데이터베이스에 구애받지 않고 API가 사용되는 모든 컨텍스트에서 효과적으로 사용할 수 있다.

참고자료 HowToGrahpQL

Tech Kakao GrahpQL

Not Only For React#

Facebook이 GraphQL에 대해 처음으로 공개적으로 발표 한 것은 React.js Conf 2015에서 였고 곧 오픈 소스 계획을 발표 한 직후 였습니다. Facebook은 항상 React 의 맥락에서 GraphQL에 대해 이야기 했었기 때문에, 비 React 개발자가 GraphQL이 결코 React와 함께 사용하는 기술이 아니라는 것을 이해하는 데 시간이 소모되었다.

React.js Conf 2015

My Think and Disadvantage#

단점#

  • GraphQL은 REST API에 익숙한 개발자를위한 학습 곡선을 제공합니다.
  • GraphQL은 데이터 쿼리 작업의 대부분을 서버 측으로 이동하므로 서버 개발자에게 복잡성이 추가됩니다.
  • 구현 방법에 따라 GraphQL은 특히 속도 제한 및 가격을 고려할 때 REST API와 다른 API 관리 전략이 필요할 수 있습니다.
  • 캐싱은 REST보다 더 복잡합니다.

    GraphQL에서는 하나의 URL에서 처리하기때문에 GraphQL만의 캐싱 방식을 찾아야 한다. 영속 쿼리(persisted query), 아폴로 엔진(Apollo Engine) 등이 있습니다.

  • API 유지 관리자는 GraphQL 스키마를 작성하는 추가 작업이 있습니다.

My Think#

API를 만들일이 있으면 클라이언트에서 요청하는 정확한 데이터를 고려하거나 HTTP 요청등을 고려해서 성능, 패칭등을 향상시키고 편리한 API 문서화 및 확장을 위해 사용해야겠다.

만약 아래경우라면..? REST API로 고려해볼만 하다.#

  • HTTP 와 HTTPs 에 의한 Caching 을 잘 사용하고 싶을 때
  • File 전송 등 단순한 Text 로 처리되지 않는 요청들이 있을 때
  • 요청의 구조가 정해져 있을 때