2021-03-22

2021-03-22 GraphQL

2021-03-22 GraphQL

GraphQL

페이스북에 의해 REST 구조를 개선하기 위한 방식으로 개발된 시스템

구조

기존 REST는 우측과 같이 서버에서 데이터를 가져올때 연관된 요청을 모두 요청 해야한다. 하지만 그 과정에서 항상 모든 정보가 쓰이진 않으며 처리될때 어떤 정보를 받게될지 명확하지 않다.
이점을 개선하여 SQL 과 같이 필요한 정보만을 타입 과 데이터 구조를 요청하게 된다.

내부 구조는 간단히 키워드로만 구성된 계층구조로 조회하는 형태로 보인다.
상세한 구조는 document에 심층적으로 소개되어있으니 그걸 참조

{
  hero {
    name
  }
}
{
  "data": {
    "hero": {
      "name": "R2-D2"
    }
  }
}

장단점

REST의 일부 단점을 개선 하였지만 그렇다고 완벽한것은 아닌것
알아서 상황에 맞는 구조로 설계하기

  • 필요한 데이터만 요청
  • 어떤 데이터구조가 이용될지 명확
  • 한번의 요청으로 필요한 데이터 조회가능

  • 기존 http 캐싱 구조를 사용할 수 없음
  • 파일 업로드의 명확한 구현이 되어있지않음
  • 요청 필터링의 어려움

    사용될 데이터를 요청할때 구조가 정의되는 탓에 항상 최적의 데이터를 조회한다고 볼수없기때문

  • 구조가 복잡해지는 문제
  • 이미 REST 구조로도 처리가 가능한 경우가 존재

Written with StackEdit

참조
5 reasons you shouldn’t be using GraphQL
GraphQL의 단점과 대안

2021-03-22 Pub-Sub 구조

2021-03-22 Pub-Sub 구조

Publish - Subsclibe

구조

아래와 같이 publisher 가 topic 계층으로 전달한 메세지를 broker 에서 해당 topic 을 보고있는 subscriber에게 메세지를 전달하는 구조

subscriber
publisher
topic/location
topic/state
topic/state
topic/location
topic/state
topic/location
state
location
state,location
update
broker

Written with StackEdit.

2020-11-30

js Proxy & Reflect (like observer)

js Proxy & Reflect (like observer)

MDN Proxy / MDN Reflect

proxy 와 reflect는 동일하게 동작하지만
reflect로 정의된 객체를 proxy로 재정의하여
동작을 할당한다고 보면 될것으로 생각됨

아래와 같은 관계로 재정의 되지않은 기본동작 정의

new Proxy(obj, {
  get: Reflect.get,
});

정리

MDN handler

var 대상Object = {} ;
var hander = new handler(....참조);
var obj = new Proxy(대상Object,  handler);

handler props

get
prop 값 호출시

get: function (대상_object,대상_prop_명) {}

set
prop 값 설정시

set: function (대상_object, 대상_prop_명, 설정값) {}

deleteProperty
prop delete시

deleteProperty: function (대상_object, 대상_prop_명) {}

ownKeys
Object.keys(대상obj) 호출시

ownKeys: function (object_내부의_모든_props) {}

has
prop 조회시

has: function (대상_object, 찾을_prop_명) {}

defineProperty
prop 조회시

defineProperty: function (대상_object, 추가된_prop_명, 정의된_값의_속성) {}

getOwnPropertyDescriptor
설명 요청시

getOwnPropertyDescriptor: function (대상_object, 설명을_검색할_prop_명) {}

Written with StackEdit.

2019-12-16

2019-12-12 피드백 || RDB 와 NO-sql

2019-12-12 피드백 || RDB 와 NO-sql

RDB (Relational Database)

ACID rules

  • 원자성(Atomicity) - 중간 단계까지 실행되고 실패하는 일이 없도록 하는 것
  • 일관성(Consistency) - 트랜잭션 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것
  • 고립성(Isolation) - 다른 트랜잭션의 작업이 끼어들지 못하도록 보장하는 것
  • 지속성(Durability) - 성공적으로 수행된 트랜잭션은 영원히 반영되는 것

