GraphQL

GraphQL 이란 Server API를 구성하기 위해 페이스북에서 만든 Query Language 입니다.

Server API

Server API란 요청을 하면 요청에 따른 응답을 주는 Endpoint(API가 서버에서 리소스에 접근할 수 있도록 가능하게 하는 URL, 주소)를 웹을 통해 노충하는것을 말합니다.
요청 ----> 응답
Server API를 만드는 방법론으로 REST API가 있으며 RESTful API에관해서는 이전에 정리를 하였습니다.

API란?

Application Programming Interface 즉 응용프로그램 프로그래밍 인터페이스 입니다. 응용프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 의미합니다.
또한 데이터베이스 관리 시스템과 같은 시스템 프로그램과 통신할 때 사용되는 언어나 메시지 형식을 가지며, 주로 파일 제어, 창 제어, 화상 처리, 문자 제어등을 위한 인터페이스를 제공합니다.

RESTful API

REpresentational State Transfer
말 그대로 셀프서술식이며 모든 리소스들을 하나의 엔드포인트에 연결해놓고, 각각의 엔드포인트들은 해당 리소스와 관련된 내용만 관리하며 엔드포인트를 리소스 관련해서 이름을 짓고 http 메소드로 행위를 정의하는 방식입니다.

GraphQL에 관하여

Graph Query Language의 줄임말 입니다.
쿼리 랭귀지란 말 그대로 정보를 얻기 위해 질의문(쿼리)을 만들기 위해 사용되는 컴퓨터 언어의 일종입니다.

왜 페이스북은 GraphQL을 만들었을까?

• RESTful API로 다양한 기기에서 필요한 정보를 일일히 구현하는 것에대한 어려움
• ios 와 android에서 필요한 정보가 다른 상황이 있다면 그 다른 부분마다 API를 구현하는 것에대한 어려움

GraphQL과 RESTful의 차이

1. GraphQL은 주로 하나의 엔드포인트를 사용한다. RESTful은 리소스마다 하나의 엔드포인트를 가지고 있지만, GraphQL은 전체 API를 위해 하나의 엔드포인트만 사용합니다.
2. GraphQL은 요청할 때 사용한 쿼리문에 따라 응답의 구조가 달라진다. RESTful은 하나의 엔드포인트에서 받는 응답의 구조가 정해져 있는 경우가 많습니다. 즉 이미 정해놓은 구조로 응답이 오게 됩니다. 그에 비해 GraphQL은 사용자가 응답의 구조를 자신이 원하는 방식으로 바꿀 수 있습니다.

Overfetch Underfetch

• Overfetch: 요청에 대한 응답이 필요한 정보보다 많은 정보를 받는것을 말하며, API의 세분화가 제대로 이루어지지 않았을때 생깁니다.
• Underfetch: 오버페치와 반대로 API를 구체적으로 세분화하여 하나의 API에서 필요한 정보를 다 응답받지 못해 여러번 요청을 해야할 경우입니다.

장단점

둘의 차이로 인하여 각각의 장단점이 생기게 됩니다.

GraphQl의 장점

1. HTTP 요청의 횟수를 줄일 수 있다. RESTful은 각 리소스별로 요청을 해야하고, 따라서 요청 횟수가 필요한 자원의 종류에 비례합니다. 반면 GraphQL은 원하는 정보를 하나의 쿼리에 모두 담아 요청하는것이 가능합니다.
2. HTTP 응답의 Size를 줄일 수 있다. RESTful은 응답의 형태가 정해져있고, 따라서 필요한 정보만 부분적으로 요청하는것이 어렵습니다. 반면 GraphQL은 원하는 대로 정보를 요청하는 것이 가능합니다.

GraphQL의 단점

1. 고정된 요청과 응답만 필요할 경우에는 쿼리로 인해 요청의 크기가 REST에 비해 커진다.
2. 파일 전송 등 텍스트 만으로 하기 힘든 내용들을 처리하기 복잡하다.
3. 재귀적인 쿼리가 불가능하다.

상황에 맞게 사용하기

GraphQL

