Node.js (8)

❗ ERD 설계 후 해야 할 것?

• API를 큰 틀에서 설계 (세부 사항 제외)

API: Application Programming Interface

: 한 프로그램에서 다른 프로그램으로 데이터를 주고받기 위한 방법

: 애플리케이션을 프로그래밍 할 때 보다 쉽게 할 수 있도록 해주는 도구들

: 코드를 통해 데이터를 주고 받음!

• ex) 웹툰을 보여주는 어플의 서버 db안에 웹툰이 있고, 클라이언트가 특정한 웹툰을 요청할 때 … id에 따른 웹툰을 db에서 찾아서 갖다주는 코드일 때

  db.collection('웹툰').findOne({_id: parseInt(요청.params.id) }, function (err, res){
  	console.log(res);
  	res.render('detail.ejs', {data: 결과});
  });

  ⇒ API code를 짜주어야 클라이언트가 코드를 실행할 수 있음

  • API code:

    app.get('/detail/:id', function(req, res) {
    		db.collection('웹툰').findOne({_id: parseInt(요청.params.id) }, function (err, res){
    		console.log(res);
    		res.render('detail.ejs', {data: 결과});
    	});
    }

    app.get('/detail/:id', function(req, res) {

    : API (해당 url로 get을 요청하면)

    db.collection('웹툰').findOne({_id: parseInt(요청.params.id) }, function (err, res){
    		console.log(res);
    		res.render('detail.ejs', {data: 결과});

    : 해당 코드를 실행하자고 요청

• API 설계 시 필요한 것

  • API end point 설계
  • 요청 데이터/ 응답 데이터의 설계 ⇒ 이 정보들을 문서화해 프론트 개발자가 API를 사용하기 쉽도록 돕는 문서: API명세서
    

• API가 가져야 할 내용

  • 요청 방식

  • 요청할 내용

  • 자료 요청에 필요한 추가 정보

    (웹의 경우 REST API라는 원칙에 따라 작성하는 것이 좋음)

  • REST API: A가 어떤 방식으로 요청하고, B가 어떤 방식으로 응답할지 지정해 놓은 다양한 형식 중 하나

• API의 종류

  • public API: 누구나 사용 가능한 공개 API
  • private API: 사내에서만 사용 가능한 API
  • partner API: 미리 정해둔 사람만 사용 가능한 API

• 프로그램 API: 해당 프로그램의 기능들 사용 가능

  • Windows API: 윈도우 운영체제 기능들 사용 가능
  • DB 관리 프로그램 API: DB 입출력 기능 사용 가능

✔️ RESTful API

REST: 네트워크 상에서 클라이언트와 서버 사이의 통신 방식 중 하나

https://hahahoho5915.tistory.com/54

https://velog.io/@yoongja/JS-GET-vs-POST-REST-API-%EA%B0%9C%EB%85%90%EA%B3%BC-%ED%95%A8%EA%BB%98-%EC%A0%95%EB%A6%AC

• RESTful API Endpoint의 설계

  • URI에 동사가 포함되어서는 안된다
  • URI에서 단어의 구분이 필요한 경우 -를 사용한다
  • 자원은 기본적으로 복수형으로 표기한다
  • 단 하나의 자원을 명시적으로 표현하기 위해서는 /user/id와 같이 식별 값을 추가로 사용한다
  • 자원 끼리의 관계가 존재할 경우 그 관계를 URI에 표현한다

• 회원가입, 로그인, 탈퇴 API URL Endpoint

  • 로그인: POST로 설계 : 클라이언트의 정보를 서버로 넘겨 로그인에 대한 처리를 요청 *POST: 서버의 값이나 상태를 바꾸기 위해 사용 POST/users/login
    
  • 회원가입 : 회원가입 이후에 회원의 고유 값(id 등)이 생성되므로 회원가입 시점, API 호출 시점에는 유저를 식별할 값이 존재하지 않음 ⇒ POST/users/id 와 같은 설계 불가능…
    

• 리소스간 연관 관계가 있는 경우의 API 설계 ex) 교사와 교과목이 1:N인 경우 (사용자는 교사만 있다고 가정) /users/subjects : uri상 교사가 관계 상 우선이 된다는 것을 표현 /users/id/subjects : 특정 교사의 교과목 목록 표현
  

• N:M 관계 예시 ex) 게시글과 해시태그 : 계층 관계를 한눈에 파악하기가 어려움 /articles/hash-tag vs /hash-tag/articles → 더 중요한 대상을 계층 관계에서 앞에 두는 방법을 이용하는 것이 좋음…
  

• URI vs URL https://www.elancer.co.kr/blog/detail/74
  • URI: 인터넷 상의 리소스 자원 자체를 식별하는 고유한 문자 시퀀스
  • URL: 인터넷 상 리소스 자원의 위치를 나타내기 위한 규역 (자원식별자 + 위치) 특정 웹 페이지의 주소에 접속하기 위해서는 웹사이트 + 프로토콜이 필요한데, 이들 모두를 나타내는 것이 URL!
    

⭕ ES와 Babel

Babel: 자바스크립트 컴파일러 중 하나… https://bravenamme.github.io/2020/02/12/what-is-babel/

• ES: ECMA Script, JS 표준화를 위한 규격 (자바스크립트의 6번째 표준안…) ⇒ 사용하면 코드의 간결화와 생산성 향상 가능 ~ . ~ https://velog.io/@kim_unknown_/JavaScript-ES6

  • Node.js는 기본적으로 실행시 CommonJS방식으로 실행되기 때문에 ES Module방식으로 실행하기 위해서는 별도의 설정이 필요…

    {
      "name": "playground-umc-7th-nodejs",
      "type": "module"
    }

    *ES Module: require 대신 import, export를 이용해 라이브러리와 모듈을 더 안전하고 효율적으로 사용할 수 있게 해줌!

💦 프로젝트 파일 구조

• Service- Oriented Architecture: 비즈니스 로직의 분리를 목적으로 하는 프로젝트 아키텍쳐

다른 계층에 영향을 주지 않으면서 특정 계층만 수정하고 확장할 수 있으므로 기능을 개발하면서 확장, 유지, 보수할 때 유리

*비즈니스 로직: https://mommoo.tistory.com/67

*프로젝트 아키텍쳐: https://yozm.wishket.com/magazine/detail/2743/

• Controller: 클라이언트의 요청을 받아 서비스에 전달, 서비스에서 작업을 마친 데이터를 받아 클라이언트에 응답
• Service Layer: 비즈니스 로직 캡슐화 및 추상화, Controller로 부터 전달된 요청에 로직을 적용
• Data Access Layer (Repository Layer): 쿼리를 수행하며 DB와 상호작용, Service 계층에서 DB에 접근이 필요한 경우가 발생하면, 데이터에 대한 직접적인 코드가 작성

⇒ 클라이언트의 요청→ Controller가 요청 받아 Service에 전달→ DB가 필요한 경우 Repository를 통해 DB와 상호작용 하여 얻어낸 결과로 비즈니스 로직 처리→ Service가 결과를 Controller에 전달, 응답을 클라이언트에 전달

• DTO: Data Transfer Object: 데이터를 옮기는 객체 역할 → 계층간 데이터를 전송할 때, 클라이언트로부터 전송받은 데이터를 객체로 변환할 때 등… 사용…
  • 써야하는 이유?: DTO를 이용하면 데이터의 유효성 검사가 가능하기도 하고,,, 외부에서 전달받는 데이터가 변경되었을 때도 DTO의 내용만 수정하면 굳이 Service 자체를 수정할 필요가 없으니 편리 ~. ~
  • DTO를 어디서 만들어야 할까?
    • Service에서 생성: Service에서 Controller로 전달할 때 DTO로 데이터를 걸러 Controller로 전달하기 때문에, Controller에서 작업할 때는 DB의 민감한 정보를 숨길 수 있음 또한 DB 테이블을 직접 반환할 수 없을 때도 사용 가능!
      
    • Controller에서 생성: Controller에서 Service로 전달할 때 Service 함수의 범용성이 늘어나 유지 보수에 용이
      
• 디렉토리 구조 (폴더 구조) 예시… 예시…

  1. 계층에 따른 폴더들을 생성해주세요. (controllers, dtos, repositories, services)

  2. 해당 폴더 내에서 파일을 생성해주세요. (user.controller.js, user.service.js, user.repository.js)

     각 폴더와 파일들이 어떤 의미를 갖는지 소개드리도록 하겠습니다.

     

  • node_modules: Node.js 라이브러리들이 저장되어 있는 폴더 (자동 생성됨)
  • public: 정적 파일들을 사용할 때 사용 (이미지 등)
  • src: 소스 코드를 저장하는 폴더
    • controllers: Controller 코드를 저장하는 곳
    • dtos: DTO 코드를 저장하는 곳
    • repositories: 데이터 조작과 관련한 코드를 저장하는 곳
    • services: Service 관련 코드를 저장하는 곳

〰️ 깃허브 이슈 만들기

• 오류 모음…

  • package.js 없어서 만들기…

    

    branch 생성…ㅠㅠ

  • index 파일과 package 파일 혼동…

• 서버 프로젝트에는 다양한 상수와 비밀 값들이 필요하지만 이 값들이 깃허브에 업로드 되어서는 안됨…

  ⇒ .env 파일을 만들어 비밀 값들을 기록하고 해당 파일은 깃허브에 업로드되지 않도록 설정!!
  

연결 완!!

🆘 API 짜기 ~. ~

🔆 API docs

• 기본 요청
  • GET: 리소스 조회(최근에는 Representation이라는 이름을 많이 사용한다.)
  • POST: 요청 데이터 처리, 주로 등록에 사용
  • PUT: 리소스를 대체, 해당 리소스가 없으면 생성
  • PATCH: 리소스 부분 변경
  • DELETE: 리소스 삭제

User

Follower

Following

Posts