코딩하는 eroke

Node.js란?

• html = 수동적, 과거엔 웹사이트 소유자만 수정가능했으며 일일히 타이핑으로 수정했음.
• node.js = html 작성작업을 자동화하기 위해 등장한 도구 

• js = 웹과 사용자의 상호작용 도움 > 웹이 웹애플리케이션이 될수있게 한 도구
• node.js = js를 이용해 웹브라우저 자동생성하는 애플리케이션 생성가능

웹 브라우저에서 웹 어플리케이션을 실행할때 html 이용해 호출하는 것처럼

Node.js 런타임환경 (프로그램)에서 자바스크립트를 이용해 Node.js 어플리케이션을 호출할 수 있다.

Node.js 설치하기

공식사이트(nodejs.org)에서 설치가 가능하다. 윈도우, Mac, 리눅스 다양한 운영체제를 지원한다.

LTS 를 다운로드 후 실행시켜 쭉 next로 설치하면 된다.

정상적으로 설치가 완료되면 CMD 창에 명령어로 node.js 실행과 버전확인이 가능하다.

• node -v : node.js 버전확인
• node : node.js 실행 (cosole.log()로 자바스크립트 실행결과 확인가능)
• Ctrl+c (두번) : node.js 종료 

Reference

Youtube /인프런 - 생활코딩 강의 : Egoing Lee - WEB2 Node.js 

IoC

Inversion of Control : 제어의 역전

정의 및 역할

IoC 컨테이너는 DI (의존관계 주입) 기능을 제공한다.

- DI : Dependency Injection

객체간 의존관계를 생성자/Setter로 명시해 객체 생성시 의존관계를 주입하는 방식을 따르는 디자인패턴이다.

IoC란 기존에 Java에서 객체를 생성하고 의존관계를 직접 주입했다면, 

스프링에서는 컨테이너가 객체를 생성하고 의존관계를 주입하는 일을 담당하기 때문에

제어의 주체가 (어플리케이션 > 컨테이너)로 역전된 것을 의미한다.

이때 스프링 컨테이너가 생성하고 관리하는 객체들을 Bean 이라고 부른다.

(자바에서의 Bean도 자바로 작성된 객체이다.)

컨테이너 동작방식 

IoC 컨테이너는 어플리케이션의 설정 메타데이터를 읽고 자바 리플렉션 API를 사용해 객체들과 의존관계를 인스턴스화 한다.

(참고 : docs.oracle.com/javase/tutorial/reflect/index.html)

- 메타데이터의 주요 엘리먼트

• <bean> : 스프링 컨테이너가 관리하는 객체를 정의한다.
• <constructor-arg> : Service 인스턴스를 Controller 생성자 인수로 전달한다.

설정 메타데이터의 제공방식은  (1) xml / (2) 자바 어노테이션 (@) / (3) 자바코드  가 있다.

Reference

책 : 배워서 바로쓰는 스프링 프레임워크 (한빛미디어)

어느덧 경력이 2년이 되었으나 아직도 REST에 대해 명확히 설명하지 못하는 부끄러운 단계여서,,

유튜브채널 naver d2에서  '그런 REST API로 괜찮은가' 테크강의와 위키백과를 보며 REST에 대해 정리해보았다. 

 REST 

 정의 

Representational State Transfer 표현적인 상태전송

a way of providing interoperability between computer systems on the Internet.

컴퓨터 시스템간의 상호운용성을 제공하는 방법

< 분산 하이퍼미디어 시스템 (ex: 웹)을 위한 아키텍쳐 스타일 (제약조건의 집합) >

사실 정의만 봐서는 잘 와닿지 않는다.

 배경 

1. WEB의 등장 (1991)

• 표현형식 : HTML (정보를 하이퍼텍스트로 연결)
• 식별자 : URI
• 전송방법 : HTTP (프로토콜)

HTTP 명세가 추가되며 기존의 웹을 망가뜨리지 않고 HTTP를 반영할 방법에 대해 고민하게 됨

HTTP Object Model 등장 > 나중에 REST 라는 이름으로 발표 (2000)

