BeeImp

[Network] REST API란?

beeimp — Sun, 4 Sep 2022 20:06:47 +0900

REST API

REST(Representational State Transfer) API는 데이터 또는 리소스를 HTTP 프로토콜을 통해 URI로 요청하고 응답받는 방식을 의미합니다. API의 역할은 클라이언트와 서버 모두 올바르게 사용할 수 있어야 합니다. 따라서, 올바르게 사용할 수 있는 규칙들을 정의하여 디자인하는 것은 중요한 작업입니다.

Richardson Maturity Model 정리

Richardson Maturity Model에 따르면 REST API를 실용적으로 적용하기위한 0단계에서 3단계로 성숙도 모델을 정의했습니다.

0단계 - 기본 단계

0단계에서는 REST API를 사용하지 않고 단순히 HTTP Protocol을 사용하는 기본 단계입니다. 실용적인 REST API를 만들기 위한 기본 단계라고 할 수 있습니다.

1단계 - 개별 리소스와 통신 준수

1단계는 개별 리소스와 통신을 준수하는 단계입니다. 모든 리소스는 각 리소스에 맞는 Endpoint를 사용하여 요청하고 자원에 대한 정보를 응답해야 합니다.

2단계 - HTTP 메소드 준수

2단계는 HTTP 메소드의 사용에 중점을 둔 단계입니다. CRUD에 따른 적절한 메소드를 사용해야 합니다. 또한, HTTP 메소드 사용에도 규칙(MDN HTTP Request Methods)을 따릅니다.

GET 메소드는 서버의 데이터를 변경하지 않는다.
POST는 요청마다 새로운 리소스를 생성한다.
PUT은 요청마다 같은 리소스를 반환하는 멱등성(idempotent)을 가진다.
PUT은 교체, PATCH는 수정의 용도로 사용한다.

3단계 - HATEOAS 적용

마지막 단계인 3단계는 HATEOAS(Hypertext As The Engine Of Application State)을 적용하는 단계입니다. HATEOAS는 Hypertext를 통해 애플리케이션의 상태 전이가 가능해야하는 REST 애플리케이션 아키텍처의 제약입니다. 응답 메세지에 리소스의 URI 포함하는데, 이는 효율적으로 리소스와 기능에 접근 가능한 트리거가 될 수 있습니다.

REST API의 6가지 제약조건(Constraints)

Client-server
- 리소스가 있는 쪽을 서버, 리소스를 요청하는 쪽을 클라이언트로 정의
Stateless
- 서버는 클라이언트의 Context를 저장하지 않고, 각각의 요청에 대해 별개로 인식하고 처리
Cacheable
- 대량의 요청을 효율적으로 처리
Layered System
- 클라이언트는 REST API 서버만을 호출
- 서버는 보안, 로드 밸런싱, 암호화, Proxy 등 다중 계층으로 구성
Code on Demand(옵션)
- 규칙 중에 유일하게 옵션으로 API의 응답을 확인해볼 수 있는 UI 위젯을 제공
Uniform Interface - 리소스에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일
- Identification of Resources
  - 리소스가 URI로 식별되면 된다.
- Manipulation of Resources through Representations
  - 리소스를 추가, 수정, 삭제 등의 행위를 HTTP Message에 표현을 포함시켜야 한다.
- Self-Descriptive Messages
  - 메세지를 스스로 설명해야한다.
  - Description, Content-Type 등
- Hypermedia As The Engine Of Application State (HATEOAS)
  - 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.
올바른 REST API를 사용하기 위해서는 6가지의 제약조건을 갖춰야 합니다. HTTP API의 사용만으로 Client-Server, Stateless, Cacheable, Layered System, Code on Demand(옵션)는 지켜집니다. 그러나, Uniform Interface를 지키기가 어렵습니다. 그 중에서도 Self-Descriptive Messages, HATEOAS는 잘 지켜지지 않고 있습니다.

왜? `Uniform Interface` 의 제약조건을 지켜야할까요?

서버와 클라이언트가 있을 때, 독립적인 진화가 가능해집니다. 서버가 여러 업데이트를 진행해도 클라이언트는 업데이트를 할 필요가 없는 것입니다. REST API의 설계 목적가 가장 인접하다고 할 수 있습니다. 예를 들어, 출시한지 얼마안된 모바일 앱의 서버를 지속적으로 최적화하면서 모바일 앱도 업데이트를 요구합니다. 이 경우 사용자는 이용 중 많은 불편함을 느끼게 될 수 있습니다. 즉, 독립적인 진화가 필요합니다. REST API의 설계자인 로이 필딩은 HTTP API를 고치면 앱에 문제가 생기는 부분을 고민했고, Uniform Interface를 만족해야만 REST API라고 말할 수 있게 되었습니다.

REST API의 제약 조건 중 하나라도 빠지도 REST API인가? NO

