• Single Page Application의 약자로 페이지가 1개인 어플리케이션을 말한다.
• 전통적인 웹어플리케이션의 구조는 여러 페이지로 구성되어져 있다. 유저가 요청할 때마다 서버로부터 리소스를 전달 받아서 렌더링을 해왔다. 하지만 이러한 면은 정보가 많은 요즘의 웹에서는 속도적인 측면에도 문제가 되며, 렌더링하는 만큼 서버의 자원이 사용되어 불필요한 낭비가 발생하게 된다.

그래서 SPA라는 개념이 나타나게 되었는데, 기존의 방식대로 서버가 페이지 구성에 필요한 리소스를 매번 전송하는 것이 아니라, 파일은 처음에 한번 송수신 하고 그 뒤로는 실시간 데이터만 주고받게 되는 것이다.

이렇게 제일 처음 전송된 단일 HTML 페이지에 포함되어 있는 JS에서 필요한 데이터를 서버로 부터 호출하여 화면을 새롭게 구성해주는 방식이 되는 것이다.

Routing

• 라우팅은 다른 경로 (url 주소)에 따라 다른 화면을 보여주는 것

React-Router

• React-Router는 써드파티 라이브러리로서, 라우팅을 위한 가장 인기있는 라이브러리 이다.

그래서 어떻게 사용하는 건데?🧐

1. React Router 설치

npm install react-router-dom --save

2. Routes 컴포넌트 구현하기

import React from 'react';
import {
  BrowserRouter as Router,
  Switch,
  Route,
} from 'react-router-dom';

import Login from './pages/Login/Login';
import Signup from './pages/Signup/Signup';
import Main from './pages/Main/Main';

class Routes extends React.Component {
  render() {
    return (
      <Router>
        <Switch>
          <Route exact path="/" component={Login} />
                    <Route exact path="/signup" component={Signup}/>
          <Route exact path="/main" component={Main} />
        </Switch>
      </Router>
    )
  }
}

export default Routes;

<Route path="주소규칙" component={보여주고싶은 컴포넌트}>

3. Routes 컴포넌트 index.js 에 import시키기

ReactDOM.render(<Routes />, document.getElementById('root'));

• CRA로 개발 환경을 세팅했을 경우 routing 기능을 적용하기 위해서는 index.js를 수정해야한다.

컴포넌트는 LifeCycle (생명주기)를 가진다. 생명주기란 컴포넌트가 생성되고 사용되고 소멸될 때 까지의 일련의 과정을 말한다.

LifeCycle 기본순서

1. constructor
2. render
3. componentDidMount (ex: 데이터를 받는 fetch함수와 setState함수가 있을경우)
4. (fetch 완료)
5. render
6. (setState)
7. componentDidUpdate (setState가 되었기 때문에 업데이트 발생)
8. componentWillUnmount

LifeCycle API

🔹constructor

constructor(props){
super();
this.state = { 
    data:[]
    }
}

• 컴포넌트가 생성될 때 단 한번 만실행된다.
• 초기 state를 정의 할 수 있다.
  

🔹render

• 컴포넌트 렌더링을 담당한다.
  

🔹componentDidMount

componentDidMount(){
// 컴포넌트에서 필요한 데이터 요청
// 외부라이브러리 연동
// dom에 관련된 작업
};

• 컴포넌트가 만들어지고 render 가 호출 된 이후에 호출된다.

• 필요한 데이터를 axios, fetch 를 통해서 AJAX요청을 할 때, 외부 라이브러리를 연동할 때 , DOM에 관련된 작업(ex: 스크롤 설정)을 할 때 사용한다.

  
  ## 🔹componentDidUpdate

• 컴포넌트가 setState로 업데이트 되고 리렌더링을 마친 후에 실행된다.

  
  ## 🔹componentWillUnmount

componentWillUnmount(){
    console.log("componentWillUnmount");
}

• 컴포넌트가 DOM에서 사라진 후 실행된다.
• 컴포넌트 제거
  
  📚**Reference**
• LifeCycle

React에 재활용가능한 UI단위

왜 component를 쓰는가?

• 재활용하여 사용할 수 있다.
• 코드 유지보수에 좋다.
• 해당 페이지가 어떻게 구성되어 있는지 한 눈에 파악하기 좋다.
• 컴포넌트는 또 다른 컴포넌트를 포함할 수 있다. (부모 컴포넌트 - 자식 컴포넌트)

React의 컴포넌트를 만드는 방법에는 Class 컴포넌트와 함수 컴포넌트가 있다.

Class component

• 리액트에서 제공하는 클래스컴포넌트를 를 상속하여 만든다.
• 컴포넌트 안에 들어있는 data를 담고있는 state 객체 와 ui를 나타내는 render 함수로 이루어져 있다.
• 컴포넌트에 상태가 있고, 주기적으로 업데이트 되어야 한다면 클래스 컴포넌트
• 상태에 따른 (Dom tree에 올라갔거나, 나왔을 때, 컴포넌트가 업데이트 되었을 때, 등등)life cycle method 가 있다.

함수형 component

• 함수로 컴포넌트를 만든다.
• 상태가 없고 정적으로 데이터가 표기가 된다면 간단하게 만들기 함수형을 만드는 방법이 있다.
• state 오브젝트가 따로 없고 라이프사이클 메소드가 없다. → 그렇기 때문에 16.8 버전부터는 React Hook이라는 개념이 도입되었다. hook을 통해서 함수형 컴포넌트에서 state도 가질 수 있고 life cycle method 도 사용할 수있다.