(Roy T. Fielding - "Architectural Styles and the Design of Network-based Software Architectures")

2. API 등장

XML-RPC (MS) > SOAP (Salesforce) > REST (Flickr)  > 점점 규칙이 적고 간결해짐

MS의 REST API 가이드라인 (2016)

• URI 형식 : https://{serviceRoot}/{collection}/{id} 
• 메소드지원 : GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS
• 버저닝 : Major.minor 버전정보는 URI 에 포함

 REST API 

REST 아키텍쳐 스타일(제약조건의 집합)을 모두 따르는  API 

RESTful : Fielding 의 REST 원리를 따르는 시스템

REST 제약조건

1. 인터페이스 일관성 (Uniform Interface) : 일관적인 인터페이스로 분리되어야 한다
   • For 독립적 진화 : 서버와 클라이언트는 각각 독립적으로 진화함 > 서버 기능이 변경되어도 클라이언트 업데이트 할 필요 없음 > HTTP, HTML 명세가 변경되어도 웹은 잘 동작함
   • Uniform Interface 제약조건 (4개)
     • 1) identification of resources : 리소스는 URI로 식별되어야함
     • 2) manipulation of resources through representations : 표현을 통해 리소스를 제작해야함 > 리소스를 생성/수정/삭제할 때 메시지에 표현을 담아 전송해야하는 것
     • 3) self-descriptive messages : 메시지에 설명이 있어야함 > 확장가능한 커뮤니케이션 = 서버/클라이언트가 변경되어도 오고가는 메시지는 언제나 해석가능함 > 현재 HTTP 요청/응답메시지에는 설명 없음
     • 4) hypermedia as the engine of application state (HATEOAS) : 애플리케이션 상태는 하이퍼링크를 통해 전이되어야함 (Late binding) > 전이가 완료된 후에 다음으로 전이될 상태가 결정됨 = 링크는 동적으로 변경될 수 있어야함
     • 오늘날 REST API는 대체로 3,4 번은 못 지키고 있음
2. 무상태(Stateless) : 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다
3. 캐시 처리 가능(Cacheable): WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
   잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability와 성능을 향상시킨다.
4. 계층화(Layered System): 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는 데 유용하다.
5. Code on demand (optional) : 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다. (ex. 자바 애플릿, 자바스크립트)
6. 클라이언트/서버 구조 : 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다

결론적으로 REST로 인해 웹의 독립적 진화가 가능해짐

• HTTP에 지속적으로 영향을 줌
  • Host 헤더 추가 / 길이제한 다루는 방법 명시 (ex. 414 URI Too Long) / URI의 리소스 정의가 추상적으로 바뀜
• REST API를 개발/ HTTP API를 개발/ (현재상태) 개발한 것을 그냥 REST API 라고 부르는것 

현재 REST API를 구현하기 힘든 이유

WEB = 사람이 보는 것 ,  Media type = html, 하이퍼링크, self-descriptive (html 명세)

HTTP = 기계가 해석, Media type = Json, 하이퍼링크 X, non self-descriptive (key-val 정의 없음)

> Self-descriptive 해결하기 위한 노력 

• json에 미디어타입을 정의한 뒤 미디어타입 문서를 만들어 self description 정의 > IANA에 등록 (모든 미디어타입)
  • 단점 : 매번 미디어타입 정의 필요
• json에 명세한 문서 링크를 추가해 Profile 작성 
  • 단점 : 클라이언트가 Link 헤더(RFC 5988)와 profile (RFC 6906)을 알아야함.
  • Content negotiation 할 수 없음

> HATEOAS 해결하기 위한 노력 : data, 헤더 모두 활용

• data(json 본문)에 다양한 방법으로 하이퍼링크 표현 
  • 단점 : 링크를 표현하는 법을 직접 정의해야함
• HTTP 헤더로 링크 표현 (Link, Location 등) 
  • 정의된 relation만 활용하면 표현에 한계가 있음

 정리 