REST API를 사용해봤다면 한 가지 의문점이 생깁니다. ‘REST API의 제약 조건을 모두 지키지 않지만 잘 동작합니다. 꼭 다 지켜야 REST API인가요? 잘 동작하면 되는거 아닌가요?’라고 이야기할 수 있습니다. 로이 필딩은 단호하게 REST의 모든 제약조건을 지키지 않는다면 REST API가 아니라고 이야기합니다. 추가적으로 전체 시스템을 통제할 수 있거나, 독립적인 진화에 관심이 없다면 REST의 모든 제약조건을 고민하지 말라고 이야기합니다. 즉, REST 제약조건을 모두 따르지 않다면 REST API가 아니지만 HTTP API라고 할 수 있는 것입니다. 로이 필딩은 REST의 제약조건을 모두 따르지 않는다면 다른 단어를 써달라고 이야기했습니다. 결국, 단어 선택의 차이일 뿐 사용에 문제가 없다면 HTTP API라고 말하면 되는거 아닐까요?

[Network] URL과 URI 차이점

beeimp — Thu, 1 Sep 2022 02:09:36 +0900

URL과 URI 차이점

URL는 많이 들어봤지만 URI는 뭘까요? 먼저, 많이 들어본 URL(Uniform Resource Locator)는 네트워크 상에 서비스에 접근하기 위한 리소스의 위치를 의미합니다. URI(Uniform Resource Identifier)는 URI에 파일의 위치와 요청사항을 추가한 자원의 식별자를 의미합니다. 즉, URI는 URL을 포함하는 개념입니다.

http://localhost:8080/about?search=beeimp

위의 예시는 일반적인 URI를 작성해보았습니다. 이를 http://, localhost, :8080, /about, ?search=beeimp&date=20220330로 구분할 수 있습니다.

http://
- scheme라고 합니다.
- 통신 프로토콜이 위치합니다.
localhost
- hosts라고 합니다. 이 부분은
- 서버의 IP, Domain이 위치합니다.
:8080
- port라고 합니다.
- 서버에서 제공하는 통로의 번호가 위치합니다.
/about
- url-path라고 합니다.
- 서버에서 웹 페이지, 사진, 영상 등 파일의 경로가 위치합니다.
?search=beeimp&date=20220330
- query라고 합니다.
- 서버에 요청할 때 추가적으로 필터링된 값을 받아옵니다.
- ?기호는 한번만 작성하여 query의 시작을 의미합니다.
- key=value형태로 작성합니다.
- &는 AND를 의미합니다.

왜 지갑 주소에는 대소문자가 들어갈까?

beeimp — Mon, 29 Aug 2022 20:52:58 +0900

왜 지갑 주소에는 대소문자가 들어갈까?

상황

이더리움 초창기에는 소문자만 사용하여 주소를 생성했었는데, 잘못된 주소를 입력하여 송금하는 사고가 종종 발생했다.

문제

이러한 경우 회수가 현실적으로 불가능하여 주소 입력 오류 확인이 필요했다.

해결

2016년에 도입된 EIP-55를 통해 주소 오류를 99.9853% 감지
EIP-55는 주소의 대소문자 형태로 인코딩해 주는 방식으로 checksum한다.
checksum은 prefix인 0x를 뗀 소문자를 사용해서 표현한 주소의 해시값이 역할을 수행한다.

방법

'''EIP-55 Code'''
import eth_utils

def checksum_encode(addr): # Takes a 20-byte binary address as input
    hex_addr = addr.hex()
    checksummed_buffer = ""

    # Treat the hex address as ascii/utf-8 for keccak256 hashing
    hashed_address = eth_utils.keccak(text=hex_addr).hex()

    # Iterate over each character in the hex address
    for nibble_index, character in enumerate(hex_addr):

        if character in "0123456789":
            # We can't upper-case the decimal digits
            checksummed_buffer += character
        elif character in "abcdef":
            # Check if the corresponding hex digit (nibble) in the hash is 8 or higher
            hashed_address_nibble = int(hashed_address[nibble_index], 16)
            if hashed_address_nibble > 7:
                checksummed_buffer += character.upper()
            else:
                checksummed_buffer += character
        else:
            raise eth_utils.ValidationError(
                f"Unrecognized hex character {character!r} at position {nibble_index}"
            )

    return "0x" + checksummed_buffer

def test(addr_str):
    addr_bytes = eth_utils.to_bytes(hexstr=addr_str)
    checksum_encoded = checksum_encode(addr_bytes)
    assert checksum_encoded == addr_str, f"{checksum_encoded} != expected {addr_str}"

test("0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed")
test("0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359")
test("0xdbF03B407c01E7cD3CBea99509d93f8DDDC8C6FB")
test("0xD1220A0cf47c7B9Be7A2E6BA89F429762e7b9aDb")

소문자만을 사용하는 이더리움 주소의 해시값을 구한다.
이더리움 주소와 해시값을 왼쪽부터 하나씩 확인하면서 다음과 같을 경우 대문자로 수정한다.
- 이더리움 주소가 0xa 이상
- 해시값이 0x8 이상인 경우
입력 오류가 있을 경우 위와같은 checksum 인코딩에서 미스매치가 발생하여 오류를 쉽게 검출할 수 있다.