Why function component?

• 기존 스크립팅 언어를 사용하는 개발자나, 디자이너와 협업시에 클래스를 이해하는데 의 개념은 어려움을 겪었다.
• 멤버 변수에 접근할 때, this 바인딩 이슈가 생긴다.
• 클래스 컴포넌트에는 라이프사이클 등의 세부적으로 함수들이 나누어져 있어서, 중복되는 코드들을 작성하게 되었었는데, react hook을 쓰면서 중복된 것을 줄일 수 있어졌다.

React 프로젝트를 진행하기 위한 작업환경을 세팅에 필요한 Tool에 대해서 알아보려고 한다.

Node.js

자바스크립트를 실행할 수 있는 환경

• 어느 곳에서나 자바스크립트로 프로그래밍이 가능하게 하는 프레임워크
• 백엔드 서버를 만들 때도 쓰고, 서버사이드 렌더링 할 때도 이용하고, 스크립트를 만들때도 쓰인다.

npm (node package manager)

패키지(외부 라이브러리) 매니저

• node.js 를 설치하면 자동적으로 설치 되는 것인데, 패키지(외부 라이브러리)를 설치/관리할 수 있는 패키지 매니저이다.
• npm을 이용하면 간단하게 명령어 하나로 라이브를 설치할 수 있고, 버전을 업데이트하거나 삭제할 수 있다.
• npm을 이용하면 package.json이라는 파일이 생기는데, 그 안에는 우리가 쓰고 있는 외부 라이브러리들과 그들의 버전의 정보가 담겨있다.

npx

패키지 실행 도구

• 패키지(외부 라이브러리)를 실행할 수 있게 도와주는 도구

CRA (Creat-React-App)

리액트 프로젝트를 시작하는데 필요한 환경을 세팅 해주는 도구(toolchain)

• CRA는 react 배우기에 간편한 환경입니다. 이것은 개발 환경을 설정하고, 최신 자바스크립트를 사용하게 해주며, 좋은 개발 경험과 프로덕션 앱 최적화를 해줍니다. (출처: 리액트 공식페이지)
• CRA에는 바벨과 웹팩과 같이 리액프 애플리케이션 실행에 필요한 다양한 패키지가 포함되어 있으며, 테스트 시스템, ES6+ 문법, CSS 후처리 등의 개발 환경을 구축해 준다.

웹팩

소스코드 번들링 라이브러리

• 여러개로 나누어져 있는 파일들을 하나의 자바스크립트 코드로 압축하고 최적화하는 라이브러리
• 의존성을 분석해 모듈을 번들(여러 개를 하나로 묶어주는)시켜주는 역할을 한다.

바벨

코드 컴파일러

• 타입스크립트나 JSX처럼 순수 자바스크립트가 아닌 것들을 변환해주거나 최신 자바스크립트 문법을 구형 브라우저에서도 이해할 수 있는 소스코드로 변환해주는 코드 컴파일러

Jest

유닛테스트를 할 수 있도록 해주는 프레임워크

React가 무엇인지, 중요한 컨셉은 무엇인지 정리해보려고 한다.

What's React

• UI를 만들 수 있는 자바스크립트 라이브러리이다.
• Component 로 이루어진 UI 라이브러리 이다.
• 재사용 가능한 Component를 모아서 원하는 웹 어플리케이션을 만들 수 있다.
• 리액트는 가상돔(Virtual Dom)을 통해 UI를 빠르게 업데이트 한다 .

가상 돔(Virtual DOM)

• 변화가 많은 View를 실제 DOM에서 처리하는 방식이 아닌 Virtual DOM과 메모리에서 미리 처리하고 저장한 후 , 실제 변화가 일어난 부분만 연산을해서 실제 DOM과 동기화 하는 프로그래밍 개념이다.

프레임워크 vs 라이브러리

프레임워크

• 정해진 골격 안에서 원하는 기능을 구현 해야한다.

• UI뿐만아니라 라우팅, 스테이트 등을 관리할 수 있는 방식 등 다양한 기능들이 한번에 묶여져서 제공되는 것.

• 많이 쓰이는 프론트엔드 웹어플리케이션 프레임워크로 Agular, Vue 가 있다.

  라이브러리

• 프레임워크와 달리, ui를 담당하는 라이브러리 / 라우팅을 담당하는 라이브러리 처럼 구현하고자 하는 기능들이 작은 단위로 구현한 것.

• 따로 정해진 골격이 없기 때문에 원하는 구조의 골격을 만들어 나갈 수 있다.

Component란?

한 가지의 기능을 수행하는 ui의 단위

• React에서 제공하는 컴포넌트라는 클래스를 상속하여 사용한다.
• 컴포넌트 안에는 이 컴포넌트 안에 들어있는 데이터를 담고있는 State 객체와 사용자에게 UI를 표기하는 render 함수가 있다.
• State 의 상태가 변경되면 render 함수가 다시 호출되면서 UI를 업데이트 해준다.
• Component의 가독성이 매우 높고 간단하여 쉬운 유지보수, 간편한 UI 수정 및 재사용이 용이하다.

Why React

• 페이스북에서 만들어진 이후로 강력한 커뮤니티가 형성 되어있고 때문에 문서화가 잘 되어 있다.
• 페이스북의 지속적인 관리와 함께 생태계가 활성화 되어 있으며 다양한 자료가 존재한다.

✅ React 의 중요한 컨셉