• 오늘날 대부분의 REST API는 사실 REST 를 따르지 않음 (self-descriptive, HATEOAS 불만족)
• REST는 진화하는 웹 어플리케이션을 위한 것이다.
• REST를 따를지는 API 설계자들이 스스로 판단해 결정해야한다.

 Reference

- Naver D2 : 그런  REST API로 괜찮은가

- 위키백과 : REST​

Git err : ! [rejected] master -> master (fetch first) 발생 시

원격저장소와 로컬저장소를 동기화 해주면 해결된다.

git pull --rebase origin master

위 명령어로 동기화 후 push해보면 원격저장소에 잘 올라간다.

Reference

이클립스는 간혹 프로젝트를 신규생성할때 한글이 깨진다. 매번 구글링하기 귀찮아서 박제...

1) Window > Preferences > General > Workspace > Text file encoding=UTF-8

2) Window > Preferences > General > Content Types

3) Window > Preferences > Web >  Files 인코딩 확인하기 

그리고 JS나 XML 파일이 고냥 검은 문자들로만 나와서 가독성이 똥망일때는

Window > Preferences > General > Editors > File Associations

위치에서 파일 형식이 없으면 *.파일형식 추가해주고

Associated editors 에  Add를 해보면 기본적으로 Generic Text Editor 가 있으니 추가 후 Default , Apply 해주면 된다.

알록달록해진 나의 js 코드 ㅎㅎ 

끝!

프레임워크

어떠한 목적을 달성하기 위해 복잡하게 얽혀있는 문제를 해결하기 위한 구조
SW개발에 있어 하나의 뼈대 역할을 함

클래스와 라이브러리가 합쳐진 형태

프레임워크는 재사용 가능한 수많은 클래스들과 라이브러리들을 융합한 채로 처음부터 제공해 줌 여러 개의 표준을 만들지 않아도 됨 > 개발자의 피곤함을 덜어줌

물론 틀 위에 기능들은 구현해야함

라이브러리

소프트웨어 개발 시 사용되는 프로그램의 구성요소 (도구)
공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것
대상 환경(플랫폼)에서 바로 실행될 수 있는 형태로 제공됨 (≠완전한 프로그램)


API vs 라이브러리

• 라이브러리 : 실제 실행되어 기능을 수행하는 단편화된 프로그램
동작하는 완전한 프로그램이 아님
특정한 부분 기능만을 수행하도록 제작된 (컴파일되어 기계어/바이트코드의 형태로 존재하는)프로그램

• API : 프로그래밍 언어에서 라이브러리를 사용할 수 있도록 소스코드 수준에서 인터페이스를 노출시킨 것

따라서 라이브러리는 이 자체로는 실행할 수 없으며, 해당 라이브러리의 기능을 직접 호출하는 프로그램을 실행하거나, 사용자가 해당 라이브러리의 기능을 실행하는 API를 사용하는 프로그램을 직접 개발하면 실행할 수 있다.


라이브러리 종류

- 표준 라이브러리: 특정 언어의 개발 환경에 기본적으로 포함된 것
기본적인 기능 수행과 더불어 디버깅, 성능측정 등을 위한 별도의 API가 존재함

- 런타임 라이브러리: 프로그램이 실제 환경에서 실행되기 위해 필요한 모듈들
표준 라이브러리에서 기능 수행에 필요한 것들만 제공되거나, 스크립트의 실행기 등을 말함
(ex : Windows - .dll/ Java - .jar)



Reference - 나무위키

GraphQL은 필요에 따라 REST API의 대안으로 원하는 컬럼만 요청이(POST) 가능하다

위처럼 타입 지정도 가능!

REST API vs GraphQL

• REST API
- URI 마다 하는 작업/정보가 정해져있음
- 받아야 하는 항목이 많고 정해져있는 경우에 용이
- 필요에 따라 데이터 요청 시 요청 여러번 해야하는 경우 있음
ex) 반의 정보와 학생들 명단 > 두 번 요청해야 함
- 비동기적 코드는 한 번의 요청보다 복잡해짐

• GraphQL
- 필요하지 않은 정보는 제외하고 body에 들어가는 정보로 유연하게 요청 가능 (구현 필요)
- 다른 depth들의 정보도 한 번에 요청 가능 = 클라이언트 구현 편함