결론

EIP-55를 통해 지갑 주소의 무결성을 보호하기 위해 대소문자를 사용한다.

[Project] 누구(Who)가 아닌 기술을 신뢰하는 Klaytn 기반 티켓팅 서비스

beeimp — Tue, 2 Aug 2022 23:47:51 +0900

1. 프로젝트 개요

TT 란 ?

누구(Who)가 아닌 기술을 신뢰하는 Klaytn 기반 티켓팅 서비스

Trust Ticket, TT는 블록체인 기술을 이용한 티켓팅 서비스를 제공합니다.
TT 이용자는 이벤트를 기획할 수도 있고, 다른 이벤트를 참여할 수 있습니다.
이벤트 참여를 하면 각 이벤트에서 발행하는 토큰을 받을 수 있고, 이는 입장티켓 또는 응모당첨권으로 사용합니다.

배포 링크

Github: https://github.com/codestates/BEB-04-ZeroTeb
Mobile : 다운링크 (스토어 배포 심사 중)
Server - POST API Document
WEB - https://tt.beeimp.com

2. 프로젝트 소개

토큰 이코노미

왜 필요한가요?
- 이벤트가 돌연 취소
  - 상황 - 소비자는 이벤트 기획측 또는 플랫폼에서 알 수 없는 이유로 콘서트 취소에 대해 일방적인 통보를 받았습니다.
  - 문제 - 소비자는 일방적인 통보를 받았음에도 보상을 받을 수 없습니다.
- 티켓 사재기
  - 상황 - 암표상들은 개인의 이익을 위해 이벤트에서 티켓을 구매 후 몰래 재판매합니다.
  - 문제 - 암표상들은 공정한 티켓 획득 기회를 미리 사재기를 하여 웃돈을 붙여 표를 판매하기 때문에 위법하다고 할 수 있습니다.
- 플랫폼의 서비스 종료
  - 상황 - 이용하던 거래 플랫폼이 어떠한 이유로 유지할 수 없어 서비스를 종료했습니다.
  - 문제 - 이용하던 거래 플랫폼 서비스가 종료되면서 소비자의 모든 기록이 삭제되면서 지금까지의 활동이 확인할 수 없습니다.
- 각 플랫폼의 제약
  - 상황 - 이용하던 거래 플랫폼이 아닌 타 거래 플랫폼을 이용한다.
  - 문제 - 타 거래 플랫폼에서는 이전에 이용하던 거래 플랫폼에서 참여했던 콘서트 내역을 가져올 수 없거나 참여했던 실물 콘서트 티켓을 모두 등록해야하는 불편함을 가집니다.
무엇을 얻을 수 있나요?
- 소비자는 이벤트가 갑자기 취소되더라도 티켓 가격의 103%를 보상 받을 수 있습니다.
  - 이벤트 기획자는 이벤트를 등록하면서 티켓으로 판매하여 얻을 수 있는 총액의 5%(보증금 3%, 수수료 2%)를 지불합니다.
    - 보증금은 이벤트 성공시 이벤트 기획자에게 반환됩니다.
    - 수수료는 주로 컨트랙트 실행, 서버 유지비에 사용됩니다.
  - 이벤트가 최소되면 소비자는 대해 티켓의 103%를 보상 받습니다.
    - 이벤트 기획자의 보증금이 피해 보상금으로 사용합니다.
- 소비자는 공정한 티 켓케득 기회를 얻을 수 있습니다.
  - 이벤트가 종료될 때까지 토큰 거래가 불가능합니다.
    - SBT와 NFT를 적절히 사용하여 참여에 대한 티켓의 주요 목적을 달성합니다.
- 소비자는 이용하던 티켓 플랫폼이 종료되더라도 모든 기록을 잃지 않습니다.
  - 데이터베이스가 손상되더라도 Klaytn Network에서 복구 가능합니다.
  - 만약, 해당 플랫폼의 서비스가 종료되더라도 모든 기록은 Klaytn Network에 투명하게 저장되어 토큰형 티켓의 거래 또는 확인이 가능합니다.
- 이벤트 기획자는 이용하던 여러 티켓 플랫폼이 통합적으로 VIP를 관리할 수 있습니다.
누가 할 수 있나요?
- 카카오 계정이 있다면 누구든 사용 가능하고 누구든 될 수 있습니다.
언제, 어디서 사용할 수 있나요?
- 모바일 기기에 종류에 상관없이 언제, 어디서든 이용 가능합니다.
  - React-Native로 앱이 제작되어 Android, ios에 상관없이 사용 가능합니다.
- 언제, 어디서든 이벤트를 등록할 수 있습니다.
  - PC, Mobile 모두 지원합니다.