• 서로 다른 모양의 다양한 요청들에 대해 응답할 수 있어야 하는 상황
• 대부분의 요청이 CRUD에 해당될 때

RESTful

• HTTP(HTTPS)에 의한 캐싱을 잘 사용하고 싶을 때
• 파일 전송 등 단순한 텍스트로 처리되지 않는 요청들이 있을 때
• 요청의 구조가 정해져 있을 때

즉 어느 하나가 좋다라고 할 수 없고, 주어진 환경에 따라서 어떤 조건에서 쓰는지, 어떠한 목표를 가지고 사용하는지에 따라서 각각의 방식의 장단점에 맞춰서 사용하는것이 중요합니다.

Database

데이터를 저장 및 보존하는 시스템입니다. 어플리케이션에서는 데이터가 메모리 상에서 존재하고 메모리에 존재하는 데이터는 보존이 되지 않습니다. 따라서 어플리케이션이 종료되면 메모리에 있던 데이터는 다시 읽을 수 없습니다.

왜 데이터베이스를 사용할까?

기존에 파일로 데이터를 저장할때는 파일저장 특성상 성능, 보안, 편의성에 한계가 있습니다. 이 한계를 극복하기 위해 고안된것이 데이터베이스 입니다.

NoSQL

비관계형 타입의 데이터를 저장할때 주로 사용되는 데이터베이스 시스템입니다.
비관계형이기에 데이터들을 저장하기 전에 정의할 필요가 없습니다.

• 장점
• 데이터 구조를 미리 정의하지 않아도 되기에 데이터의 구조 변화에 유연합니다.
• 확장성이 상대적으로 좋습니다.
• 방대한 양의 데이터를 저장하는데 유리합니다.
• 단점
• 데이터의 완전성이 상대적으로 덜 보장됩니다.
• 트랜잭션이 안되거나 불안정합니다.

관계형 데이터베이스(RDBMS Relational Database Management Sysntem)

관계형 데이터 모델에 기초를 둔 데이터베이스 시스템을 말합니다. 데이터들 끼리 서로 상호관련성을 가진 형태료 표현하며, 모든 데이터들은 테이블로 표현되고, 각각의 테이블은 로우와 컬럼으로 구성됩니다.

• 로우는 각 항목들의 실제 값 열
• 컬럼은 테이블들의 각 항목 행
• 각 로우는 고유키(Primary Key)가 있고 고유키를 통해 해당 로우를 찾거나 인용(reference)한다

테이블의 연결은 3가지 종류가 있습니다.

1. one to one 테이블 A의 로우와 테이블B의 로우가 정확히 일대일 매칭이 되는 관계
2. one to many 테이블 A의 로우가 테이블 B의 여러 로우와 연결이 되는 관계
   한 유저가 여러 제품을 구매함. 구매된 제품은 한 고객 뿐
3. many to many 테이블 A의 여러 로우가 테이블 B의 여러 로우와 연결이 되는 관계 책은 여러 작가에 의해 쓰일 수 있고 작가들은 여러 책을 쓸 수 있음
4. 장점
5. 관계형 데이터베이스는 데이터를 더 효율적, 체계적으로 저장할 수 있습니다.
6. 트랜잭션이 용이합니다.
7. 미리 저장하는 데이터들의 구조(테이블 스키마)를 정의해 데이터의 완전성이 보장됩니다.
8. 단점
9. 테이블을 미리 정의해야하기에 테이블 구조 변화 등에 유연하지 못합니다.
10. 확장성이 상대적으로 나쁩니다. (미리 구조가 정의되어 있기 때문)

SQL

Structured Query Language
Mysql과 같은 관계형 데이터베이스에서 데이터를 읽거나 생성 및 수정하기위해 사용하는 언어입니다.

MySQL 명령어 정리

• 접속

cd /usr/local/mysql/bin 해당 디렉토리 이동
MySQL 서버 활성화 (환경설정)
./mysql -urrot -p (패스워드)

• 데이터베이스 목록확인

show databases;

• 데이터베이스 삭제

DROP DATABASE [dbname]

• 해당 데이터베이스 사용

USE [dbname]

• 테이블 목록확인