같은 API 서버를 쓰더라도 사용자/기기/상황마다 필요로 하는 정보가 다른 서비스에 용이하다

GraphQL 정보요청, 삽입, 수정 방식 = POST

결론
REST API : 요청 단순(URI), 데이터 복잡
GraphQL : 요청 복잡(bracket), 데이터 효율적

백엔드서버에 둘다 구현 가능

GraphQL 구현
방법, 환경, 디테일 가지각색임
> 공식 사이트에 언어마다 라이브러리 제공
(C#/NET, Go, Groovy, Java, Python, Ruby, JavaScript, Kotlin, PHP, Scala, Swift.....)

1) app 이름으로 서버 생성
2) app.use에 인자 넣음 > 이 URI로 GraphQL 요청 받을 준비가 됨

- schema : 데이터 구조/표현법/관계

type Query{
메소드명 : [스키마명]
}

type 스키마명{
컬럼명 : 자료형, ...
}

- resolver : 각 메소드명의 요청마다 실제 작업이 어떻게 진행될지 구현 (하드코딩)

type Mutation{
db작업명(input : 스키마명Input) : Int
}

input 스키마명Input{
컬럼명 : 자료형,...
}

db작업명 : async ({input}) =>
const insertResultData = await new Promise((resolve) =>
connection.query( 쿼리 작성..)

return { idx : insertResultData.insertId }

조만간 얄팍한 코딩사전님 영상 보면서 꼭 실습을 해봐야겠다 ...!


Reference

SSH 키를 이미 사용 중이라면 다른 git, gitlab 등에서 새로운 SSH키를 사용해야 할 수 있다.

1) SSH 키 생성

Window > Preference > General > Network Connections > SSH2

Key Management의 "Generate RSA key"로 키를 생성한다.

Save Private Key로 키 저장 후 그림에 표시한 노란 부분 텍스트를 전체 복사해 github의 Setting > SSH 키에 등록한다.

2) EasyShell

이클립스 우측상단의 돋보기 아이콘 클릭 후 Marketplace 검색 > EasyShell 플러그인을 설치하면

이클립스에서 git을 커맨드창으로 실행하는 것처럼 사용할 수 있다.

3. Branch 변경

프로젝트 git init 시 기본적으로 그림처럼 master branch를 사용한다.

이클립스에서 브랜치를 추가/변경하려면

프로젝트 우측클릭 > Team > Switch to 에서 설정 가능하다.

• 추가 : "New branch"
• 변경 : "other" > "Remoe Trachking"의 브랜치 선택 후 checkout 

이클립스에서 sun.misc.BASE64Encoder 를 import 하면 access 에러가 발생한다.

Window > Preferences > Java > Compiler > Errors/Warnings > Deprecated and restricted API > Forbidden reference = Warning  (Default=Error)

위처럼 지정 후 Apply 한다.

다시 컴파일 시에도 에러가 발생하면

1) Project > Clean 

2) Problems > errors > Delete

위 단계를 수행한 뒤 다시 컴파일하면 된다.

Warning은 발생하지만 잘 실행된다.

DBeaver에서 Tibero DB에 접속하려면 드라이버 관리자에 Tibero 드라이버를 추가해주어야 한다. 

경로 : 상위탭 > 데이터베이스 > 드라이버 관리자 (Driver Manager) > New

1. 아래 내용 입력

• Driver Name : Tibero
• Class Name: com.tmax.tibero.jdbc.TbDriver
• URL Template : jdbc:tibero:thin:@{host}[:{port}]:{database}
• Default Port : 8629

2. DBeaver lib 경로 (C:\Program Files\DBeaver\jre\lib)에 tibero6-jdbc.jar 파일 추가 

3. Libraries 에 tibero6-jdbc.jar 파일 추가 (위 DBeaver lib 경로의 tibero 파일!)

Connection 새로 추가하면 Tibero가 등록된 것을 볼 수 있다.

IP, DB, 계정정보를 입력하고 Test Connection을 해보면 잘 접속되는 것을 볼 수 있다.