- 언제, 어디서든 티켓을 구매, 응모, 인증, 확인 가능합니다.
어떻게 사용할 수 있나요?
1. 카카오톡 앱을 설치합니다. ( 이미 다 있으실 거에요 )
2. 앱 서비스에서 클립을 가입합니다.
3. TT 앱을 설치합니다. ( 앱 스토어, 플레이 스토어 등 배포 예정입니다! )
4. TT 앱을 실행하여 이벤트 등록부터 티켓 구매, 응모, 조회, 인증, 확인까지 자유롭게 이용 가능합니다.

Klaytn 사용한 이유

카카오 클립으로 누구나 간단하게 지갑 생성 가능합니다.
- 복잡한 지갑 생성 과정을 거치지 않고, 국민 메신저 서비스로 자리 잡은 카카오톡 앱이 있다면 사용 가능한 클립을 사용하기 위해 채택했습니다.
속도와 가격 측면에서 용이합니다.
- 가격 - 트랜잭션에서 발생하는 가스비가 1~20원 수준으로 매우 저렴합니다.
- 속도 - 이론적 측면이 아닌 실제 4000 TPS의 처리량을 가집니다

WorkFlow

기능별 시연 영상

랜딩 페이지 (WEB)

Klip 로그인
- Klip을 이용한 개발Klip에서 request key를 받아 서버로 전송하고, 서버에서 Klip과 통신해서 사용자를 인증합니다. 인증된 사용자에게 JWT 토큰을 발행하여, TT의 기능을 사용할 수 있도록 합니다.
- 현재 Klip API에서 테스트 넷을 지원하지 않습니다. 그래서 Klip의 일부 기능들을 서버에서 구현하여 Klip API의 역할을 대체합니다.
이벤트 등록(모바일)
- 간편한 이벤트 등록
- 스마트폰으로 간단하게 이벤트를 등록할 수 있고, 많은 데이터를 등록하는 사람들을 위해 웹으로도 등록할 수 있습니다.
- 토큰 발행
- 이벤트가 등록되면, 컨트랙트는 토큰을 서버에 발행합니다. 발행된 토큰은 구매를 통해 얻을 수 있습니다.
이벤트 등록(웹)
이벤트 티켓 구매/응모
- 티켓 구매
- 서버는 티켓을 구매한 사용자에게 티켓을 전송합니다. 사용자가 쉽게 구매할 수 있도록 Klip API를 사용하여, 편의성을 높였습니다.
- 티켓 응모
- 응모한 사용자의 주소를 컨트랙트에 보관합니다. 이벤트 응모 가능 기간이 지나면 서버가 자동으로 이벤트 추첨을 컨트랙트에 요청합니다. 이벤트 추첨은 응모자 중 랜덤으로 당첨자를 선정합니다.
QRcode 생성
- 간편한 티켓 생성
- QR 코드는 앱에서 티켓을 클릭할 때 발행되고, 서버는 해당 QR에 유효 기한을 부여합니다. QRcode는 nonce 데이터를 가지고 있습니다.
QRcode 유효성 확인
- 티켓 확인하기서버는 해당 이벤트의 QRcode인지, 유효 기한이 남았는지 검사합니다.
- QR Reader는 QRcode에서 읽은 데이터(nonce, event_id)를 서버로 전송합니다.
검색
- 원하는 이벤트 찾기
- 사용자는 Keyword가 포함한 이벤트를 검색할 수 있습니다.
- 인기 있는 이벤트 (개발 진행 중)이후 같은 키워드가 들어오면 count값을 올려주고, count가 가장 많은 키워드를 인기 검색어로 정합니다.
- 사용자가 검색한 키워드 중 검색 결과가 유효한 데이터를 DB에 저장합니다.
내 주변
- 나와 가까운 이벤트 찾기
- 현재 위치의 좌표를 서버로 보냅니다. 서버는 Map API를 통해 사용자의 지역을 찾고, 이벤트의 좌표와 거리를 구해 사용자에게 출력해 줍니다.

3. 기술 스택

4. 관련 문서

시나리오 기반 WorkFlow

https://www.figma.com/proto/EiawCKjCRga7uzldcSx5fu/ZeroTEB_Architecture?node-id=85%3A2&scaling=min-zoom&page-id=0%3A1

App Prototype

https://www.figma.com/proto/ISnNAWq8EU68Np1WNlIS3P/ZeroTEB_Mockup?node-id=5%3A6&starting-point-node-id=5%3A6

5. 내가 수행한 역할

Project Management

Notion을 통해 프로젝트 전체 work-flow 기획
Discord에서 Github Webhook를 연결하여 Github bot 연결

Blockchain

KIP17을 활용한 Solidity 컨트랙트 작성
- 이벤트 생성
- 이벤트 토큰 민팅, 거래, 응모
- 이벤트 당첨자 추첨 - 랜덤함수 구현
- 이벤트 종료

Back-End