show tables;

• 테이블 생성

CREATE TABLE topic(
    id INT(11) NOT NULL AUTO_INCREMENT,
    -- 아이디 정수 11글자까지 보여줌 공백허용안함 자동으로 증가시키는옵션
    title VARCHAR(100) NOT NULL,
    -- 100글자에서 자른다
    -- NULL 은 값이없는걸허용
    description TEXT NULL,
    created DATETIME NOT NULL,
    author VARCHAR(30) NULL,
    profile VARCHAR(100) NULL,
    PRIMARY KEY(id));
    -- 아이디를 프라이머리 키(메인 키 , 중복방지)로 지정

• 테이블 구조 확인

DESC [table_name]topic 테이블 구조를 보여줌

• 테이블에 로우 삽입

INSERT INTO topic (
   title, description, created, author, profile)
   VALUES(‘’Mysql”,  “MySQL is …”, NOW(), “재영”, “devloper”)
-- NOW()는 현재시간 아이디는 오토인크리먼트 값지정안하면 자동으로 올라감

• 테이블의 정보 가져오기

SELECT * from [table_name]topic;
-- 해당 테이블의 모든 데이터를 가져옴
SELECt [column](id, title) FROM topic;
SELECT id, title, created, author FROM topic WHERE author=‘재영’ ORDER BY id DESC LIMIT 2;
U

• 테이블 로우의 값 업데이트

UPDATE [table_name](topic) SET title=‘’Oracle”, description=“Oracle is …” WHERE id=2;
-- 아이디가 2번인 토픽테이블의 로우의 타이틀과 디스크립션을 업데이트

• 테이블의 로우 삭제

DELETE FROM topic Where id = 5;
-- 토픽에서 아이디가 5번인 로우 삭제

• 테이블의 이름 변경

RENAME TABLE table_name TO changed_name(topic_backup);

SQL JOIN

한 테이블이 아닌 양쪽(여러) 테이블에서 로우를 읽고 싶을 떄는 join문을 사용해서 Foreign Key(외부키)로 걸려있는 2개의 table들을 연결해서 읽습니다. 교집합의 느낌과 비슷합니다.

• 기본 문법

SELECT
  테이블별칭.조회할칼럼,
  테이블별칭.조회할칼럼
FROM 기준테이블 별칭
INNER(LEFT, ...) JOIN 조인테이블 별칭 ON 기준테이블별칭.기준키 = 조인테이블별칭.기준키

유형

• (INNER) JOIN: 일반적인 join문으로서 기준이 되는 테이블과 조인이 걸리는 테이블 양쪽 모두에 매칭되는 로우만 선택이 됩니다.
• LEFT (OUTER)JOIN: 기준이 되는 테이블의 모든 로우와 조인이 걸리는 테이블 중 기준이 되는 테이블과 매칭되는 로우만 선택됩니다.
• RIGHT JOIN: 조인이 걸리는 테이블의 모든 로우와 기준이 되는 테이블 에서 걸리는테이블과 매칭되는 로우만 선택됩니다.
• FULL JOIN: 기준이 되는 테이블과 조인이 걸리는 테이블 양쪽 모두의 로우가 선택됩니다.

위 외에도 몇가지 조인들이 더 있으나, 주로 위의 조인들만 사용됩니다.

• LEFT JOIN 예시

SELECT * FROM [table_name]topic LEFT JOIN [table]author ON topic.author_id = author.id

토픽의 author 아이디와 author의 아이디가 같은것들끼리 같은 행에 두고 토픽테이블을 기준으로 author 테이블을 걸어서 레프트 조인합니다..

SELECT topic.id, title, description, created, name FROM [table_name]topic LEFT JOIN [table]author ON topic.author_id = author.id

author도 아이디가있고, 토픽도 아이디가 있어서 그냥 id 하면 애매하다고 에러가납니다. topic.id AS topicid 라고하면 컬럼명을 topicid라고 보여줍니다.

mysql 공식문서 팁 하나하나

SELECT [ALL | DISTICT | DISCTICT ROW]

usage에서 대괄호로 묶여있으면 생략이 가능하다는 뜻