• React는 데이터가 변경 될 때마다 어플리케이션 전체를 다시 렌더링하여 UI를 자동으로 업데이트 해준다. → 데이터가 변경되는 부분에 대해서 한 번만 정리 해놓으면 React가 알아서 상태가 변경되면 render 함수를 다시 호출해주기 때문에 다시 해당하는 부분을 업데이트 해야되는 걱정을 하지 않아도 된다.

• React 내부에서 가상의 돔(Virtual DOM)트리를 메모리에 보관해 놓고 있기 때문에 업데이트가 일어날 때마다 이전의 트리와 비교해서 돔트리를 업데이트 하기때문에 성능을 보장할 수 있다.

이미지출처

동기

동기는 데이터의 요청과 결과가 한 자리에서 동시에 일어난다. 간딘히 말해 사용자가 데이터를 서버에게 요청한다면 그 서버가 데이터 요청에 따른 응답을 사용자에게 다시 리턴해주기 전까지 사용자는 다른 활동을 할 수 없으며 기다려야 한다.

• 장점 : 설계가 매우 간단하고 직관적이다.
• 단점 : 요청에 따른 결과가 반환되기 전까지 아무것도 못하고 대기해야한다.
  
  

비동기

비동기는 데이터의 요청과 결과가 동시에 일어나지 않는다. 서버에게 데이터를 요청한 후 요청에 따른 응답을 계속 기다리지 않아도 되며 다른 외부 활동을 수행하여도되고 서버에게 다른 요청사항을 보내도 된다.

• 장점 : 요청에 따른 결과가 반환되는 시간동안 다른 작업을 수행할 수 있으며, 자원을 효율적으로 사용할 수 있다.
• 단점 : 동기보다 설계가 복잡하다.

다음과 같은 작업들은 주로 비동기적으로 처리한다

• Ajax Web API 요청 : 서버쪽에서 데이터를 받아와야 할 때는, 요청을 하고 서버에서 응답을 할 때 까지 대기를 해야 되기 때문에 작업을 비동기적으로 처리한다.
• 파일 읽기 : 주로 서버 쪽에서 파일을 읽어야 하는 상황에는 비동기적으로 처리한다.
• 암호화/복호화 : 암호화/복호화를 할 때에도 바로 처리가 되지 않고, 어느정도 시간이 걸리는 경우가 있기 때문에 비동기 적으로 처리한다.
• 작업 예약 : 단순히 어떤 작업을 몇 초 후에 동작해야 하는 상황에는 setTimeout 을 사용하여 비동기 처리한다.

자바스크립트에서 비동기 프로그래밍을 하기 위해서 callback 함수 , Promise, async/await 라는 문법을 사용한다.

📚Reference

• 동기와 비동기에 대해서
• 자바스크립트에서 비동기 처리 다루기

REpresentational State Transfer의 약자로 전반적인 웹 어플리케이션에서 상호작용하는데 사용되는 웹 아키텍쳐 모델이다. 즉, 자원을 주고받는 웹 상에서의 통신 체계에 있어서 범용적인 스타일을 규정한 아키텍쳐

API란?

Application Programming Interface의 약자로 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것.

API를 통해 소스 및 DB에는 접근하지 못하게 하고 해당 프로그램을 사용할 수 있도록 기능을 제공하게 하는 것.

REST의 특징들

균등한 인터페이스 (Uniform Interface)

• REST는 HTTP 표준만 따른다면, 어떠한 기술이든 사용이 가능한 인터페이스 스타일이다.

무상태성 (Stateless)

• 서버는 클라이언트의 상황을 고려하지 않고 API 요청에 대해서만 처리하기 때문에 이를 "상태가 없다"라고 표현한다.

캐싱 가능 (Cacheable)

• HTTP 표준을 기반으로 만들어졌기 때문에 HTTP의 특징인 캐싱을 사용할 수 있다. 이렇게 캐시를 사용하게 되면 네트워크 응답시간 뿐만 아니라, REST 컴포넌트가 위치한 서버에 트랜젝션을 발생시키지 않아, 응답시간과 성능 그리고 서버의 자원 사용률의 부담을 덜 할 수 있다.

자체 표현성 (Self-Descriptiveness)

• REST API의 자원명시 규칙 및 메소드는 그 자체로 의미를 지니기 때문에 요청에 있어서 그 요청 자체로 어떤 것을 표현하는지 알아보기 쉽다.

클라이언트-서버 구조(Client-Server Architecture)

• REST 서버가 API를 제공하는 방식이기 때문에 클라이언트에서 처리하는 부분과 독립적으로 동작하기 때문에 서로간의 의존성이 줄어들어, 최대한 독립적으로 개발할 수 있도록 도와준다.

계층형 구조 (Layered System)

• 서버는 클라이언트가 모르게 API 서버에 여러 계층(사용자인증, 암호화 등)을 추가하여 유연한 구조로 개발 될 수 있다.

→ 이러한 특징들을 잘 지켜서 디자인을 한 것을 Restful 하다고 할 수 있다.

REST API란?

HTTP URI를 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD를 적용하는 것을 의미한다.

한마디로, 별도의 설명없이 명시적으로 구분 가능한 API를 말한다.

[참고] HTTP Method의 알맞은 역할

HTTP Method(POST, GET, PUT, DELETE) 를 가지고 자원을 CRUD를 할 수 있다.

• Create(생성)
• Read(조회)
• Update(수정)
• Delete(삭제)
  

📚 Reference

• REST API란
• REST API 제대로 알고 사용하기
• REST API

Model, View, Controller의 합성어로 소프트웨어 공학에서 상용되는 소프트웨어 디자인패턴. 애플리케이션을 세가지의 역할로 구분한 개발 방법론.