DB 생성 및 원격 연결 - Mongo Atlas
JWT 인증 기능 구현 - Nest.js @Guard
DB 정보 추가 및 업데이트 Scheduling 구현 - Nest.js @Cron
컨트랙트 실행 API 구현 - Caver-js
서버 자동 배포
- Azure VM 위에 Docker, Jenkins 설치
- Github Webhook에 Jenkins설정
- Jenkins Pipeline 작성

Front-End (WEB)

Lending Page
Create Event Page
Created View Page

6. 회고

초기 목표(시작하게 된 목표)

프로젝트 초기 목표
- 투자에 과열된 NFT 또는 SBT에 대한 새로운 인식 제공
- 누구나 이벤트 성공 여부에 대한 최대 보상 제도 도입
- 누구나 이벤트를 생성 수 있고 혜택을 받을 수 있는 서비스 구현
팀장으로써 목표
- 팀원들 간의 심리적 갈등이 없이 프로젝트가 즐겁게 시작하여 마무리
- 저를 포함한 팀원이 프로젝트에서 얻고자하는 방향 및 결과물 완성
- 각 포지션의 개발
- 프로젝트 이슈 관리
개인 목표
- 모두 피해 받지 않는 토큰 이코노미 설계
- 티켓팅 컨트랙트 작성 및 배포

현실(실제 어떤 원인에 의해 문제가 발생했고 해결했는가?)

각 포지션에만 집중할 수 있는 환경
- 상황 - 백엔드에서 개발한 API를 통해 프론트에서 테스트를 진행해야 합니다.
- 문제 - 프론트에서 API를 테스트하기 위해서는 백엔드 서버를 로컬에 다운받아 서버를 실행시켜 테스트해야하는 어려움이 있었습니다.
- 해결 - 클라우드 서비스 중 Azure를 이용하여 VM을 생성하여 Docker와 Jenkins를 설치했습니다. Jenkins를 프로젝트 Github Webhook과 연결하여 push 이벤트가 발생하면 빌드하여 실행할 수 있도록 설정했습니다. 이를 통해, 서버에서는 API를 개발 후 push하면 프론트에서는 해당 API를 사용할 수 있었습니다.
카카오 클립 메인넷만 지원
- 상황 - 앱에서 로그인, 이벤트 등록, 티켓 구매, 응모 등 카카오 클립 지갑을 통해 컨트랙트에 요청해야 했습니다.
- 문제 - 테스트 환경에서 진행하는 프로젝트에서 카카오 클립이 테스트넷을 지원하지 않았습니다.
- 해결 - 가스비가 발생하지 않는 로그인 인증 부분만 카카오 클립을 사용하고, 이외의 클립 API는 서버에서 자체적으로 테스트용 지갑을 생성 후 매칭하여 서버 API를 통해 대체 했습니다.
당첨자를 뽑기 위한 랜덤 함수 구현
- 상황 - 이벤트 응모를 진행하면 당첨자를 뽑는 추첨을 진행해야 했습니다.
- 문제 - 이중 반복문을 사용하여 suffle을 구현하게 되면 시간 복잡도 n^2으로 높은 가스비가 발생할 수 있었습니다.
- 해결 - 해시 함수를 통해 랜덤한 값을 응모자 수의 나머지 값으로 랜덤한 인덱스를 생성하고 순차적으로 Swap했습니다. 이를 통해, 시간 복잡도 n을 달성하여 가스비 절감과 속도 성능을 향상 시킬 수 있었습니다.

후기(지속, 개선, 포기할 것은 무엇인가, 아쉬운 점)

포기 - 개인적으로 설계했던 시나리오 수정
- 내용 - 팀원을 뽑기 전, 개인적으로 설계했던 시나리오를 수정했습니다.
- 포기한 이유 - 팀원 모두 프로젝트를 재밌게 진행하기 위해 시나리오를 수정했습니다. 포괄적으로 제시했던 아이디어에서 개인적으로 했으면 좋겠던 시나리오가 있었는데, 그 시나리오를 포함하여 다른 팀원들이 생각하는 시나리오를 수합하여 투표를 진행하여 최종적으로 하나의 시나리오를 채택하게 되었습니다.
지속 - 각 포지션에 해당하는 독립적인 작업 부여
- 내용 - POSTMAN의 Mock server 기능을 활용하여 프로젝트 진행 간 백엔드와 프론트에 대한 기능 개발 유무와 상관없이 테스트 API를 사용하여 간섭없이 각 개발을 진행할 수 있었습니다.
- 지속하려는 이유 - 이전에 프로젝트를 진행할 때는 백엔드에서 API를 개발할 때까지 데이터를 가져올 수 없어 더미 데이터를 추가하고 진행했었습니다. 이 과정에서 더미 데이터 위치에 API를 연결해야하는 추가 작업이 필요 했었는데, 추가 작업을 진행하지 않아 생산성을 향상시킬 수 있었습니다.
아쉬운점 - 진행 상황 관리 부족
- 내용 - 일일 2회 회의를 진행하면서 이슈 사항을 정리하면서 프로젝트를 관리했습니다.
- 아쉬운 이유 - 프로젝트 기한이 다가오면서 팀원들의 일일 프로젝트 작업을 제대로 확인하지 못했습니다. 또한, 다들 지쳐가고 와중에 팀장으로써 제대로 독려를 못한 것 같아 아쉬웠습니다.
개선 - 지속적인 진행 상황 확인 및 관리
- 내용 - 아쉬운점과 같습니다.
- 개선하려는 이유 - 프로젝트 결과물이 개인적으로 기대하는 만큼 UI가 그려지지 못해 너무 아쉬웠습니다. 팀장으써 각 팀원의 컨디션과 진행 상황을 제대로 파악하지 못했기 때문이라고 생각합니다. 바쁠수록 돌아가라는 말이 있습니다. 추후 프로젝트를 진행하게 된다면, 다음 사항을 생각하면서 개선하려고 합니다.
  1. 기본 기능, 주요 기능, 고급 기능, 추가 기능 등 기능들을 단계별 세분화 개발
  2. 지속적으로 결과물을 평가하고 일정을 조정하여 프로젝트를 관리