NO-sql (Not Only SQL)

Key-Value

DynamoDB에 키-값 쌍으로 저장된 데이터의 예를 보여주는 다이어그램

  • Set 처럼 자료 저장

document

[
    {
        "year" : 2013,
        "title" : "Turn It Down, Or Else!",
        "info" : {
            "directors" : [ "Alice Smith", "Bob Jones"],
            "release_date" : "2013-01-18T00:00:00Z",
            "rating" : 6.2
        }
    },
    ....
    {...}
]
  • json 과 같은 비슷한 형태

그래프

소셜 네트워크 그래프의 사례

인 메모리

  • 디스크 대신 RAM에 저장
  • 휘발성

RDB vs NO-sql

관계형 데이터베이스 NO-sql 데이터베이스
최적의 워크로드 관계형 데이터베이스는 트랜잭션 및 강력히 일관된 온라인 트랜잭션 프로세싱(OLTP) 애플리케이션을 위해 설계 NoSQL 키 값, 문서, 그래프 및 인 메모리 데이터베이스는 낮은 지연 시간의 애플리케이션을 포함한 수많은 데이터 액세스 패턴에 맞도록 OLTP를 위해 설계되었습니다. NoSQL 검색 데이터베이스는 반정형 데이터에서 분석을 위해 설계되었습니다
데이터 모델 테이블, 행, 열, 인덱스, 테이블 간 관계, 기타 데이터베이스 요소를 정확하게 규정 문서, 그래프, 키 값, 인 메모리, 검색 등 다양한 데이터 모델
ACID 속성 ACID(atomicity, consistency, isolation, durability)의 속성을 제공 관계형 데이터베이스의 일부 ACID 속성을 완화
성능 디스크 하위 시스템에 따름. 쿼리, 인덱스, 테이블 구조 최적화 필요 하드웨어 클러스터 크기, 네트워크 지연 시간 및 호출 애플리케이션에 따름
확장 머신성능 향상 분산형 아키텍처
API 요청 SQL(구조화 질의 언어)을 준수하는 쿼리 객체 기반 API

성능

데이터 모델 성능 확장성 유연성 복잡성 기능
키-값 스토어 높음 높음 높음 없음 가변적 (없음)
컬럼 지향 스토어 높음 높음 준수 낮음 최소
도큐먼트 지향 스토어 높음 가변적 (높음) 높음 낮음 가변적 (낮음)
그래프 데이터베이스 가변적 가변적 높음 높음 그래프 이론
관계형 데이터베이스 가변적 가변적 낮음 준수 관계대수

2019-12-14

2019-12-12 피드백 || API 요청조절 - 스로틀링(Throttling), 디바운스(Debounce)

2019-12-12 피드백 || API 요청조절 - 스로틀링(Throttling), 디바운스(Debounce)

스로틀 (Throttle)

정해진 시간보다 많은 요청을 제한적 수용

디바운스 (Debounce)

연속적인 요청 발생 후 일정 시간 후 수용

버킷 알고리즘

FIFO 큐 형태로 패킷을 버킷에 담듯 쌓아서 처리 알고리즘에 따라 패킷제어

토큰 버킷 (Token bucket)

https://i.imgur.com/XCfQQ0K.png
정해진 양의 토큰을 순환적으로 전달될 요청에 담아 토큰을 포함한 요청만 처리하는 패킷제어

소요시간 계산식
time = bucketSize ÷ (packetRate - tokenArrivalRate) × 1000m

리키 버킷 (Leaky Bucket)

Leaky Bucket
최대 대역폭을 정해 일정한 요청이 발생하도록 패킷제어

초기값

limit = 1000
packet = [200, 700, 500, 450, 400, 200]

limit 을 초과하지 않는 패킷을 network로 전송

limit = 1000 - 200 = 800
packet = [200, 700, 500, 450, 400]
limit = 1000 - 400 = 400
packet = [200, 700, 500, 450]

pacaket[firstIn] > limit 인 경우, 절차 중단후 limit = 1000 으로 초기화 후 다음 절차 진행

소요시간 계산식
time = bucketSize × packetRate ÷ 1000m

참조

Written with StackEdit.

2019-11-07