** 디자인 패턴 : 프로그램 개발에서 자주 나타나는 문제를 해결하기 위한 방법 중 하나로, 개발 과정 중 발견된 설계의 노하우를 재사용하기 좋은 형태로 특정 규약을 묶어서 정리한 것.

Model

• 애플리케이션의 정보/데이터를 나타내며, 백그라운드에서 동작하는 로직을 처리한다.

View

• 사용자가 보게 될 결과 화면을 출력한다.
• 데이터를 기반으로 사용자들에게 보여주는 화면을 나타낸다.

Controller

• 데이터와 사용자 인터페이스 요소를 컨트롤 한다.
• 사용자가 접근한 URL에 따라서 사용자의 요청을 파악한 후, 그 요청에 맞는 데이터를 Model에 보내고, 그 데이터를 View에 반영해서 사용자에게 알려준다.

Web과 MVC

mvc의 개념을 웹에 적용해보자!

1. 사용자가 웹사이트에 접속한다.
2. Controller는 사용자가 요청한 웹페이지를 서비스 하기 위해서 모델을 호출한다.
3. Model은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후에 그 결과를 리턴한다.
4. Controller는 Model이 리턴한 결과를 View에 반영한다.
5. 데이터가 반영된 View는 사용자에게 보여진다.

정리하자면!

Model 은 무엇을 할지 정의한다. -비즈니스 로직에서의 알고리즘, 데이터 등의 기능을 처리한다. Controller 는 어떻게 할지를 정의한다. -요청을 받아서 Model과 View를 연결시켜주는 역할을 한다. View 는 무엇을 화면으로 보여주는 역할을 한다. -웹이라면 웹페이지, 모바일이라면 어플의 화면의 보여지는 부분이다.

📚Reference

• MVC 디자인 패턴
• [아키텍처 패턴] MVC 패턴이란?

자주 사용되는 HTTP 통신 메소드 'GET, POST, DELETE' 의 대해서 알아보자. 해당 메소드는 클라이언트의 입장의 요청의 의도가 담긴 것이다.

GET

• 데이터를 서버로 부터 받아 올 때 주로 사용하는 메소드
• 데이터를 받아오기만 할 때 사용된다.
• 가장 간단하고 빈번히 사용되는 HTTP 메소드
  • ex) 장바구니에 담은 제품을 조회한다.

POST

• 데이터를 생성 / 수정 할 때 주로 사용되는 메소드
• 데이터를 생성 및 수정 할 때 많이 사용 되기 때문에 대부분의 경우 요청의 body 부분에 포함되서 보내진다.
  • ex) 장바구니에 맘에 드는 상품을 담는다.

DELETE

• 특정 데이터를 서버에서 삭제 요청을 보낼때 쓰는 메소드

> 기타 이외의 Method

PUT

• 기존 존재하는 데이터에 대한 변경, 갱신 할 때 사용되는 메소드

OPTION

• 서버 옵션들을 확인하기 위한 요청 할 때 사용되는 메소드. CORS에서 사용
  

Response Status Code

응답 상태를 알려주는 코드. HTTP 응답 메세지 Status Line에 'Status Code : Status Text' 로 표기된다. Status Code만 보아도 응답이 제대로 됐는지 안 됐는지 파악할 수 있다.

응답 코드는 5개의 클래스(분류)로 구분된다.

• 1xx (정보): 요청을 받았으며 프로세스를 계속한다
• 2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다
• 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다
• 4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다
• 5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다
  

💡 주요 status code에 대해서 알아보자!

200: OK

• 가장 자주 보게되는 Status Code
• 문제없이 요청에 대한 처리가 서버에서 이루어지고 나서 오는 응답코드

201: Created

• 무언가가 잘 생성되었을 때에(Successfully Created) 오는 Status Code
• 대게 POST 메소드의 요청에 따라 서버에 데이터가 잘 생성 또는 수정 되었을 때에 보내는 코드

400: Bad Request

• 해당 요청이 잘못되었을 때 보내는 Status Code
• 주로 요청의 Body에 보내는 내용이 잘못되었을 때 사용되는 코드 ex) 전화번호를 보내야 하는데 숫자가 아닌 문자열의 주소가 대신 Body에 담겼을 경우

401: Unauthorized

• 유저가 해당 요청을 진행하려면 먼저 로그인을 하거나 회원가입이 필요하다는 의미 ex) wish list, 좋아요 기능은 회원이 아니면 요청을 보낼 수 없음

403: Forbidden

• 유저가 해당 요청에 대한 권한이 없다는 뜻
• 접근 불가능한 정보에 접근했을 경우 ex) 오직 유료회원만 접근할 수 있는 데이터를 요청 했을 때

404: Not Found

• 요청된 URI 가 존재하지 않는다는 의미

500: Internal Server Error

• 서버에서 에러가 났을 때의 Status Code

보다 더 자세한 HTTP Response Status Codes MDN link

📚 Reference

• wecode
• https://ychae-leah.tistory.com/83
• https://joshua1988.github.io/web-development/http-part1/
• https://ko.wikipedia.org/wiki/HTTP_상태_코드

HTTP 요청은 클라이언트와 서버 사이에서 데이터 처리를 시작하게 하기 위해 보내는 메세지이다. 이 메세지의 구조는 크게 세 부분으로 구성되어있다

1. Start Line

 1) HTTP Method : 해당 요청이 액션을 정의 하는 부분. GET, POST, DELETE
 2) Request target : 해당 요청이 전송되는 목표 url
 3) HTTP version : HTTP 버전. 주로 1.1 버전이 널리 쓰임