[TIL] Nest 중복 호출 오류, Node process.cwd()와 __dirname의 차이

beeimp — Wed, 13 Jul 2022 23:27:09 +0900

[TIL] Nest 중복 호출 오류, Node `process.cwd()`와 `__dirname`의 차이

날짜

2022.07.13.

목표

Nest.js 학습

내용

Nest.js - `@InjectConnection` 중복 호출 오류

오류 메세지

  ERROR [ExceptionHandler] Nest can't resolve dependencies of the AuthService (JwtService, ?, UsernameConnection). Please make sure that the argument UserConnection at index [1] is available in the AuthModule context.

  Potential solutions:
  - If UserConnection is a provider, is it part of the current AuthModule?
  - If UserConnection is exported from a separate @Module, is that module imported within AuthModule?
    @Module({
      imports: [ /* the Module containing UserConnection */ ]
    })

원인

@**InjectConnection** 가 두번 선언되어서 오류 발생

export class AuthService {
constructor(
  private jwtService: JwtService,
  **@InjectConnection(User.name) private userModel: Model<User>,
  @InjectConnection(Username.name) private usernameModel: Model<Username>,**
) {}
  ...
}

해결

  export class AuthService {
      userModel: Model<UserDocument>;
    usernameModel: Model<UsernameDocument>;
    constructor(
      private jwtService: JwtService,
          **@InjectConnection() private readonly mongooseConnection: Connection,**
    ) {
          this.userModel = mongooseConnection.model(User.name);
      this.usernameModel = mongooseConnection.model(Username.name);
      }
      ...
  }

Node.js - `process.cwd()`와 `__dirname`의 차이

process.cwd()
- 전역 객체의 메소드
- 프로세스의 현재 작업 디렉토리를 문자열 값으로 리턴
__dirname
- 현재 스크립트의 디렉토리 이름
- 전역이 아니라 각 모듈에 대해 로컬을 문자열 값으로 리턴

결론

오류의 원인을 정확히는 모르겠지만 잘 해결되었습니다.

[TIL] Mongo - import json file

beeimp — Wed, 13 Jul 2022 02:02:42 +0900

[TIL] Mongo - import json file

날짜

2022.07.12

내용

MongoDB - import json file for macOS

mongoimport 설치
- brew install mongodb/brew/mongodb-database-tools
실행
$ mongoimport \ --uri=<Atlas Cluster URI> \ --drop=<File Name>.json --jsonArray -c <Collection Name>

결론

랜덤하게 생성한 JSON 형태의 파일을 MongoDB에 import하는 방법을 학습 및 실습 했습니다.

[TIL] Klip, EIP-5114

beeimp — Sun, 10 Jul 2022 01:54:48 +0900

[TIL] Klip, EIP-5114

날짜

2022.07.10

목표

SBT 구현을 위한 학습

내용

KaKao Klip - App2App API
Authentication
- 기본적으로 인증이 필요하지 않음
- API 요청시 - Request Key를 발급하여 사용
- Request Key 발급 절차
  1. prepare API를 통해 인증 또는 서명할 내용을 전달
    - 응답으로 Request Key를 전달
  2. 전달받은 Request Key를 이용하여 Deep Link를 호출하고, 모바일 카카오톡 더보기 탭에 있는 Klip 실행
  3. 처리 결과는 Result API를 통해 polling
    - Query 파라미터 Request Key에 어떤 요청에 대한 처리 결과를 얻고자 하는지 전달

Ethereum - EIP-5114 : SoulBound Token

SoulBound Token : 거래 불가능 NFT

interface IERC5114 {
    // fired anytime a new instance of this token is minted
    // this event **MUST NOT** be fired twice for the same `tokenId`
    event Mint(uint256 indexed tokenId, address indexed nftAddress, uint256 indexed nftTokenId);

    // returns the NFT token that owns this token.
    // this function **MUST** throw if the token hasn't been minted yet
    // this function **MUST** always return the same result every time it is called after it has been minted
    // this function **MUST** return the same value as found in the original `Mint` event for the token
    function ownerOf(uint256 index) external view returns (address nftAddress, uint256 nftTokenId);

    // returns a censorship resistant URI with details about this token collection
    // the metadata returned by this is merged with the metadata return by `tokenUri(uint256)`
    // the collectionUri **MUST** be immutable and content addressable (e.g., ipfs://)
    // the collectionUri **MUST NOT** point at mutable/censorable content (e.g., https://)
    // data from `tokenUri` takes precedence over data returned by this method
    // any external links referenced by the content at `collectionUri` also **MUST** follow all of the above rules
    function collectionUri() external view returns (string collectionUri);

    // returns a censorship resistant URI with details about this token instance
    // the tokenUri **MUST** be immutable and content addressable (e.g., ipfs://)
    // the tokenUri **MUST NOT** point at mutable/censorable content (e.g., https://)
    // data from this takes precedence over data returned by `collectionUri`
    // any external links referenced by the content at `tokenUri` also **MUST** follow all of the above rules
    function tokenUri(uint256 tokenId) external view returns (string tokenUri);
}

결론

클레이튼에서 SBT 구현을 위해 이더리움 EIP에서 SBT 관련 부분을 공부했습니다.

[TIL] Nest.js 프로바이더와, React-Native 안드로이드 설정

beeimp — Fri, 8 Jul 2022 02:03:53 +0900

[TIL] Nest.js 프로바이더와, React-Native 안드로이드 설정

날짜

2022.01.01

목표

Nest.js 학습

내용

Nest.js - Provider

Provider : 앱이 제공하는 핵심 기능인 비즈니스 로직 수행
- Service, Repository, Factory, Helper 등

@injectable 데코레이터 사용

다른 어떤 Nest 컴포넌트에서도 주입 가능해짐

import { Injectable } from '@nestjs/common';

@Injectable()
export class UsersService {
  ...

remove(id: number) {
  return `This action removes a #${id} user`;
}
}

사용

  @Controller('users')
  export class UsersController {
    constructor(private readonly usersService: UsersService) {}
      ...

      @Delete(':id')
      remove(@Param('id') id: string) {
        return this.usersService.remove(+id);
      }
  }

React-Native - 안드로이드 설정

OS - macOS ( m1 )

기본 설치

  # Node & Watchman
  $ brew install node
  $ brew install watchman

Java Development Kit

  $ brew tap homebrew/cask-versions
  $ brew install --cask zulu11

Android Studio 개발 환경 설정
- Android SDK
- Android SDK Platform
- Android Virtual Device
SDK Platforms 설치
- Appearance & Behavior → System Settings → Android SDK → Click ‘Show Package Details’
- Android SDK Platform 31
- ARM 64 v8a System Image
- Google APIs ARM 64 v8a System Image

ANDROID_SDK_ROOT 환경 변수 설정

  $ export ANDROID_SDK_ROOT=$HOME/Library/Android/sdk
  $ export PATH=$PATH:$ANDROID_SDK_ROOT/emulator
  $ export PATH=$PATH:$ANDROID_SDK_ROOT/platform-tools

project 생성

  $ npx react-native init AwesomeTSProject # --template react-native-template-typescript

서버 실행
```
  $ npx react-native start
```
앱 실행
```
  $ npm run android
```

결론

API 31 버전이 기본으로 되어 있었고, m1이라 약간 설치가 달랐습니다. API 32 버전을 사용하고 arm 관련 설치 해주니 잘 동작했습니다.

참조링크

https://wikidocs.net/148511

[TIL] Nest.js 컨트롤러 부분 학습

beeimp — Wed, 6 Jul 2022 23:45:28 +0900

[TIL] Nest.js 컨트롤러 부분 학습

날짜

2022.07.06.

목표

Nest.js 학습

내용

Nest.js - Controller

MVC 패턴에서 Controller에 해당
- Request로 받은 데이터를 처리하고 결과를 Response하는 인터페이스 역할

Nest.js - Routing

데코레이터 사용

@Get('/hello')
getHello(): string {
  return this.appService.getHello();
}

와일드카드 사용 가능

@Get('he*lo')
getHello(): string {
  return this.appService.getHello();
}

Nest.js - Request/Response Object

import { Request, Response } from 'express';
import { Controller, Get, Req, Res, Param } from '@nestjs/common';
import { AppService } from './app.service';

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get(':id')
  getHello(
        @Param('id') id: string, // Parameter
        @Req() req: Request, 
        @Res() res: Response
    ): string {
    res.send(this.appService.getHello(id));
  }
}

Nest.js - Custom Header

import { Header } from '@nestjs/common';

@Header('Key', 'Value')
@Get()
getHello(): string {
  return this.appService.getHello();
}

// 또는

@Header('Key', 'Value')
@Get()
getHello(
    @Res() res: Response
): string {
    res.header('Key', 'Value');
  res.send(this.appService.getHello());
}