ex)
GET/login HTTP/1.1
해석 : GET 메소드로 login 이라는 요청 타겟에 http 1.1 버전으로 요청을 보내겠다!

2. Headers

• 요청 그 자체에 대한 정보를 담고 있다.
• 파이썬 딕셔너리 형태 처럼 Key : Value 값으로 되어있다.
  • Header 정보
    • Host : 요청을 보내는 타겟의 URL 주소. 즉, 요청을 보내는 웹사이트 주소
    • User-Agent : 요청을 보내는 클라이언트의 대한 정보 (ex.chrome, safari .....)
    • Accept :
      • 해당 요청이 받을 수 있응 응답 body 데티어 타입 정보
      • 모든 타입을 허용하는 경우 */* 로 지정
    • Connection :
      • 해당 요청이 끝난 후에 클라이언트와 서버간의 연결을 계속 유지할 것인지 끊을 것인지 알려주는 정보
      • HTTP 요청 때마다 네트워크 연결을 새로 만드는 건 번거롭기 때문에 요청이 계속되는 한 처음 연결을 재사용하는 것이 바람직하다.
      • keep-alive : 네트워크 연결을 유지해라
      • close: 더 이상 요청을 보내지 않으니 연결을 닫아라
    • Content-Type : HTTP 요청이 보내지는 body 타입 (ex. application/json
    • Content-Length : body 내용의 길이

3. Body

• HTTP 요청이 전송하는 데이터를 담고 있는 부분
• 전송하는 데이터가 없다면 body 부분은 비어있다.

Response(응답) 메세지 구조

이 메세지 또한 세 부분으로 구성되어있다.

1. Status Line

: 응답은 요청에 대한 처리상태를 클라이언트에게 알려주면서 내용을 시작한다.

1) HTTP Version : 요청의 HTTP 버전과 동일 2) Status Code : 응답 메세지의 상태 코드 3) Status Text : 응답 메세지의 상태를 간략하게 설명 해주는 텍스트

ex) 
HTTP/1.1 404 Not Found
해석 : HTTP 1.1 버전으로 응답하고 있는데, 요청(ex.로그인시도)에 대해서 유저의 정보를 찾을수 없기 때문에(Not Found) 404 상태 메세지를 보낸다.

HTTP/1.1 200 SUCCESS
해석 : HTTP 1.1 버전으로 응답하고 있는데, 요청에 대해서 성공했기 때문에 200 상태 메세지를 보낸다.

2. Headers

• HTTP 요청 메세지의 헤더와 동일
• 단 User-Agent 헤더 대신 Sever 헤더가 사용된다.

3. Body

• HTTP 요청의 body와 동일

• 전송하는 데이터가 없으면 비어 있다.

  
  

📚 Reference

• wecode
• https://ychae-leah.tistory.com/82

하이퍼텍스트 문서를 교환하기 위하여 사용된 통신규약 이다. 즉, 인터넷에서 데이터를 주고받을 수 있는 통신규약이다. 이렇게 규칙을 정해두었기 때문에, 모든 프로그램이 이 규약에 맞춰 개발해서 정보를 교환할 수 있게 되었다.

HTTP의 두가지 특징

1. Request / Response (요청 / 응답)

• HTTP 통신의 핵심은 요청과 응답이다. 보내는 주체는 받는 주체에게 요청을 보내고, 받는 주체는 요청을 보낸 주체에게 응답을 보낸다.

  2. Stateless

  • 각각의 HTTP 통신은 독립적이기 때문에 과거의 통신(요청/응답)에 대한 내용(이전 상태)을 전혀 알지 못한다. 그렇기 때문에 매 통신마다 필요한 모든 정보를 담아서 요청을 보내야 한다.

    따라서, 만일 여러번의 통신의 진행과정에서 연속된 데이터가 필요한 경우(ex. 온라인 쇼핑몰에서 로그인 후 장바구니 기능)를 위해 로그인 토큰 또는 브라우저의 쿠키,세션, 로컬스토리지 같은 기술이 필요에 의해 만들어 졌다.

    
    

📚 Reference

• https://www.zerocho.com/category/HTTP/post/5b344f3af94472001b17f2da
• wecode
• 이미지 : https://joshua1988.github.io/web-development/http-part1/

브라우저에 데이터를 저장하는 데는 여러가지 종류가 있다. 애플리케이션 정적 리소스(HTML,JavaScript, CSS, 이미지 등)나 데이터(사용자 데이터, 기사 글 등)를 저장해야하는 것들은 다양하다.

웹 스토리지(Web Storage)

• 기존 쿠키(cookie)의 문제점을 극복하기 위해 HTML5 부터 추가된 기능이다.
• Local Storage와 Session Storage가 있다. 두 스토리지의 차이점은 영구성이다.
• Key-Value 객체 형태로 데이터가 저장된다.

로컬 스토리지 (Local Storage)

• 브라우저를 종료해도 유지되는 데이터로, 명시적으로 지우지 않는 이상 영구적으로 저장된다.
• 도메인별로 생성되며, 다른 도메인의 로컬 스토리지에는 접근이 불가능하다.
• 지속적으로 필요한 정보를 저장하기에 좋다. (ex. 자동 로그인)

세션 스토리지 (Session Storage)

• 윈도우나 브라우저 탭을 닫을 경우 제거 된다.
• 로컬 스토리지와 달리 윈도우/탭 별로 생성된다.
• 동일한 윈도우/탭이라도 다른 도메인이라면 또 다른 세션 스토리지가 생성된다. 서로 독립적으로 동작한다.
• 잠시 동안 필요한 정보를 저장하기에 좋다. (ex. 일회성 로그인)

쿠키 (Cookie)

• 로컬 스토리지와 세션 스토리지 이전에 사용되던 저장소 이다.
• 서버와 클라이언트 간의 지속적인 교환을 위해 만들어 졌기 때문에 *웹사이트에서 쿠키를 설정하면 이후의 모든 웹 요청은 *생성 될 때 마다 매번 서버에 전송 된다. (크기가 클 경우 서버에 부담이 갈 수 있다.)
• 4KB까지 저장할 수 있는 용량 제한이 있다.
• 반 영구적으로 데이터 저장이 가능하다. 사용기간을 지정가능 하며 지정하게 되면 명시된 날짜에 삭제 되거나, 명시된 기간 이후에 삭제 된다. → 시간 제한 설정 가능!

IndexedDB

• localStorage보다 훨씬 더 많은 양의 데이터를 저장할 수 있다. 위의 스토리지들에 비해 코드가 복잡하다.
• 네트워크 가능여부에 상관 없이, 온라인과 오프라인 모두에서 동작할 수 있다.
• 많은 리소스를 저장할 때에 사용될 수 있다.

reference

https://it-eldorado.tistory.com/90

https://web.dev/storage-for-the-web/

JSON Web Token의 약자로 전자 서명(어떤 데이터가 정말 그 사람의 것이 맞는지 보장해주는것) 된 속성 정보(Claim)를 JSON 데이터 구조로 표현한 토큰.

일반적으로 클라이언트와 서버, 서비스와 서비스 사이 통신 시 권한 인가(Authoriztion)를 위해 사용하는 토큰이다. URL에 대해 안전한 문자열로 구성되어 있기 때문에 HTTP 어디든 위치할 수 있다.

JWT 는 어떤 상황에서 사용될까?

다음과 같은 상황에서 JWT 가 유용하게 사용 될 수 있습니다:

• 회원 인증: 유저가 로그인을 하면, 서버는 유저의 정보를 기반한 토큰을 발급하여 유저에게 전달해준다. 그 후, 유저가 서버에 요청을 할 때마다 JWT를 포함하여 전달한다. 서버가 클라이언트에게 요청을 받을 때 마다, 해당 토큰이 유효하고 인증됐는지 검증을 하고, 유저가 요청한 작업에 권한이 있는지 확인한 후 작업을 처리한다.
• 정보 교류: 두 개체 사이에서 안정성있게 정보를 교환하기에 좋은 방법니다. 그 이유는, 정보가 서명(sign)이 되어 있기 때문에 정보를 보낸이가 바뀌진 않았는지, 정보가 도중에 조작되지 않았는지 검증할 수 있다.

JWT의 구조

🔹헤더(header)

Header는 토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있다.

{
  "typ": "JWT",
  "alg": "HS256"
}

• typ : 토큰의 타입
• alg : 해시 알고리즘. 해시 알고리즘은 토큰을 검증 할 때 사용되는 signature 부분에서 사용된다.

🔹내용(payload)

• 토큰에 담을 클레임(claim) 정보를 포함하고 있다.
• 여기에 담는 정보의 한 '조각'을 클레임(claim)이라고 부르고, 이는 name/valu의 한 쌍으로 이뤄져있다. 토큰에는 여러개의 클레임을 넣을 수 있다.
  • 등록된 (registered) 클레임
  • 공개 (public) 클레임
  • 비공개 (private) 클레임

🔹서명(signature)

서명(signature)은 헤더의 인코딩값과, 정보의 인코딩값을 합친 후 scret key를 포함하여 암호하되어 있다.

📚 Reference

[JWT] JSON Web Token 소개 및 구조

JWT를 소개합니다. : TOAST Meetup

JWT (JSON Web Token) 이해하기와 활용 방안 - Opennaru, Inc.

애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다.

애자일 개발 방법론은 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어 내며 그때 그때 필요한 요구를 더하고 수정하여 커다란 소프트웨어를 개발해 나가는 개발 프로세스라고 할 수 있다.

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile = 기민한, 좋은것을 빠르게 낭비없게 만드는 것) 개발을 가능하게 해주는 다양한 방법론 전체를 일컫는 말이다.

이 애자일 개발 프로세스 중 하나가 '스크럼' 인 것이다.

Scrum

• 애자일 소프트웨어 개발 방법론의 종류중 하나로 반복적이고 점진적인 개발방법
• 단기적인 계획을 단계적으로 짜는 것을 목표로하여 발생할 수 있는 오류를 최소화한다.
• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공해야 한다. 이 개발 주기를 sprint 라고 한다.

• 프로그램 개발 과정 속에서 자주 나타나는 문제들을 쉽게 해결하기 위한 방법
• 과거의 소프트웨어 개발 과정에서 발견된 설계의 노하우를 바탕으로 이후에도 재사용할 수 있기 좋은 형태로 가공하여 정리한 것

디자인 패턴은 왜 사용하는가?

알고리즘과 같이 프로그램 코드로 바로 변환될 수 있는 형태는 아니지만, 유사한 상황에서 문제를 해결할 수 있는 방안을 제시해준다.

장점

• 개발자 간의 원활한 의사소통 : 여러 디자인의 패턴의 특성을 잘 알고 있어 문제해결 시 어떤 디자인 패턴을 사용하면 좋을지 해결책을 논의 할 수 있다.
• 소프트웨어 구조 파악 용이 : 패턴의 특성을 잘 알고 있기에 어떤 디자인 패턴이 설계할 때 사용되었는지 알면 소프트웨어 전체구조를 쉽게 파악 가능
• 재사용을 통한 개발 시간 단축
• 설계 변경 요청에 대한 유연한 대처

단점

• 초기 투자 비용 부담
  

소프트웨어 아키텍처

• 시스템을 구성하는 서브 시스템, 컴포넌트와 같이 구성요소 간의 관계를 관리하는 시스템의 구조.
• 소프트웨어의 전체적인 그림을 만드는 솔루션

소프트웨어 아키텍처와 디자인 패턴의 차이점

소프트웨어와 디자인 패턴과 비슷하지만 더 넓은 범위에 속한다.

📚Reference

https://sshoreng.tistory.com/68

https://juyeop.tistory.com/28

💡 기업협업은 2차 프로젝트를 마치고 실제 기업에서 인턴으로 개발자의 업무를 경험 해 볼 수 있는 과정이다.

우리팀은 프론트엔드 7명으로 구성되었고, 부동산 서비스를 제공하는 기업인 uiti로 인턴십을 나가게 되었다.

인턴 기간

20/11/16 ~ 12/10

진행한 task

기업마다 진행되는 방식은 토이프로젝트를 진행하거나 디버깅을 하거나 각각 다른 걸로 알고 있었는데, 우리 팀의 경우에는 실제로 배포예정에 있는 스포츠 이커머스 앱 프로젝트의 페이지를 업무 분담 받아서 진행하는 형식이었다.

✅ 내가 진행한 task

• 영상 상세페이지
  • youtube url을 통해 영상을 보여주는 페이지
  • 라이브러리(React-Native-youtube)를 사용하여 페이지 구성
• 포인트 관리 페이지
• 쇼핑페이지 내에 가격,수량 컴포넌트
  • mock data를 이용해 ui 확인

기술스택

• React Native
• React
• TypeScript
• Axios
• Styled component

협업툴

• GitLab
• Teamgantt
• Yarn
• Adobe XD
  

기업협업/인턴십을 마치며

좋았던 점

• 현업은 어떤식으로 진행되는 지에 대해서 알 수 있었다. : 이전 프로젝트에서는 동기들과 실력향상을 위한 과정이었다면, 이번 인턴십은 실제 배포예정인 프로젝트에 합류되어서 생생하게 진행되는 사항들에 내가 참여하고 어떤 플로우로 프로젝트가 진행되는 지에 대해서 알 수 있었다. 아침마다 스크럼미팅을 진행하고, 담당했던 부분의 이슈에 대해서 함께 고민하고, 마무리 단계에서는 실제로 기기에서도 동작이 잘 되는지도 체크하고 피드백 했던 경험들을 할 수 있었다.
• 다양한 직군과의 커뮤니케이션을 통한 작업진행 : 내가 부여받은 업무를 진행 하면서 기획서의 의도를 파악하다가 궁금한 점에 대해서 기획자님에게 질문하고 의견을 조율해서 진행하고, 디자이너님에게 필요한 소스를 부탁드린다던가 하는 커뮤니케이션을 직접 할 수 있었다.
• 팀원들과 함께 끝까지 해결 해 낸 것 : 초기세팅을 하면서 다같이 끝까지 해내려고 밤늦게까지 함께 고생했던 기억이 난다. 세팅을 진행하면서 내가 안되는 점에 대해서 물어보고 도움을 요청했을 때 어느 고민없이 친절하게 도움을 주고 함께 해주었고, 내가 도움을 줄 수 있는 부분 또한 최선을 다해서 도움을 주려고 노력했다. 그렇게 함께 초기세팅을 온전히 마쳤을 때의 기쁨은 잊을 수 없을 것 같다.

아쉬운 점

• 어떻게든 혼자서 해결 해보려고 붙잡고 있던 일 때문에 진행사항이 조금은 느렸었다. 일을 진행 함에 있어서 막히는 부분은 스스로 해결하려고 하는 부분도 중요하지만, 진행상황에 따라서는 질문과 소통을 통해서 진행 해 나가는 방법 또한 피드백 받고 배웠다.
• 프로젝트에서 요구했던 새로운 기술 스택을 많이 적용해 보지 못했던 점. 이미 진행되고 있는 프로젝트에서 Typescript , axios 등등의 부분에서 기존에 모듈화 된 것을 적용하여 작업을 진행했는데 , 기존의 기술을 온전히 파악하고 진행 했던 것은 아니었던 것 같다.

후기

인턴십을 나가기 전에는 내가 실무에서 도움이 될 만한 일들을 할 수 있을까에 대해서 많이 고민하고 망설였었는데, 하기를 잘했다는 생각이 든다. 일단 부딪히고 경험해봐야 알 수 있는 일이 많다는 걸 배웠다.

그리고 우리가 만든 부분이 실제 배포예정이라는 점이 좋은 동기가 되어서 더욱 책임감을 가지고 일 할 수 있었고, 처음 배워는 React native를 통해서 진행해보는 일들이 어려웠지만 신기하고 흥미로웠다.

무엇보다 매일 오전 진행한 스크럼회의를 참여하면서 내 의견을 어떤식으로 명료하게 전달 할지에 대해서 많이 생각해보고 리마인드 할 수 있어서 좋았다. 작업진행 사항에 대해서 했던 일, 해야할 일, 블로킹 이슈 등을 미리 정리해서 매일 참여하였는데 그 시간이 중요하다는 생각을 하게 되었다.

개발자로 일한다는 것은 단순히 코드만 잘 짜는 것이 아니라 솔직하고 명료하게 올바른 커뮤니케이션 할 수 있는 태도도 중요하다는 것을 느끼게 된 한달이었다.

많이 부족한 상태였음에도 의견들을 존중해주시고 충분히 해낼 수 있도록 이끌어주신 사수 개발자분들과 늘 곁에서 으쌰으쌰하면서 도와주고 함께 했던 좋은 팀원들에게 정말 너무 감사하다.

• and 의 의미 ( and 연산자 )
• 좌항과 우항이 모두 true 일 때 " true "
• 둘 중 하나의 값이 false 이면 false

if(true && true){
    alert(1); 
}
                       // true

if(true && false){
    alert(2);
}
                       //false

< || >

• or 의 의미 ( or 연산자 )
• 좌항 우항중 하나라도 true 라면 " true"
• 둘 다 false 일 때 false

if(true || true){
    alert(1);
}
                       // true

if(true || false){
    alert(2);
}
                       // true

< ! >

• 부정의 의미 ( not 연산자 )
• Boolean 값을 역전시킨다

boolean 의 대체제

if(!''){
    alert('빈 문자열')
}
// 결과값 '빈 문자열' 출력됨
// '' (빈문자열은 false)

if(!undefined){
    alert('undefined');
}
// 결과값 'undefined' 출력됨
// undefined 는 false 로 간주

var a;
if(!a){
    alert('값이 할당되지 않은 변수'); 
}

if(!null){
    alert('null');
}
//결과값 'null' 출력됨
// null 은 false 로 간주

if(!NaN){
    alert('NaN');
// 결과값 'Nan' 출력됨
// Nan 은 false 로 간주

기업 협업을 진행하면서 참고 사항으로 알게 된 웹브라우저 제조사인 모질라(Mozilla) 에서 css 속성을 기술할 때 다음 과 같은 순서로 제안하고 있다는 걸 알게 되었다.

1. display -객체의 노출여부/표현방식--
2. list-style
3. position -위치/좌표--
4. float
5. clear
6. width / height -크기/여백--
7. padding / margin
8. border / background -윤곽/배경--
9. color / font -글자/정렬--
10. text-decoration
11. text-align / vertical-align
12. white-space
13. other text
14. content -내용--

위치 선정 > 윤곽 > 외곽 디테일링 > 채색 > 타이포그래피와 같이 밖에서부터 안쪽으로의 흐름이다.

참고

https://milooy.wordpress.com/2015/08/21/css-property-순서에-맞추어-깔끔히-적기/

https://www.beautifulcss.com/archives/203

어떤 라이브러리가 적합한 라이브러리 일까?

비슷한 라이브러리들이 많기 때문에 어떤 걸 써야할지 고민 될 때가 있다.

이럴때 유용한 사이트인

https://www.npmtrends.com/

이런 식으로 내가 찾아본 라이브러리의 트렌드에 대해서 파악할 수 있고, 비교도 가능한 사이트 이다.

npm을 사용하는 모듈을 추가하게 되면, 다운로드 수나 이슈, 최근 업데이트 된 날짜 등의 정보들을 비교해 볼 수 있는 유용한 사이트이다.

다운로드 수가 높거나 업데이트가 잘 되고 있는 라이브러리 일 수록 그만큼 버그에 대한 픽스도 잘 이루어지고 있어서 질이 향상된 라이브러리이기 때문에, 이런 비교를 통해서 라이브러리 선택에 도움을 줄 수 있다.

git@gitlab.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

라는 에러 메세지가 자꾸 떠서

구글링을 하다보니 새로운 ssh key를 생성하여 gitlab에 새로 등록하는 방법들을 추천해 줘서 해보았지만 똑같은 에러가 계속 발생하였고,

또 구글링을 해보니

새로운 키를 에이전트에 추가 eval “$(ssh-agent -s)” ssh-add ~/.ssh/id_rsa 출처: https://nickjoit.tistory.com/94 [nickjoIT]

라는 것을 활용해서 새로운 ssh 키를 생성하고 해보았지만 연속되는 실패가 이어졌다. 여기서 더 해지는 상황이 git을 pull 받아보려는 상황에서도 똑같은 상황이 이어져서, 아예 프로젝트를 clone 받아서 하는 방향으로 로직을 틀었다.

하지만.... 클론과정에서도

Cloning into 'highrun-v2'...
no such identity: /Users/summer/.ssh/gitlab_rsa: No such file or directory
git@gitlab.com: Permission denied (publickey,keyboard-interactive).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

또 permission denied 상황이 일어나는 것이다.

계속되는 에러에 멘붕이 와서 내가 기업협업에 나간 회사에서 일하고 계신 프론트엔트 분께 질문을 드려서 해결을 할 수 있었다 😭

오랫동안 찾아보다가 해결된 방법은

.ssh/gitlab.rsa: No such file or directory 의 명령어를 보고 캐치하신 것이다. 우리가 생성한 ssh key는 다른 이름의 파일인데 요구하는 것은 다른이름의 파일을 찾고 있어서 그런 상황이었 던 것이다.

1. 새로운 키를 생성하고
2. 그 새로운 키의 이름(keyName)을 ssh-add ~/.ssh/'생성한 keyName' 를 넣어주고

3 . 새로 생성한 ssh키를 gitlab에 등록해 준다.

**참고 https://devlog.jwgo.kr/2019/04/17/ssh-keygen-and-ssh-agent/