Nest.js - Redirection

클라이언트를 다른 페이지로 이동시키고 싶은 경우 사용
HTTP code - 301, 307, 308
- 아니면 제대로 동작 안할 수 있음

@Get('redirect/docs')
@Redirect('https://docs.nestjs.com', 302)
getDocs(@Query('version') version) {
  if (version && version === '5') {
    return { url: 'https://docs.nestjs.com/v5/' };
  }
}

Nest.js - Sub-Domain Routing

하위 도메인 설정

  @Controller({ host: 'api.beeimp.com' }) // 하위 도메인 요청 처리 설정
  export class ApiController {
    @Get() // 같은 루트 경로
    index(): string {
      return 'BeeImp API'; // 다른 응답
    }
  }

Nest.js - Payload (@Body)

// DTO(Data Transfer Object) 정의
export class CreateUserDto {
  name: string;
  email: string;
}

@Post()
create(@Body() createUserDto: CreateUserDto) {
  const { name, email } = createUserDto;

  return `유저를 생성 - 이름: ${name}, 이메일: ${email}`;
}

결론

Nest.js 조금만 더 공부하면 편하게 API를 구축할 수 있을 것 같다는 생각이 들었습니다.

[TIL] Nest.js Decoration

beeimp — Tue, 5 Jul 2022 01:03:47 +0900

[TIL] Nest.js Decoration

날짜

2022.07.04

목표

내용

Nest.js - 데코레이터

파이썬의 데코레이터나 자바의 어노테이션과 유사
클래스, 메서드, 접근자, 프로퍼티, 매개변수에 적용 가능

JS - +로 숫자형 변환

const str = '123';

console.log(typeof str); // string
console.log(typeof Number(str)); // number
console.log(typeof parseInt(str)); // number

console.log(typeof +str); // number

결론

nest.js의 데코레이션을 보면서 자바 스프링이 생각났습니다. 이미 스프링 조금 공부해봤기에 비교적 쉽게 배울 수 있을 것 같습니다.
JS에서 +로 숫자형으로 바로 변환 가능함을 알게 되었습니다.

BeeImp

[Network] REST API란?

REST API

Richardson Maturity Model 정리

0단계 - 기본 단계

1단계 - 개별 리소스와 통신 준수

2단계 - HTTP 메소드 준수

3단계 - HATEOAS 적용

REST API의 6가지 제약조건(Constraints)

왜? Uniform Interface 의 제약조건을 지켜야할까요?

REST API의 제약 조건 중 하나라도 빠지도 REST API인가? NO

[Network] URL과 URI 차이점

URL과 URI 차이점

왜 지갑 주소에는 대소문자가 들어갈까?

왜 지갑 주소에는 대소문자가 들어갈까?

상황

문제

해결

방법

결론

[Project] 누구(Who)가 아닌 기술을 신뢰하는 Klaytn 기반 티켓팅 서비스

1. 프로젝트 개요

TT 란 ?

배포 링크

2. 프로젝트 소개

토큰 이코노미

Klaytn 사용한 이유

WorkFlow

기능별 시연 영상

3. 기술 스택

4. 관련 문서

시나리오 기반 WorkFlow

App Prototype

5. 내가 수행한 역할

Project Management

Blockchain

Back-End

Front-End (WEB)

6. 회고

초기 목표(시작하게 된 목표)

현실(실제 어떤 원인에 의해 문제가 발생했고 해결했는가?)

후기(지속, 개선, 포기할 것은 무엇인가, 아쉬운 점)

[TIL] Nest 중복 호출 오류, Node process.cwd()와 __dirname의 차이

[TIL] Nest 중복 호출 오류, Node process.cwd()와 __dirname의 차이

날짜

목표

내용

Nest.js - @**InjectConnection** 중복 호출 오류

Node.js - process.cwd()와 __dirname의 차이

결론

[TIL] Mongo - import json file

[TIL] Mongo - import json file

날짜

내용

MongoDB - import json file for macOS

결론

[TIL] Klip, EIP-5114

[TIL] Klip, EIP-5114

날짜

목표

내용

KaKao Klip - App2App API

Ethereum - EIP-5114 : SoulBound Token

결론

[TIL] Nest.js 프로바이더와, React-Native 안드로이드 설정

[TIL] Nest.js 프로바이더와, React-Native 안드로이드 설정

날짜

목표

내용

Nest.js - Provider

React-Native - 안드로이드 설정

결론

참조링크

[TIL] Nest.js 컨트롤러 부분 학습

[TIL] Nest.js 컨트롤러 부분 학습

날짜

목표

내용

Nest.js - Controller

Nest.js - Routing

왜? `Uniform Interface` 의 제약조건을 지켜야할까요?

[TIL] Nest 중복 호출 오류, Node `process.cwd()`와 `__dirname`의 차이

Nest.js - `@InjectConnection` 중복 호출 오류

Node.js - `process.cwd()`와 `__dirname`의 차이