1. 왜 server-side rendering과 client-side rendering 중 하나를 선택해야 할까?
2. server-side rendering과 client-side rendering의 차이는 무엇인가?
3. pre-rendering은 무엇인가?
4. server-side rendering과 client-side rendering 방식 각각의 장단점은 무엇인가?
5. 어떠한 프로젝트에 어떠한 rendering 방법을 적용하여야 할까?

Rendering

사용자가 사이트에 접속하면 브라우저는 화면을 출력하기 위해 서버에 html, js 파일을 요청하여 브라우저 DOM에 그려주는데 이러한 전 과정을 렌더링이라고 한다. 즉, 렌더링 과정은 작성한 html, css, javascript 파일을 브라우저 화면으로 출력하는 과정이다. 개발자 측면에서는 웹/앱의 코드를 사용자와 상호작용할 수 있는 인터페이스인 브라우저와 사용자의 화면에 보여주게끔하는 과정이다.

여기에는 대표적으로 js 언어가 사용되고, 새로운 라이브러리나 프레임워크가 만들어지며 다양화된 웹사이트를 좀 더 효율적으로 보여주고자 만들어진 Client-side rendering, 그리고 WWW(World Wide Web)이 처음 출범했을 때 브라우저에 사용되었던 Server-side rendering의 2가지 종류가 있다. 실제로 Client-side rendering은 React에서 주로 사용되고 있고, Server-side rendering은 새로 떠오르고 있는 Next.js에서 주로 사용되고 있는 방식이다.

Rendering 방식 선택의 중요성

웹 개발자는 화면을 개발할 때 어떠한 웹 서비스를 개발할지에 따라 적절한 웹 앱 아키텍처를 설계하고 적절한 tool과 기술을 사용해야 하는데, 렌더링 종류도 그 중 하나의 결정사안이 될 수 있다. 렌더링 종류를 개발할 웹 서비스에 맞게 잘 선택해야지만, SEO 결과, 앱 성능, 사용자 경험 등의 측면에서 나쁜 결과를 초래하지 않는, 그래서 이후 추가 개발 비용이 들지 않을 수 있는 서비스를 완성할 수 있다고 생각한다.

Server-side rendering (SSR) VS Client-side rendering (CSR)

SSR

app의 코드가 server에서 process(render)되는 것이 특징이고 다음의 렌더링 과정을 거친다.

1. 유저가 브라우저의 주소창에 원하는 URL을 입력한다.
2. 해당 URL에 대한 요청 데이터가 server에 전달된다.
3. server는 front-end/브라우저에서 필요한 데이터와 css 파일과 함께 html 파일을 생성한다.
4. server는 생성한 html 파일을 브라우저의 요청에 대한 응답으로 전송한다.
5. 브라우저는 받은 html 파일을 실행하고 페이지에 표시한다.

장점

• 처음 load하는 시간이 빠르다.

  • server의 브라우저의 요청에 대한 page 응답이 rendered html 파일이기 때문에, 브라우저에서는 javascript 파일을 실행시킬 필요가 없이 바로 결과를 화면에 보여줄 수 있다.

• 검색환경최적화(SEO)에 유리하다.

  • search engine 상위 결과에 노출되려면 웹사이트는 검색엔진 웹 크롤러에 의해 readable해야 한다. 그러기 위해서 웹 사이트의 모든 정보를 텍스트 형태로 표시되어야 한다.
  • 또한 웹사이트의 response time도 랭킹에 영향을 미친다. 그러한 측면에서 client-rendered 웹사이트에 비해 server-rendered 웹사이트에 걸리는 웹크롤러의 response time이 더 빠르다.

단점

• server의 부하가 크다.

  • SSR의 특성상 server의 자원을 사용하기 때문에 많은 요청이 들어오면 느려질 수 있다.
  • 이러한 문제를 피하기 위해, 유저 수와 웹사이트 load capacity에 따라 적절한 조건의 hosting server를 선택하여야 한다.

• page의 데이터가 변하는 경우(페이지 전환)에는 그 속도가 느리다.

  • 유저가 server-rendered 페이지를 바꾸어야 하는 경우, 그 변화의 크고 작은 정도와 관련 없이 server가 다시 render하는 과정이 필요하다.

CSR

app의 코드가 사용자의 browser에 전송되어 process(render)되는 것이 특징이고 다음의 렌더링 과정을 거친다.

1. 유저가 브라우저의 주소창에 원하는 URL을 입력한다.
2. 해당 URL에 대한 요청 데이터가 server에 전달된다.
3. server는 database로부터 정보를 끌어와 JSON 등의 요청된 형태로 응답을 생성한다.
4. server는 client에 요청된 데이터를 전송한다.
5. 브라우저는 html 코드에 server로부터 얻은 데이터를 넣어 화면을 보여주고, client에 저장되어 있던 javascript를 실행하여 유저에게 페이지를 보여줄 수 있게 된다.

장점

• server의 부하가 적다.

• 처음 load 이후에는 웹사이트 rendering 속도가 빠르다.

  • 새로 변경된 부분만 client-side에서 re-render되므로 속도가 빠르다.

단점

• 초기 loading 시간이 길다.

• SEO에 불리하다.

Use Case

SSR

SEO가 중요하고 변경이 잘 없는 웹사이트의 경우에는 서버 사이드 렌더링이 가장 좋은 선택이 될 수 있다.

ex. 온라인 마켓, e-learning

CSR

변경이 잦은 dynamic 웹사이트의 경우 클라이언트 사이드 렌더링이 더 좋은 선택지가 될 수 있다.

ex. 온라인 메신저, 소셜 네트워크

SSR + CSR (함께 사용하기)

Pre-rendering

렌더링 과정을 빠르게 진행하기 위해, 브라우저에 rendering되기 전 먼저 rendering 과정을 진행하여 빠르게 화면을 보여주는 Pre-render이 있다.

해당 과정을 통해서 다음의 두 가지 이점을 얻을 수 있다.

• server response 시간이 빨라진다.

  • server에서 client로부터 요청을 받으면 바로 응답(ex. static webpage skeleton; 기본 페이지 레이아웃)을 주고 나머지 데이터를 생성하고 전송하는 동안 유저는 로딩 페이지를 보게 된다.

• SEO 랭킹을 올릴 수 있다.

  • static website element(ex. meta-data, meta-descriptions, web page structure)가 먼저 렌더링되면서 웹 크롤러가 먼저 렌더링된 데이터를 분석하고 더 높은 SEO 랭크에 올릴 수 있다.

Use Case

ex. facebook

Ref

• https://clockwise.software/blog/client-side-vs-server-side-vs-pre-rendering/

side effects란 함수의 반환 값 외에 볼 수 있는 상태/동작의 모든 변경 사항이다.
Ex.
- 콘솔에 값 로깅
- 파일 저장
- 비동기 타이머 설정
- AJAX HTTP 요청
- 함수 외부에 존재하는 일부 상태를 수정하거나 함수에 대한 인수 변경
- 난수 또는 고유한 난수 id 생성

이러한 Side effects는 Redux Middleware에서 수행될 수 있다.

대표적으로 상태에 관해 외부 Server에 http request로 받은 데이터를 fetch하여 들고오는 경우 비동기 처리를 하여야 한다.

How?

비동기 middleware 함수를 action 객체가 아니라 dispatch로 넘겨, dispatch 전에 middleware가 먼저 실행될 수 있도록 한다.

Async Data Flow

Redux Thunk Middleware

Redux의 공식 async function middleware

Configure

npm install redux-thunk

Redux Thunk Function

dispatch와 getState를 인수로 받는 함수로, 어떤 Redux store가 사용되는지 알지 못하는 채로 비동기 로직을 미리 작성할 수 있다.

Ex.

// index.js

import React from 'react'
import ReactDOM from 'react-dom'
import { Provider } from 'react-redux'
import './index.css'
import App from './App'

import './api/server'

import store from './store'
import { fetchTodos } from './features/todos/todosSlice'

store.dispatch(fetchTodos)

ReactDOM.render(
  <React.StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </React.StrictMode>,
  document.getElementById('root')
)

// store에 thunk 사용할 수 있도록 update

import { createStore, applyMiddleware } from 'redux'
import thunkMiddleware from 'redux-thunk'
import { composeWithDevTools } from 'redux-devtools-extension'
import rootReducer from './reducer'

const composedEnhancer = composeWithDevTools(applyMiddleware(thunkMiddleware))

// The store now has the ability to accept thunk functions in `dispatch`
const store = createStore(rootReducer, composedEnhancer)
export default store

// thunk function

import { client } from '../../api/client'

const initialState = []

export default function todosReducer(state = initialState, action) {
  switch (action.type) {
    // omit other reducer cases
    case 'todos/todosLoaded': {
      // Replace the existing state entirely by returning the new value
      return action.payload
    }
    default:
      return state
  }
}

// thunk function
export async function fetchTodos(dispatch, getState) {
  const response = await client.get('/fakeApi/todos')
  dispatch({ type: 'todos/todosLoaded', payload: response.todos })
}

Ref

https://redux.js.org/tutorials/fundamentals/part-6-async-logic

https://redux.js.org/tutorials/fundamentals/part-7-standard-patterns

https://redux.js.org/tutorials/fundamentals/part-8-modern-redux

Action 이벤트를 사용하여 애플리케이션 상태를 관리하고 업데이트하기 위한 패턴 및 라이브러리

• 모든 UI 프레임워크와 통합할 수 있고, React와 함께 가장 자주 사용된다.

• 독립형 JS 라이브러리이므로 UI 프레임워크가 없어도 사용 가능

왜 사용하나 ?

전역 상태가 예측 가능한 방식으로만 업데이트될 수 있도록 상태에 대한 중앙 집중식 저장소 역할을 한다.

아래의 그림과 같이 애플리케이션은 State, 현재 상태에 대한 UI인 View, 사용자의 입력에 따라 앱에서 발생하는 이벤트와 State에서의 업데이트인 Trigger로 이루어져 있는데, Redux는 공유된 상태가 있는 경우 이를 단방향 데이터 흐름으로 관리되게 함으로써, 상태 관리와 관련된 개념을 정의 및 분리하고 뷰와 상태 간의 독립성을 유지하는 규칙을 적용함으로써 코드에 더 많은 구조와 유지 관리성을 보장 받는다.

언제 사용할까 ?

공유 상태 관리를 처리하는데 도움이 되지만 배워야 할 개념과 작성해야 할 코드가 많다. 따라서 다음의 경우에 유용하다.

1. 앱의 여러 위치에서 필요한 많은 양의 애플리케이션 상태가 있다.
2. 시간 경과에 따라 앱 상태가 자주 업데이트된다.
3. 해당 상태를 업데이트하는 논리는 복잡할 수 있다.
4. 앱에 중간/큰 규모의 코드베이스가 있으며 많은 사람들이 작업할 수 있다.

요소

Action

type *필드가 있는 JS 객체로 애플리케이션에서 발생한 *이벤트

Ex.

const addTodoAction = {
  type: 'todos/todoAdded',    // (기능)/(발생 이벤트)
  payload: 'Buy milk'        // 추가 정보로 필수 아님    
}

Reducer

현재 state와 Action 객체를 수신하고 필요한 경우 상태를 업데이트하는 방법을 결정하고 새 상태를 반환하는 함수

(state, action) => newState

규칙

1. state 및 action 인수를 기반으로 새 상태 값만 계산한다.

2. 기존 state를 수정할 수 없다. (상태 불변)

   • 따라서 기존 state의 복사본을 이용해 새 값으로 복사본을 업데이트한 다음 반환하는 형태로 구현된다.

3. 비동기 논리를 수행하거나 임의의 값을 계산하거나 다른 side effect를 일으키지 않아야 한다.

   • store를 custom하기 위해 dispatch 시, middleware를 활용하여 side effect(Ex. 콘솔에 값 로깅, 파일 저장, 비동기 타이머 설정, AJAX HTTP 요청, 함수 외부의 상태 수정, 함수에 대한 인수 변경, 난수 생성)를 발생시킬 수 있다.

Ex.

const initialState = { value: 0 }

function counterReducer(state = initialState, action) {
  // Check to see if the reducer cares about this action
  if (action.type === 'counter/incremented') {
    // If so, make a copy of `state`
    return {
      ...state,
      // and update the copy with the new value
      value: state.value + 1
    }
  }
  // otherwise return the existing state unchanged
  return state
}

Store

애플리케이션의 전역 상태를 보관하는 컨테이너이자 JS 객체

기능 및 특징

Redux Store 내부에 보관된 상태를 직접 수정/변경하면 안 된다. 대신, 일반 작업 객체를 만든 다음 저장소에 작업을 보내(Action) 무슨 일이 일어났는지 알려주어 상태를 업데이트할 수 있다. 그 과정은 다음과 같다.

1. Store에 Action이 발송
2. Store는 root Reducer 함수를 실행하고 이전 상태와 Action을 기반으로 새 상태를 계산
3. Store는 UI가 새 데이터로 업데이트될 수 있도록 상태가 업데이트되었음을 Subscriber에게 알림

Ex.

import { configureStore } from '@reduxjs/toolkit'

const store = configureStore({ reducer: counterReducer })

console.log(store.getState())
// {value: 0}

Dispatch

업데이트하고 해당 state를 호출/전달하는 Redux store의 기능

Ex.

store.dispatch({ type: 'counter/incremented' })

console.log(store.getState())
// {value: 1}

Selectors

store의 state 값에서 특정 정보를 추출하는 함수

Ex.

const selectCounterValue = state => state.value

const currentValue = selectCounterValue(store.getState())
console.log(currentValue)
// 2

핵심 개념

1. Single Source of Truth

   • 전역 state는 하나의 store에 객체로써 저장되어 있다.

2. State is Read-Only

   • state를 변경하는 유일한 방법은 action을 dispatch하는 것이다.

3. Changes are Make with Pure Reducer Functions

DataFlow

초기 설정

1. Redux 저장소는 루트 감속기 기능을 사용하여 생성됩니다.
2. store는 루트 리듀서를 한 번 호출하고 반환 값을 초기 state 값으로 저장합니다.
3. UI가 처음 렌더링되면 UI 구성 요소는 Redux 스토어의 현재 상태에 액세스하고 해당 데이터를 사용하여 무엇을 렌더링할지 결정합니다. 또한 향후 매장 업데이트를 구독하여 상태가 변경되었는지 알 수 있습니다.

업데이트

1. 사용자가 버튼을 클릭하는 것과 같이 앱에서 어떤 일이 발생합니다.
2. 앱 코드는 다음과 같이 Redux 스토어에 작업을 전달합니다. dispatch({type: 'counter/incremented'})
3. store는 이전 state와 현재 state로 감속기 기능을 다시 실행 action하고 반환 값을 새 것으로 저장합니다.
4. store은 등록된 UI의 모든 부분에 상점이 업데이트되었음을 알립니다.
5. 스토어의 데이터가 필요한 각 UI 구성 요소는 필요한 상태 부분이 변경되었는지 확인합니다.
6. 변경된 데이터를 보는(dispatch) 각 구성 요소는 새 데이터로 강제로 다시 렌더링하므로 화면에 표시되는 내용을 업데이트할 수 있습니다.

React-Redux

React의 공식 Redux UI 바인딩 라이브러리

npm install react-redux

React-Redux Hook

useSelector

React 구성 요소가 Redux store에서 데이터를 읽을 수 있게 해줌 (Redux store -> React element)

• 선택자를 인수로 가짐

• 선택자는 전체 Redux 상태를 인수로 사용하고 상태에서 일부 값을 읽고 해당 결과를 반환하는 함수

• 자동으로 Redux store를 구독하고 action이 생길 때마다 useSelector를 다시 실행한다.

• useSelector에 의해 반환된 값이 마지막으로 실행되었을 때 변경된 경우, 새로운 참조 데이터(===)가 다시 렌더링되도록 한다.

  • 배열 state인 경우 성능적인 문제가 있을 수 있다. 따라서 React.memo()를 wrapping하여 실제로 상태가 변경되었을 때만 재렌더링하거나, 배열에서 id 배열만 읽도록 하고 해당 id를 props로 전달하는 방법이 있다(* 참조).

• 한 Component에서 여러 개의 useSelector를 호출할 수 있다.

Ex.

import React from 'react'
import { useSelector } from 'react-redux'
import TodoListItem from './TodoListItem'

const selectTodos = state => state.todos            // 선택자

const TodoList = () => {
  const todos = useSelector(selectTodos)

  // since `todos` is an array, we can loop over it
  const renderedListItems = todos.map(todo => {
    return <TodoListItem key={todo.id} todo={todo} />
  })

  return <ul className="todo-list">{renderedListItems}</ul>
}

export default TodoList

Ex * .

import React from 'react'
import { useSelector, shallowEqual } from 'react-redux'
import TodoListItem from './TodoListItem'

const selectTodoIds = state => state.todos.map(todo => todo.id)

const TodoList = () => {
  const todoIds = useSelector(selectTodoIds, shallowEqual)

  const renderedListItems = todoIds.map(todoId => {
    return <TodoListItem key={todoId} id={todoId} />
  })

  return <ul className="todo-list">{renderedListItems}</ul>
}

import React from 'react'
import { useSelector, useDispatch } from 'react-redux'

import { availableColors, capitalize } from '../filters/colors'

const selectTodoById = (state, todoId) => {
  return state.todos.find(todo => todo.id === todoId)
}

// Destructure `props.id`, since we only need the ID value
const TodoListItem = ({ id }) => {
  // Call our `selectTodoById` with the state _and_ the ID value
  const todo = useSelector(state => selectTodoById(state, id))
  const { text, completed, color } = todo

  const dispatch = useDispatch()

  const handleCompletedChanged = () => {
    dispatch({ type: 'todos/todoToggled', payload: todo.id })
  }

  // omit other change handlers
  // omit other list item rendering logic and contents

  return (
    <li>
      <div className="view">{/* omit other rendering output */}</div>
    </li>
  )
}

export default TodoListItem

useDispatch

Component에서 Redux store로 action을 dispatch하여 그 결과를 제공함 (Redux store <- React element)

• 실제 store.dispatch 함수를 반환한다.

Ex.

import React, { useState } from 'react'
import { useDispatch } from 'react-redux'

const Header = () => {
  const [text, setText] = useState('')
  const dispatch = useDispatch()

  const handleChange = e => setText(e.target.value)

  const handleKeyDown = e => {
    const trimmedText = e.target.value.trim()
    // If the user pressed the Enter key:
    if (e.key === 'Enter' && trimmedText) {
      // Dispatch the "todo added" action with this text
      dispatch({ type: 'todos/todoAdded', payload: trimmedText })
      // And clear out the text input
      setText('')
    }
  }

  return (
    <input
      type="text"
      placeholder="What needs to be done?"
      autoFocus={true}
      value={text}
      onChange={handleChange}
      onKeyDown={handleKeyDown}
    />
  )
}

export default Header

Store Provider

React-Redux hook가 올바른 Redux store를 찾는 위치와 방법으로, Component에서 사용하려는 store를 React-Redux에 알려주어 React Component에서 store를 사용할 수 있도록 한다.

• Component에 Redux store를 props로 가진 를 전달한다.

Ex.

import React from 'react'
import ReactDOM from 'react-dom'
import { Provider } from 'react-redux'

import App from './App'
import store from './store'

ReactDOM.render(
  // Render a `<Provider>` around the entire `<App>`,
  // and pass the Redux store to as a prop
  <React.StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </React.StrictMode>,
  document.getElementById('root')
)

React-Redux Patterns

• Global State -> Redux Store

• 로컬한 Component State -> React Component

• edit의 과정에서가 아니라 edit 완료 후 state를 store에 update한다.

• useSelector를 여러 번 호출하여, store의 가능한 가장 작은 state를 return 하라.

• 성능을 위해 ID로 목록 항목에서 데이터를 선택하라.

Ref

https://redux.js.org/tutorials/fundamentals/part-1-overview

https://redux.js.org/tutorials/fundamentals/part-2-concepts-data-flow#reducers

state, action, reducer https://redux.js.org/tutorials/fundamentals/part-3-state-actions-reducers

store { enhancer , middleware } https://redux.js.org/tutorials/fundamentals/part-4-store

ui https://redux.js.org/tutorials/fundamentals/part-5-ui-react

함수 Component에서 React state와 생명주기 기능을 연동(hook into)할 수 있게 해주는 함수

Hook은 React 버전 16.8부터 새로운 요소로 추가되어, 기존의 React 컨셉을 대체하지 않으면서도 React의 props, state, context, refs, lifecycle 개념에 좀 더 직관적인 API를 제공한다.

기존 React는 Component 간 재사용이 가능한 로직을 붙이는 방법을 제공하지 않는다. Hook을 통해 기존의 계층의 변화 없이(Class 없이) 상태 관련 로직을 재사용할 수 있게 되어 상태 값 관리가 보다 편리해진다. 그래서 class 내에서는 동작하지 않는다.

Hook 규칙

1. 최상위에서만 Hook을 호출해야 한다. 반복문, 조건문, 중첩된 함수 내에서 Hook을 실행하지 말라.

• 이를 통해 컴포넌트가 렌더링 될 때마다 항상 동일한 순서로 Hook이 호출되는 것이 보장되면서, useState와 useEffect가 여러 번 호출되는 중에도 Hook의 상태가 올바르게 유지된다.

2. React 함수 Component 내에서만 (혹은 Custom Hook에서) Hook을 호출해야 한다. 일반 JavaScript 함수에서는 Hook을 호출해서는 안 된다.

• 이를 통해 컴포넌트의 모든 상태 관련 로직을 소스코드에서 명확하게 보이도록 할 수 있다.

ESLint 플러그인

Hook의 2가지 규칙을 강제하는 플러그인으로 Create React App에 기본적으로 포함되어 있다.

설치 방법

npm install eslint-plugin-react-hooks --save-dev

Hook API

State Hook: useState

state를 함수 Component 안에서 사용할 수 있게 해준다.

const [count, setCount] = useState(0);

• 현재의 state 값과 이 값을 업데이트하는 함수를 쌍으로 반환한다.

• 초기 state는 첫 번째 렌더링에서만 사용된다.

• state는 Class Component에서와 달리 객체일 필요가 없고, 숫자나 문자 타입을 가질 수 있다.

Effect Hook: useEffect

React Component 안에서 데이터를 가져 오거나 구독하고, DOM을 직접 조작하는 등의 side effects를 수행할 수 있게 한다.

 const [count, setCount] = useState(0);

  // componentDidMount, componentDidUpdate와 비슷합니다
  useEffect(() => {
    // 브라우저 API를 이용해 문서의 타이틀을 업데이트합니다
    document.title = `You clicked ${count} times`;
  });

• React DOM을 바꾼 뒤에 useEffect 함수가 실행된다.

Clean-up을 이용하지 않는 Side-effects

Ex.

• 네트워크 리퀘스트
• DOM 수동 조작
• 로깅

아래의 같은 코드를 비교해보자.

i. Class Component

class Example extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 0
    };
  }

  componentDidMount() {
    document.title = `You clicked ${this.state.count} times`;
  }
  componentDidUpdate() {
    document.title = `You clicked ${this.state.count} times`;
  }

  render() {
    return (
      <div>
        <p>You clicked {this.state.count} times</p>
        <button onClick={() => this.setState({ count: this.state.count + 1 })}>
          Click me
        </button>
      </div>
    );
  }
}

ii. 함수 Component

import React, { useState, useEffect } from 'react';

function Example() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

ii.의 경우의 useEffect는 React Component의 모든 렌더링(DOM 업데이트를 수행한; 마운트 + 업데이트) 이후에 수행된다.

Clean-up이 필요한 Side-effects

Ex. 구독(subscription)을 설정해야 하는 경우에는 메모리 누수가 발생하지 않도록 정리가 필요하다.

i. Class Component

class FriendStatus extends React.Component {
  constructor(props) {
    super(props);
    this.state = { isOnline: null };
    this.handleStatusChange = this.handleStatusChange.bind(this);
  }

  componentDidMount() {
      document.title = `You clicked ${this.state.count} times`;
    ChatAPI.subscribeToFriendStatus(
      this.props.friend.id,
      this.handleStatusChange
    );
  }
  componentDidUpdate(prevProps) {
    // 이전 friend.id에서 구독을 해지합니다.
    ChatAPI.unsubscribeFromFriendStatus(
      prevProps.friend.id,
      this.handleStatusChange
    );
    // 다음 friend.id를 구독합니다.
    ChatAPI.subscribeToFriendStatus(
      this.props.friend.id,
      this.handleStatusChange
    );
  }
  componentWillUnmount() {
    ChatAPI.unsubscribeFromFriendStatus(
      this.props.friend.id,
      this.handleStatusChange
    );
  }
  handleStatusChange(status) {
    this.setState({
      isOnline: status.isOnline
    });
  }

  render() {
    if (this.state.isOnline === null) {
      return 'Loading...';
    }
    return this.state.isOnline ? 'Online' : 'Offline';
  }
}

ii. 함수 Component

function FriendStatusWithCounter(props) {
  const [count, setCount] = useState(0);
  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });

  const [isOnline, setIsOnline] = useState(null);
  useEffect(() => {
    function handleStatusChange(status) {
      setIsOnline(status.isOnline);
    }

    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
    };
  });
  // ...
}

• i. 과 다르게 ii.에서는 업데이트를 위한 특별한 추가 코드가 필요하지 않다.

최적화: 불필요한 re-rendering 방지

i. Class Component

componentDidUpdate(prevProps, prevState) {
  if (prevState.count !== this.state.count) {
    document.title = `You clicked ${this.state.count} times`;
  }
}

ii. 함수 Component

** useEffect 두 번째 인자로 배열로써** 전달하면, 배열에 해당하는 값들이 동일하다면 useEffect를 건너뛴다.

useEffect(() => {
  document.title = `You clicked ${count} times`;
}, [count]); // count가 바뀔 때만 effect를 재실행합니다.

심화: useReducer

상태를 관리할 때 컴퍼넌트의 상태 업데이트 로직을 컴포넌트에서 분리시킬 수 있다.

i. useState

mport React, { useState } from 'react';

function Counter() {
  const [number, setNumber] = useState(0);

  const onIncrease = () => {
    setNumber(prevNumber => prevNumber + 1);
  };

  const onDecrease = () => {
    setNumber(prevNumber => prevNumber - 1);
  };

  return (
    <div>
      <h1>{number}</h1>
      <button onClick={onIncrease}>+1</button>
      <button onClick={onDecrease}>-1</button>
    </div>
  );
}

export default Counter;

ii. useReducer

import React, { useReducer } from 'react';

function reducer(state, action) {
  switch (action.type) {
    case 'INCREMENT':
      return state + 1;
    case 'DECREMENT':
      return state - 1;
    default:
      return state;
  }
}

function Counter() {
  const [number, dispatch] = useReducer(reducer, 0);

  const onIncrease = () => {
    dispatch({ type: 'INCREMENT' });
  };

  const onDecrease = () => {
    dispatch({ type: 'DECREMENT' });
  };

  return (
    <div>
      <h1>{number}</h1>
      <button onClick={onIncrease}>+1</button>
      <button onClick={onDecrease}>-1</button>
    </div>
  );
}

export default Counter;

useRef

용도

1. Component 안에서 조회/수정할 수 있는 변수 관리하는 경우(setTimeout, setInterval을 통해 만들어진 id, 외부 라이브러리를 사용하여 생성된 인스턴스, scroll 위치)에 사용한다.
   • useState와 달리 useRef로 관리하는 변수는 값이 바뀐다고 해서 컴포넌트가 리렌더링되지 않는다.
2. 직접 DOM을 선택해야 하는 경우(특정 엘리먼트 크기를 가져올 때, 스크롤바 위치를 가져오거나 설정할 때, 포커스를 설정할 때) React에서는 ref를 사용하는데 Hook 함수로는 useRef가 존재한다.

사용 방식

1. useRef()를 이용하여 ref 객체를 만든다.
2. 선택하고 싶은 DOM에 ref 값으로 설정해준다.
3. 그러면 ref 객체의 .current 값이 우리가 원하는 DOM을 가르킨다.

Ex1.

import React, { useRef } from 'react';
import UserList from './UserList';

function App() {
  const users = [
    {
      id: 1,
      username: 'velopert',
      email: 'public.velopert@gmail.com'
    },
    {
      id: 2,
      username: 'tester',
      email: 'tester@example.com'
    },
    {
      id: 3,
      username: 'liz',
      email: 'liz@example.com'
    }
  ];

  const nextId = useRef(4);
  const onCreate = () => {
    // 나중에 구현 할 배열에 항목 추가하는 로직
    // ...

    nextId.current += 1;
  };
  return <UserList users={users} />;
}

export default App;

Ex2. 초기화 버튼을 누르면 이름 input에 포커스가 잡힘

import React, { useState, useRef } from 'react';

function InputSample() {
  const [inputs, setInputs] = useState({
    name: '',
    nickname: ''
  });
  const nameInput = useRef();

  const { name, nickname } = inputs; // 비구조화 할당을 통해 값 추출

  const onChange = e => {
    const { value, name } = e.target; // 우선 e.target 에서 name 과 value 를 추출
    setInputs({
      ...inputs, // 기존의 input 객체를 복사한 뒤
      [name]: value // name 키를 가진 값을 value 로 설정
    });
  };

  const onReset = () => {
    setInputs({
      name: '',
      nickname: ''
    });
    nameInput.current.focus();
  };

  return (
    <div>
      <input
        name="name"
        placeholder="이름"
        onChange={onChange}
        value={name}
        ref={nameInput}
      />
      <input
        name="nickname"
        placeholder="닉네임"
        onChange={onChange}
        value={nickname}
      />
      <button onClick={onReset}>초기화</button>
      <div>
        <b>값: </b>
        {name} ({nickname})
      </div>
    </div>
  );
}

export default InputSample;

useMemo

성능 최적화를 위해 연산된 값을 재사용할 때 사용한다.

사용 방식

useMemo((값을 어떻게 연산할지 정의하는 함수), (배열));

사용 예시

다음은 useMemo를 사용하지 않는 것과 사용했을 때의 차이를 보여주는 예시 코드이다. useMemo를 사용하게 되면 useMemo의 두 번째 인자로 넣은 배열의 내용이 바뀌면 첫 번째 인자로 등록한 함수를 호출해 값을 연산하고, 내용이 바뀌지 않았다면 이전에 연산한 값을 재사용한다.

import React, { useRef, useState } from 'react';
import UserList from './UserList';
import CreateUser from './CreateUser';

function countActiveUsers(users) {
  console.log('활성 사용자 수를 세는중...');
  return users.filter(user => user.active).length;
}

function App() {
  const [inputs, setInputs] = useState({
    username: '',
    email: ''
  });
  const { username, email } = inputs;
  const onChange = e => {
    const { name, value } = e.target;
    setInputs({
      ...inputs,
      [name]: value
    });
  };
  const [users, setUsers] = useState([
    {
      id: 1,
      username: 'velopert',
      email: 'public.velopert@gmail.com',
      active: true
    },
    {
      id: 2,
      username: 'tester',
      email: 'tester@example.com',
      active: false
    },
    {
      id: 3,
      username: 'liz',
      email: 'liz@example.com',
      active: false
    }
  ]);

  const nextId = useRef(4);
  const onCreate = () => {
    const user = {
      id: nextId.current,
      username,
      email
    };
    setUsers(users.concat(user));

    setInputs({
      username: '',
      email: ''
    });
    nextId.current += 1;
  };

  const onRemove = id => {
    // user.id 가 파라미터로 일치하지 않는 원소만 추출해서 새로운 배열을 만듬
    // = user.id 가 id 인 것을 제거함
    setUsers(users.filter(user => user.id !== id));
  };
  const onToggle = id => {
    setUsers(
      users.map(user =>
        user.id === id ? { ...user, active: !user.active } : user
      )
    );
  };
  const count = countActiveUsers(users);
  return (
    <>
      <CreateUser
        username={username}
        email={email}
        onChange={onChange}
        onCreate={onCreate}
      />
      <UserList users={users} onRemove={onRemove} onToggle={onToggle} />
      <div>활성사용자 수 : {count}</div>
    </>
  );
}

export default App;

import React, { useRef, useState, useMemo } from 'react';
import UserList from './UserList';
import CreateUser from './CreateUser';

function countActiveUsers(users) {
  console.log('활성 사용자 수를 세는중...');
  return users.filter(user => user.active).length;
}

function App() {
  const [inputs, setInputs] = useState({
    username: '',
    email: ''
  });
  const { username, email } = inputs;
  const onChange = e => {
    const { name, value } = e.target;
    setInputs({
      ...inputs,
      [name]: value
    });
  };
  const [users, setUsers] = useState([
    {
      id: 1,
      username: 'velopert',
      email: 'public.velopert@gmail.com',
      active: true
    },
    {
      id: 2,
      username: 'tester',
      email: 'tester@example.com',
      active: false
    },
    {
      id: 3,
      username: 'liz',
      email: 'liz@example.com',
      active: false
    }
  ]);

  const nextId = useRef(4);
  const onCreate = () => {
    const user = {
      id: nextId.current,
      username,
      email
    };
    setUsers(users.concat(user));

    setInputs({
      username: '',
      email: ''
    });
    nextId.current += 1;
  };

  const onRemove = id => {
    // user.id 가 파라미터로 일치하지 않는 원소만 추출해서 새로운 배열을 만듬
    // = user.id 가 id 인 것을 제거함
    setUsers(users.filter(user => user.id !== id));
  };
  const onToggle = id => {
    setUsers(
      users.map(user =>
        user.id === id ? { ...user, active: !user.active } : user
      )
    );
  };
  const count = useMemo(() => countActiveUsers(users), [users]);
  return (
    <>
      <CreateUser
        username={username}
        email={email}
        onChange={onChange}
        onCreate={onCreate}
      />
      <UserList users={users} onRemove={onRemove} onToggle={onToggle} />
      <div>활성사용자 수 : {count}</div>
    </>
  );
}

export default App;

useCallback

특정 함수를 재사용하며 성능 최적화

사용 방식

useCallback((재사용 함수), (함수에 필요한 값들이 포함된 배열));

Ref

https://ko.reactjs.org/docs/hooks-overview.html

https://ko.reactjs.org/docs/hooks-state.html

https://ko.reactjs.org/docs/hooks-effect.html

https://ko.reactjs.org/docs/hooks-rules.html

https://ko.reactjs.org/docs/hooks-reference.html#usecontext

https://react.vlpt.us/basic/10-useRef.html

https://react.vlpt.us/basic/17-useMemo.html

처리해야 할 이벤트도 다양해지고, 관리해야할 상태 값이나 DOM의 구조도 다양해지게 된다면 이에 따라 처리해야하는 업데이트 규칙도 복잡해진다.

리액트는 이러한 문제점을 개선하기 위해 아래와 같은 방법을 사용한다.

View에서 어떠한 상태가 바뀌었을 때 그 상태에 따라 DOM을 어떻게 업데이트 할지를 정하는 것이 아니라, 아예 View를 다 날려버리고 새로 보여주면 코드가 난잡해지는 것을 방지할 수 있지 않을까, 하는 아이디어에서 리엑트가 탄생했다.

SPA (Single Page Application)

사용자가 한 페이지의 머무르면서 새로운 페이지로 바뀔 때 마다 필요한 정보만 추가적으로 받아와 부분적으로 업데이트한다.

• 첫 화면 로딩 시간이 다소 길다는 점이 있다.
• 라우팅에 따라 다른 뷰를 보여줄 수 있다.

가상 돔(Virtual DOM)

DOM을 추상화한 가상의 객체로, 브라우저에 실제로 보여지는 DOM이 아니라 단순히 메모리에 가상으로 존재하는 DOM으로서, 단순한 Javascript객체이기 때문에 작동 성능이 브라우저에서 DOM을 보여주는 것보다 속도가 훨씬 빠르다.

일반적인 브라우저 렌더링 과정으로는

1. HTML 파싱 -> DOM 객체 생성 -> CSS 파싱 -> 스타일 규칙 생성
2. 위의 과정을 합쳐 실제로 웹 브라우저에 보여줘야 할 'render tree' 를 만든다.
3. 이 렌더 트리 기준으로 레이아웃을 배치하고 Paint의 작업을 한다.

이 과정에서 변경될 구성 요소가 바뀌면 전체가 렌더링이 되는데 매우 비효율적이라고 볼 수 있다. 그래서 리액트를 사용하는 이유 중 하나가 바로 Virtual DOM 이다. 리액트는 상태가 업데이트 되면 Virtual DOM은 기존 DOM과 변경될 Virtual DOM의 차이를 판단하고 변경된 구성요소만 찾아 그 부분만 렌더링을 한다.

diffing 알고리즘

위에 설명한 Virtual DOM과 관련이 크다. 변경된 부분만 감지해서 바뀐 부분만 업데이트 하는 방식을 취하게 되는데 이 변경된 부분을 감지하는 것을 diffing Algorihm 이라고 한다. 일반적인 트리 구조의 비교는 O(n^3)의 시간이 소요된다고 한다. 하지만 리액트는 이러한 diffing 알고리즘으로 인해 O(n)의 시간에 해결하고 있다.

key를 사용하는 이유

이것 또한 Virtual DOM과 diffing 알고리즘과 연관이 있다. 하나의 JSX 태그는 자바스크립트 객체로 구성되는데 이 객체에는 해당 객체가 Virtual DOM의 요소임을 확인해주는 심볼값과 각각의 Virtual DOM를 고유하게 구분하는 key 값이 들어가게 된다.

그래서 map 을 사용했을 때, 해당 리스트에 고유한 key값을 넣어줘야한다. 리액트는 이 key들의 비교를 통해 리스트의 요소가 추가되거나 삭제되었을 때 상태를 빠르게 감지하고 반영할 수 있다.

쉽게 말해 엘리먼트 혹은 컴포넌트의 변화를 감지하기 위함이고 이는 효율적인 DOM 사용으로 귀결된다.

환경세팅

Webpack

최신 프런트엔드 프레임워크에서 가장 많이 사용되는 모듈 번들러(Module Bundler)

모듈 번들러

웹 애플리케이션을 구성하는 자원(HTML, CSS, Javscript, Images 등)을 모두 각각의 모듈로 보고 이를 조합해서 병합된 하나의 결과물을 만드는 도구를 의미합니다

사용하는 이유

• 파일 단위의 자바스크립트 모듈 관리의 필요성
• 웹 개발 작업 자동화 도구
• 웹 애플리케이션의 빠른 로딩 속도와 높은 성능

Prettier

협업을 하게 될 때, 일관성 있는 코드 스타일은 정말 중요하다. 그래서 일관성 있는 코드 스타일 규칙만 설정해주면 알아서 자동으로 그 규칙에 맞게 코드들을 정리해준다.

Babel

최신 문법을 브라우저가 이해할 수 있는 자바스크립트로 통역 브라우저는 JSX를 이해하지 못한다. 그러니 바벨이라는 통역사로 JSX -> Javascript

Eslint

ESLint가 코드 퀄리티를 일관적으로 유지 문법 에러를 잡아주거나 더 좋은 코드 구현 방식을 사용하도록 해준다.

Ref

https://narup.tistory.com/183

https://velog.io/@leemember/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EA%B8%B0%EC%88%A0-%EB%A9%B4%EC%A0%91-%EB%8B%A8%EA%B3%A8-%EA%B0%9C%EB%85%90%EB%93%A4-%EC%A0%95%EB%A6%AC-%EB%A6%AC%EC%95%A1%ED%8A%B8-%ED%8E%B8

화면을 이루는 '요소'로 여러 곳에서 재사용 가능한 UI 코드 조각

React를 사용할 때 Component는 class나 function으로 정의할 수 있다.

• Component의 이름은 항상 대문자로 시작한다.

• 코드의 재사용성과 유지보수성을 증가시켜 준다.

• 데이터의 단방향성

  • 데이터는 아래로 흐른다.
  • 부모 Component는 자식 Component가 어떤 상태인지 알 수 없고 관심을 가지지 않는다.
  • state가 소유하고 설정한 Component 이외에는 어떠한 Component에서도 접근할 수 없다.
  • Component가 자신의 state를 자식 Component에 props로 전달할 수 있다.

Component와 Props

Props

속성을 나타내는 데이터로 Property의 준말

• 부모 Component에서 자식 Component로 전달해 준 데이터

Props를 개체로 받는 Component의 예시는 다음과 같다.

Ex. Class Component

import React from 'react'
class Welcome extends React.Component {
  render() {
    return <h1>Hello, {this.props.name}</h1>;
  }
}

Ex. Function Component

function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

props는 읽기 전용이다.

따라서 Component에서 자체 props를 수정할 수 없다. 즉, 모든 React Component는 자신의 props를 다룰 때 반드시 자신의 입력값을 바꾸지 않는 순수 함수처럼 동작해야 한다.

Component Rendering

React Element는 DOM 태그와 사용자 정의 Component 모두로 나타낼 수 있다. React가 사용자 정의 Component로 작성한 Element를 발견하면 JSX 속성과 자식을 해당 Component에 단일 객체로 전달하는데, 이를 Props라 한다.

Ex.

const element = <Welcome name="Sara" />;

Component 합성 / 추출

Component는 자신의 출력에 다른 Component를 참조할 수 있다.

Ex.

function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

function App() {
  return (
    <div>
      <Welcome name="Sara" />
      <Welcome name="Cahal" />
      <Welcome name="Edite" />
    </div>
  );
}

또한 Component를 여러 개의 작은 Component로 나눌 수 있다.

State

한 Component 내에서 완전히 제어되는 상태 (local/캡슐화) 를 나타내고 동적인 데이터를 다룰 때 사용

• constructor가 아니라면 직접 State를 수정하지 않고 대신 setState()를 사용한다. 직접 state를 수정하는 경우, component가 다시 렌더링되지 않는다.

    // Wrong
    this.state.comment = 'Hello';
    // Correct
    this.setState({comment: 'Hello'});

• state 업데이트는 비동기적일 수 있으므로 객체보다는 함수를 인자로 사용하는 형태의 setState()를 사용하자.

    // Wrong
    this.setState({
          counter: this.state.counter +     this.props.increment,
    });
    // Correct
    this.setState((state, props) => ({
          counter: state.counter + props.increment
    }));

• state 업데이트는 병합된다. 즉, setState()를 호출할 때, React는 제공한 객체를 현재 state로 병합한다. 따라서 여러 번의 setState() 호출로 여러 변수를 독립적으로 업데이트할 수 있다.

-** Hook의 useState**로 상태를 추가해줄 수도 있다.

생명 주기와 생명 주기 메서드

Mount

Component의 instance가 생성되어 DOM 상에 삽입될 때 다음 메서드들이 순서대로 호출된다.

1. constructor()
   • instance에 이벤트 처리 메서드를 바인딩하거나 state를 초기화하는 작업이 없다면, 해당 React Component에서는 constructor를 구현하지 않아도 된다.
   • 구현하는 경우, props를 기본 constructor로 호출해야 한다.
   • constructor() 내부에서 setState()를 호출하면 안된다. component에 지역 state가 필요하다면 constructor 내에서 this.state에 초기 state 값을 할당하면 된다. 다만 여기서도 state에 props를 복사하면 안 된다.

     constructor(props) {
         super(props);
         // 여기서 this.setState()를 호출하면 안 됩니다!
         this.state = { counter: 0 };
         this.handleClick = this.handleClick.bind(this);
     }

2. static getDerivedStateFromProps()
3. render()
   • Class component 내에서 반드시 구현되어야 하는 유일한 메서드
   • component의 state를 변경하지 않고, 호출될 때마다 동일한 결과를 반환해야하며, 브라우저와 직접적으로 상호작용하지 않는다.
4. componentDidMount()
   • component가 mount된 직후 (트리에 삽입된 직후)에 호출
   • 브라우저와 상호작용하는 작업이 필요할 때 사용

업데이트

props나 state가 변경되면 업데이트가 발생한다. 이 때 component가 다시 렌더링되면서 다음 메서드들이 순서대로 호출된다.

1. static getDerivedStateFromProps()
2. shouldComponentUpdate()
3. render()
4. getSnapshotBeforeUpdate()
5. componentDidUpdate()

Unmount

component가 DOM 상에서 제거될 때 호출된다.

• componentWillUnmount()

오류 처리

자식 컴포넌트를 렌더링하거나, 자식 컴포넌트가 생명주기 메서드를 호출하거나, 또는 자식 컴포넌트가 생성자 메서드를 호출하는 과정에서 오류가 발생했을 때 호출된다.

• static getDerivedStateFromError()
• componentDidCatch()

State와 생명주기 사용 예시

class Clock extends React.Component {
  constructor(props) {
    super(props);
    this.state = {date: new Date()};
  }

  componentDidMount() {
    this.timerID = setInterval(
      () => this.tick(),
      1000
    );
  }

  componentWillUnmount() {
    clearInterval(this.timerID);
  }

  tick() {
    this.setState({
      date: new Date()
    });
  }

  render() {
    return (
      <div>
        <h1>Hello, world!</h1>
        <h2>It is {this.state.date.toLocaleTimeString()}.</h2>
      </div>
    );
  }
}

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(<Clock />);

Ref

https://ko.reactjs.org/docs/react-component.html

https://ko.reactjs.org/docs/components-and-props.html

https://ko.reactjs.org/docs/state-and-lifecycle.html

https://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/

React 앱의 가장 작은 단위로, 화면에 표시할 내용을 기술한다.

Element Rendering

DOM에 element 렌더링하기

브라우저의 DOM element와 달리 React element는 일반 객체이며 쉽게 생성할 수 있다. React DOM은 React element와 일치하도록 매번 DOM을 업데이트한다.

React 프로젝트를 생성하면 html 파일 중 다음의 코드가 존재한다.

<div id="root"></div>

위의 코드는 root DOM 노드로, 해당 노드 안에 들어가 있는 모든 element들은 React DOM에서 관리한다. React로 구현된 애플리케이션은 일반적으로 하나의 root DOM 노드가 존재하는데, 경우에 따라 여러 독립된 root DOM 노드가 존재할 수 있다.

React element를 렌더링하기 위해서는 다음의 코드와 같이, DOM element를 ReactDOM.createRoot()에 전달한 다음, React element를 root.render()에 전달해야 한다.

const root = ReactDOM.createRoot(
  document.getElementById('root')
);
const element = <h1>Hello, world</h1>;
root.render(element);

렌더링된 element 업데이트하기

React element는 특정 시점의 UI를 보여주는 불변 객체이기 때문에, element를 생성한 이후에는 해당 element의 children이아 attribute를 변경할 수 없다.

따라서 UI를 업데이트하는 유일한 방법은 새로운 element를 생성하고 이를 root.render()로 전달하는 것이다.

변경된 부분만 업데이트하기

React DOM은 해당 element와 그 자식 element를 이전의 element와 비교하고 DOM을 원하는 상태로 만드는데 필요한 경우에만 DOM을 업데이트한다.

Ref

https://ko.reactjs.org/docs/rendering-elements.html

JavaScript를 확장한 문법으로, 렌더링 로직을 UI 로직(이벤트가 처리되는 방식, 시간에 따라 state가 변하는 방식, 화면에 표시하기 위해 데이터가 준비되는 방식 등)과 연결하기 위해 React와 함께 사용할 것을 권장하며, React의 element를 생성하는 역할을 한다.

JSX과 표현식

JSX에 표현식 포함하기

JSX의 중괄호 안에는 유효한 모든 Javascript 표현식을 넣을 수 있다.

const name = 'Josh Perez';
const element = <h1>Hello, {name}</h1>;

JSX도 표현식이다

컴파일이 끝나면, JSX 표현식이 정규 Javascript 함수 호출이 되고 JavaScript 객체로 인식된다.

따라서 JSX를 if 구문이나 for loop 안에 사용하거나, 변수에 할당하거나, 인자로서 받아들이거나, 함수로부터 반환할 수 있다.

JSX는 주입 공격을 방지한다

React DOM은 JSX에 삽입된 모든 값을 렌더링하기 전에 Escape하므로, 애플리케이션에서 명시적으로 작성되지 않은 내용은 주입되지 않는다. 따라서 XSS(cross-site-scripting) 공격을 방지한다.

JSX는 객체를 표현한다

Babel은 JSX를 React.createElement() 호출로 컴파일한다. 다음 두 예시는 동일하다.

const element = (
  <h1 className="greeting">
    Hello, world!
  </h1>
);

const element = React.createElement(
  'h1',
  {className: 'greeting'},
  'Hello, world!'
);

Ref

https://ko.reactjs.org/docs/introducing-jsx.html

JavaScript

웹 개발 주요 언어로 웹 페이지를 대화식으로 만드는 프로그래밍 언어

• ES6 Syntax를 따름

• 클라이언트 측 스크립트 언어

  • 사용자가 웹 브라우저를 열고 웹페이지를 요청할 시 해당 요청이 웹 서버로 이동

• 폼 유효성 검사, 애니메이션 적용 및 이벤트 생성 수행

• 멀티 스레딩, 멀티 프로세싱 기능이 없음

TypeScript

Javascript 기반의 언어로 JS의 모든 기능이 있음

• 객체 지향 컴파일 & 프로그래밍 언어

  • 클래스 기반 객체를 만들 수 있고, class 기반 상속, 캡슐화, 생성자 지원

• 정적 유형 검사 제공

• TypeScript 컴파일러를 사용해 .ts 파일을 .js로 변환 및 통합

• type

  • var, let
  • type 정의 시 소문자, 대문자 구별해야 함
  • type 선언 생략 시 동적 타입 결정 (타입 추론)
  • 타입 선언 생략 + 값 할당 X -> any

Ref

JS 참조 블로그

• https://doozi0316.tistory.com/entry/JavaScript-ECMAScript%EB%9E%80-ES5%EC%99%80-ES6%EC%9D%98-%EC%B0%A8%EC%9D%B4var-const-let-%ED%99%94%EC%82%B4%ED%91%9C-%ED%95%A8%EC%88%98-class
• https://hanamon.kr/javascript-es6-%EB%AC%B8%EB%B2%95/

TS https://joshua1988.github.io/ts/why-ts.html#%ED%83%80%EC%9E%85%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EB%9E%80

var / let / const 차이 https://inpa.tistory.com/entry/JS-%F0%9F%93%9A-var-let-const-%EC%B0%A8%EC%9D%B4%EC%A0%90-%EB%B3%80%EC%88%98-%ED%98%B8%EC%9D%B4%EC%8A%A4%ED%8C%85

Spring 3.0의 @ResponseBody, 그리고 4.0부터 지원되는 @RestController를 통해 Rest API 메소드를 지원할 수 있게 되었다.

• @ResponseBody : html을 JSON 형태로 보여주는 역할

  • Method 앞에 사용하는 annotation

• @RestController = @ResponseBody + @Controller

  • Class 앞에 사용하는 annotation
  • 해당 Class 내의 모든 Method는 자동으로 @ResponseBody가 적용됨

Spring에서는 class나 method 앞에 간단한 annotation(@~)을 통해 각 class나 method가 어떤 역할을 해주는지 자동으로 정해준다.

마찬가지로 REST Controller에 대해서도 Annotation을 활용할 수 있는데 그 방법은 크게 두 가지가 있다.

I. 필요한 Controller Class 앞에 @RestController를 붙여주거나,

II. 필요한 Controller Class 앞에 @Controller를 붙여주고, 해당 Class 내의 필요한 Method 앞에는 @RequestBody를 붙여줄 수 있다.

CRUD와 REST API

CRUD = Create + Read + Update + Delete

1. Read

   • @GetMapping("/api/~")

2. Create

   • @PostMapping("/api/~")

3. Update

   • @PutMapping("/api/~") : 자원의 전체 교체

   • @PatchMapping("/api/~") : 자원의 부분 교체

       - Spring 3.2부터 지원

4. Delete

   • @DeleteMapping("/api/~")

5. 1~4의 다른 방식

   • @RequestMapping(value = "/api/~", method = RequestMethod.GET/POST... )

Endpoint 설정

위의 annotation 예시에서 공통적인 ("/api/~") 부분은 서버 상 해당 주소에 REST EndPoint를 만들어 준다.

-  (server baseURL)/api/~

PathVariable

만약 Endpoint 설정에 있어 그 주소를 다음과 같이 주게 되면 URI 경로의 일부를 parameter로 사용하는 PathVariable을 설정할 수 있다.

@RequestMapping("/api/{id}")
public String ex(@PathVariable String id) {
    ...
}

Query Parameter

Query parameter를 주고 싶다면 다음과 같이 method를 작성할 수 있다.

@RequestMapping("/api/~")
public String ex(@RequestParam(required=false) String id) {
    ...
}

• required에 대한 default 설정 값은 true이다.

RequestBody

JSON 데이터를 원하는 타입의 객체(여기서는 HashMap으로 변환해야 하는 경우 사용할 수 있다.

즉, @RequestBody는 HTTP 요청의 body를 Java 객체로 받을 수 있게 해준다.

@RequestMapping("/api/~")
public String ex(@RequestBody(required=false) HashMap<String, Object> data) {
    ...
}

• required에 대한 default 설정 값은 true이다.

• 간혹 구글링을 하다보면 @RequestBody는 @GetMapping과 함께 사용하지 못한다고 나와 있는 경우가 많은데, 이와 상관없이 Get, Post 등 모든 REST API와 사용 가능하다.
• 다만 client 측에서 request body를 전달할 수 없는 경우가 있기 때문에 RequestParameter로 대체하는 것으로 결정하는 경우가 많다.

Ref

https://rebeccacho.gitbooks.io/spring-study-group/content/chapter16.html

표준 CSS 방법론 ; CSS 클래스명을 어떻게 지으면 좋을지에 대해 정의

기본 구조

Block + Element + Modifier

• .(block 명)__(element 명)--(modifier 명)

• ID를 사용하지 않음

• Class만을 사용함

• 명명은 '어떻게 보이는가'가 아니라 '어떤 목적이냐'에 따라

• 명명 시, white space 구분은 '-' 하나로

Block

재사용 가능한 기능적으로** 독립적**인 페이지 component

Ex.

<div class="logo">

• Nested Block 허용 Ex. .(block1)>.(block2) // block이 block을 감싼 형태

Element

Block을 구성하는 단위

• 자신이 속한 Block 내에서만 의미를 가짐 (의존적)

Ex. (속한 block 명)__(element 명)

<form class="search-form">
    <input class="search-form__input"/>
    <button class="search-form__button">Search</button>
</form>

• Nested Element 허용 Ex. .block>.block______element1>.block__element2 // block 내에 element1과 element2가 위치함

• class 명에 cascading을 여러 번 표시할 필요가 없음

Ex.

<form class="search-form">
  <div class="search-form__content">
      <input class="search-form__input"/>
      <button class="search-form__button">Search</button>
  </div>
</form>

Cf.

<form class="search-form">
  <div class="search-form__content">
      <input class="search-form__content__input"/>
      <button class="search-form__content__button">Search</button>
  </div>
</form>

Modifier

Block이나 Element의 속성

Ex. (속한 block/element 명)--(modifier 명)

1. boolean type Ex. --focused

    <ul class="tab">
    <li class="tab__item tab__item--focused">탭 01</li>
    <li class="tab__item">탭 02</li>
    <li class="tab__item">탭 03</li>
    </ul>

2. key-value type Ex. --theme-normal, --color-gray

    <div class="column">
    <strong class="title">일반 로그인</strong>
    <form class="form-login form-login--theme-normal">
    <input type="text" class="form-login__id"/>
    <input type="password" class="form-login__password"/>
    </form>
    </div>
   
    <div class="column">
    <strong class="title title--color-gray">VIP 로그인 (준비중)</strong>
    <form class="form-login form-login--theme-special form-login--disabled">
      <input type="text" class="form-login__id"/>
      <input type="password" class="form-login__password"/>
      </form>
      </div>
   
   
   
   

장점

클래스 명만으로 마크업 구조를 알기 쉬움

Ref

BEM을 따른 마크업 Implementation https://nykim.work/15

Application을 Model-View-Controller의 세 가지 역할로 구분한 개발 방법론 / 소프트웨어 디자인 패턴

Design Pattern 프로그램 등 개발 중에 발생했던 문제점들에 대해 상황에 따라 간편하게 적용해서 특정한 규약으로 쉽게 쓸 수 있는 형태로 정리한 것으로 유지 보수성을 높임 Ex. MVC 패턴, Strategy 패턴, Observer 패턴 등

필요성

각 component를 분리하여 각자의 역할에 집중할 수 있게끔함으로써 유지보수성, application의 확장성, 유연성이 증가하고, 중복 코딩의 문제점이 사라짐

구조

Model

데이터와 비즈니스 로직을 관리하는 객체

• 데이터 : 내부의 상태에 대한 정보나 모델을 표현하는 이름 속성으로 DB, 상수, 초기화 값, 변수 등을 뜻함

• 모델 상태 변화 시, controller와 view에 통보하면 view는 최신의 결과를 보여주고, controller는 모델의 변화에 따른 적용 가능한 명령을 추가, 제거, 수정할 수 있음

규칙

1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
2. view나 controller에 대해서 어떠한 정보도 알지 말아야 한다.
3. 변경이 일어나면 변경 통지에 대한 처리 방법을 구현해야만 한다.

View

사용자 interface 요소

• 데이터 및 객체의 입력 및 출력을 담당; 레이아웃과 화면을 처리함

규칙

1. model이 가지고 있는 정보를 따로 저장해서는 안된다.
2. model이나 controller와 같이 다른 구성요소들을 몰라야 된다.
3. 변경이 일어나면 변경통지에 대한 처리 방법을 구현해야만 한다.

Controller

명령을 model과 view로 라우팅함 ; 사용자가 데이터를 클릭하고 수정하는 것에 대한 이벤트들을 처리하는 부분 ; model과 view를 연결해주는 역할

규칙

1. model이나 view에 대해서 알고 있어야 한다.
2. model이나 view의 변경을 모니터링해야 한다.

예시 프레임워크 / 라이브러리

React, Angular JS, Python Django

컴퓨터 프로그래밍의 패러다임으로써 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위인 객체들의 모임으로 파악하고자하는 것

• 추상화, 상속, 다형성, 다중 상속 등을 통해 프로그램을 유연하고 변경이 용이하게 만듦 EX. 역할은 interface로 구현은 이를 구현한 class/객체로 하여 역할과 구현을 분리한다.

SOLID : 좋은 객체 지향 설계의 5가지 원칙

1. Single Responsibility Principle (SRP) : 단일 책임 원칙

   • 하나의 클래스는 하나의 책임만 가진다.

2. Open / Closed Principle (OCP) : 개방 / 폐쇄 원칙

   • 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

   • cf. 기능을 추가하고자 다형성을 이용하여 클라이언트 코드를 변경하는 경우

3. Liskov Substitution Principle (LSP) : 리스코프 치환 원칙

   • 프로그램의 객체는 정확성을 깨뜨리지 않으면서 하위 타입의 instance로 바꿀 수 있어야 한다.

   • EX. 다형성에서 sub-class는 interface 규약을 모두 지켜야 함

4. Interface Segregation Principle (ISP) : 인터페이스 분리 원칙

   • 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

5. Dependency Inversion Principle (DIP) : 의존관계 역전 원칙

   • 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다.

   • 변경되기 쉬운 부분(ex. impl)이 아니라 interface와 같은 변경되기 쉽지 않은 것에 의존하도록

   • Ex. 구현 클래스가 아닌 인터페이스에 의존해야 함

Ref

SOLID와 코드 예시 https://ios-development.tistory.com/705?category=1008271

시스템의 구조(structure), 행위(behavior), 뷰(view)를 정의하는 개념 모델로, 각 컴포넌트가 어떻게 상호작용하고 정보를 교환하는지 설명한다.

목적

소프트웨어를 계층으로 나눔으로써 관심사를 분리할 수 있다.

이 때, 계층간 경계를 두어 각 Layer를 분리하고, 관심사를 분리하는데 설명한 방식이 Dependency Rule이다.

Dependency rule Software를 이루는 서로 다른 영역을 circular diagram으로 나타내었을 때, higher level일 수록 더 안쪽 circle이 되는 형태를 띤다. (outer circle : mechanism, inner circle : policy) 이 때, inner circle은 outer circle에 independent하기 때문에, outer circle의 변화는 inner circle에 영향을 주지 않는다. 반면, inner circle의 변화는 outer circle에 영향을 줄 수 있다.

중요성

이를 통해 다음과 같은 시스템을 생성할 수 있다.

1. Framework-independent한 시스템을 구축할 수 있다.

   • System Architecture는 라이브러리 존재 여부나 프레임워크에 한정적이지 않아 도구로써 사용하는 것이 가능하다.

2. 테스트가 용이하다.

   • Dependency rule을 따름으로써 Business rule이 UI, DB, 웹 서버 등 외부적인 요인들에 영향 받지 않고 테스트될 수 있다.

3. UI에 독립적이다.

   • 시스템의 다른 부분을 고려하지 않고 UI를 변경할 수 있다.

4. Db에 독립적이다.

   • DB (SQL, MongoDB, CouchDB 등)에 독립적으로 변경될 수 있고, Business rule에 얽매이지 않는다.

5. 외부 기능에 독립적이다.

   • Business rule은 외부 상황 (DB, UI)에 대해 아무것도 모른다.

Business Rule (Logic)

• 컴퓨터 프로그램에서 실세계의 규칙에 따라 데이터를 생성, 표시, 저장, 변경하는 부분
• UI (Presentation tier) 와 DB (Data tier) 사이에서 발생한 정보 교환을 위한 특정 알고리즘이나 규칙이 정의된 tier

Clean Architecture

크게 Domain, Infrastructure, 그 사이의 Adapter로 구분되어 있고 각 layer는 세분화되어 있다.

위 그림 또한 Dependecy Rule에 따라 작동하여 outer에서 inner로 의존성을 가지게 된다.

Domain

Business rule이 존재하는 영역

• 잘 변하지 않는 안정된 영역

Entities

Application에서 핵심적인 기능인 Business Rule들을 담고 있음

• Class 내의 method 들의 그룹으로 볼 수 있다.

Use Cases

특정 Application에 대한 Business Rule로써, Entity를 사용하여 시스템이 어떻게 자동화될 것인지에 대해 정의하고 Application의 행위를 결정함

• Abstract class나 interface를 정의한다.

(Interface) Adapter

Domain과 Infrastructure 사이의 경계를 관리하는 영역

Controllers

Gateways

Presenters

Infrastructure

UI, DB, web APIs, Devices,** Frameworks**, External Interfaces 등이 존재하는 영역

• Domain에 비해 자주, 쉽게 바뀔 수 있는 영역

Ref

https://k-elon.tistory.com/38

의존성 역전 원칙 (DIP) https://huisam.tistory.com/entry/DIP

Controller

주로 사용자의 요청을 처리한 후 지정된 뷰에 모델 객체를 넘겨주는 역할로 사용자의 요청이 진입하는 지점으로 요청에 따라 어떤 처리를 할지 결정을 Service에 넘겨줌

; Client의 요청을 받았을 때 그 요청에 대해 실제 업무를 수행하는 Service를 호출하고

• 클라이언트가 보낸 데이터가 있다면 호출 시 전달하기 쉽게 데이터 가공

모델의 업무 수행이 완료되면 그 결과를 바탕으로 화면을 구성하도록 View에 전달함

Service

비즈니스 로직을 수행하고 DB에 접근하는 DAO를 이용해서 결과값을 받아 와 처리한 내용을 View에 넘겨줌

; Controller의 요청을 받아 알맞은 정보를 가공하여 Controller에게 재전달

• Repository를 상속받아 관련 함수 사용이 가능

DAO (Data Access Object)

DB에 접근하기 위한 객체

• 영속성 객체를 숨기지 않음; 구현체가 인프라 계층에 있다는 것을 숨기지 않음

• 서비스와 DB를 연결하기 위한 중간 다리

• JPA는 매우 적은 코드로 DAO를 구현할 수 있도록 해줌

Repository

DB에 접근하기 위한 객체이자 객체의 상태를 관리하는 저장소로 영구 저장소가 아닌 객체의 상태를 관리하는 저장소

; Entity에 의해 생성된 DB에 접근하는 메서드를 사용하기 위한 인터페이스

• 인프라 계층이 아니라 도메인 계층
• 영속성 객체임을 숨김; 구현체가 인프라 계층에 숨겨져 있음
• JPA를 상속받음으로써 기본적인 CRUD 동작이 가능해짐

DTO (Data Transfer Object)

계층(Layer)간 데이터 교환을 위해 사용하는 객체

• 데이터 교환만을 위해 사용하므로 로직을 가지지 않고, getter/setter 메소드만 갖는다.

• 뷰에서 컨트롤러로 넘어오는 데이터를 담거나, 컨트롤러에서 서비스로 넘기는 데이터를 담거나 할 때 사용

Entity (Domain)

DB 테이블 내에 존재하는 Column만을 속성(field)로 가지는 클래스

; DB 테이블과 매핑되며 실제 DB에 저장되는 내용들을 구현하는 class (Entity Table)

• PK (id)로 구분
• 상속을 받거나 구현체여서는 안됨
• Setter를 사용하면 안됨
• 로직을 가질 수 있음

DB

VO (Value Object)

값 그 자체를 표현하는 객체

• 로직을 포함할 수 있음
• 객체의 불변성을 보장함; 객체의 정보가 변경되지 않음

+ Practice

Qvest의 oms 프로젝트 중 백엔드 task인 help.oms API를 개발하게 되면서 알게 된 점을 간단하게나마 정리한다.

CRUD 기반 REST API를 Spring으로 구현한 일반적인 형태는 다음 실습 참고 Github 소스를 참고하면 좋을 것 같다. Entity, DTO, Repository, Service, Controller(아래 소스에서는 Resource)를 비교적 잘 구분해놓았기 때문에 각각의 개념과 쓰임을 익히는데 도움이 될 것 같다.

• 실습 참고 Github 소스

다만 해당 코드가 이번 task를 진행하면서 Abstraction을 좀 더 잘 지키기 위해 작성한 코드와 조금 다른 건, Service에 대해 Service Interface와 Service 하위 Package로 Implementation(ServiceImpl)이 존재하지 않고 바로 Service Class를 구현하였다는 점 정도인 것 같다.

Ref

https://velog.io/@jybin96/Controller-Service-Repository-%EA%B0%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

https://plo-developdiary.tistory.com/m/62

극단적으로 동일한 목적 하에 동일한 기능을 수행하게끔 강제하는 것이 바로 인터페이스의 역할이자 개념이다.

interface를 이용하여 개발 코드를 직접 수정하지 않고도 사용하고 있는 객체만 변경할 수 있도록 할 수 있다. 즉 자바의 다형성을 극대화하여 개발코드 수정을 줄이고 프로그램 유지보수성을 높이기 위해 인터페이스를 사용한다.

특징

• 추상 메서드를 가진다.

• 변수를 만들면 자도응로 앞에 public static final이 생략된다.

• 인터페이스를 메모리에 로드하려면 익명 클래스를 만든다.

• 추상 method는 무조건 child가 구현해야 한다.

• 함수를 넘길 때 사용하며, class와 다르게 행위가 정해져 있지 않을 때 사용한다.

Ref

https://interconnection.tistory.com/129

Java version 1.5부터 도입된 서로 연관된 상수들의 집합인 열거형 클래스

Ex.

enum Status {
    PROCEEDING, COMPLETE;
}

=

class Status {
    public static final Status PROCEEDING = new Status();
    public static final Status COMPLETE = new Status();
}

필요성

기존의 String type의 상수는

public static final String

으로 정의하였는데, 런타임 에러 등 프로그램의 치명적인 오작동을 초래할 수 있다는 문제점을 해결하기 위해 활용한다.

이를 활용하면 코드가 단순해지며 가독성이 향상되고, instance 생성과 상속을 방지하여 컴파일 시 상수값의 type stability가 보장된다.

Ref

https://mangkyu.tistory.com/73

https://mangkyu.tistory.com/74

실시간 데이터 전송에 사용되는 HTTP 프로토콜과 WebSocket 프로토콜에 대해 알아보고 이를 비교한다. 추가적으로 SSE 기술에 대해서도 알아볼 것이다.

HTTP

기본적으로 HTTP Protocol은 비연결성의 특징을 가지기 때문에, 실시간 통신에는 적합하지 않은데 이를 구현하는 3가지 방식은 다음과 같다.

Polling

브라우저가 일정한 주기마다 서버에 HTTP request를 보내는 방식

• HTTP가 클라이언트에서 서버로만 요청이 가기 때문에 이벤트가 없어도 주기적으로 서버에 요청을 보내 업데이트가 있는지 확인하고 있다면 업데이트 시킴
• 클라이언트가 주기적으로 서버에 request를 보내므로 부담이 큼
• 실시간 데이터의 업데이트 주기는 예측 불가능하여 불필요한 요청에 따른 서버 및 네트워크의 부하가 늘어남
• time interval에 따라 서버의 부하가 커지거나 실시간성이 떨어지는 문제가 발생

<활용> 실시간성이 중요하지 않거나 time interval을 늘려 여러 대의 client와 통신할 때 사용

Long Polling

polling의 서버 부하를 줄이면서 실시간성을 높이기 위한 방식

• HTTP 요청 시 서버는 해당 연결을 바로 해제하지 않고 일정 시간 대기함. 이 동안 데이터 업데이트가 일어나면(이벤트) 바로 클라이언트에게 response를 보내고 전달 받은 데이터를 처리함. 그리고 응답을 받은 클라이언트는 서버에 다시 request를 보냄
• 응답이 와 연결이 끊기면 클라이언트가 서버에 다시 연결 request를 하므로 클라이언트의 부담이 줄어듦
• 잦은 데이터 변경이 발생하면 서버의 부담이 커짐
• 일반 polling 방식보다는 서버의 부담이 줄겠지만 데이터 업데이트가 빈번해지면 일반 polling 방식과 차이가 큰 차이가 없음

<활용> 실시간성이 필요한 적은 수의 클라이언트와 연결되어 있는 경우에 사용

Streaming

요청에 대한 응답을 완료하지 않은 상태에서 데이터를 계속 내려받는 방식으로 응답을 받더라도** 연결을 끊고 다시 request를 보내는 과정이 없고** 계속 응답을 받아 처리하는 방식

• long polling의 연결구축에 대한 부하를 해결하는 방식
• 서버는 무한정 / 일정 시간동안 클라이언트의 요청을 대기시키고 chunked 메세지를 통하여 응답 시 연결을 계속 유지함
• 클라이언트에서 서버로 데이터를 보내는 게 힘들기 때문에 실시간 양방향 통신이 아니라 실시간 단방향 통신이 주로 이뤄짐

Server Sent Event (SSE)

• EventSource 객체를 이용해 처음 한 번만 연결하면 서버가 클라이언트에게 지속적으로 데이터를 보내줌
• 클라이언트는 서버로부터 데이터만 받을 수 있음
• 접속에 문제가 있으면 자동으로 재연결을 시도하지만 클라이언트가 페이지를 닫아도 서버에서 감지하기 어려움
• HTTP/1.1의 경우 브라우저당 6개의 접속만을 허가하며 HTTP/2에서는 100개까지의 접속을 허용
• 알람과 같이 서버에서 단방향으로 보내는 이벤트들에 유리함

WebSocket

실시간 양방향 데이터 전송을 위한 기술

• ws/wss 프로토콜 사용
  • ws 프로토콜을 지원하지 않는 오래된 브라우저에서는 사용할 수 없음
  • Ex. Node.js : ws나 Socket.IO와 같은 패키지를 통해 웹 소켓 사용 가능
• Full-Duplex (전이중) 방식
• 클라이언트와 서버 간 양방향 통신이 가능
• 불필요한 요청(한 번의 요청) / 응답 헤더 데이터가 존재하지 않음
• 최초 WebSocket 연결(접속)은 Http 요청인 Handshaking을 활용
• TCP 연결임에도 Byte stream만이 아닌 UTF-8의 Text와 Binary 모두를 보낼 수 있음
• 실시간성이 강조될 때, Http보다 빠른 Websocket을 사용
• HTTP와 포트 공유가 가능하며 좋은 성능을 보여줌

정리

+ http/https VS ws/wss

http : 일반적인 http 프로토콜 https : 데이터 보안을 위해 SSL을 적용한 http 프로토콜

ws : 일반적인 ws 프로토콜 wss : 데이터 보안을 위해 SSL을 적용한 ws 프로토콜

REF

https://www.joinc.co.kr/w/man/12/websocket

Annotation 기반으로 코드를 자동완성해주는 library

필요성

getter, setter, toString 등 여러 코드의 (반복적인) 생성 없이 코드를 자동 완성시킴으로써 코드 생산성을 향상시키고, 가독성 및 유지 보수성을 향상시키고, 그 외에도 builder 패턴이나 로그 생성 등 다양한 방면으로 활용 가능하다.

REF

lombok 사용 방법 참고 https://mangkyu.tistory.com/78

Java 언어에서의 Object-Relational Mapping (ORM) 기술 표준으로 사용되는 인터페이스의 모음으로 구현된 클래스와 매핑을 해주기 위해 사용되는 프레임워크

ORM Application class와 관계형 데이터베이스 (Relational Database)의 테이블을 매핑한다는 뜻으로, 기술적으로는 application의 객체를 RDB 테이블에 자동으로 영속화해주는 것

필요성

배경 : 패러다임의 불일치

현재의 개발 언어 트렌드 : Java, Scala, Kotlin과 같은 객체 지향 언어
현재의 데이터베이스 세계 : Oracle, MySQL, PostgreSQL과 같은 RDB

> 추상화, 캡슐화, 정보은닉, 상속, 다형성 등 시스템의 복잡성을 제어할 수 있는 객체지향개발에 비해,
관계형 데이터베이스의 경우 데이터를 잘 정규화해서 저장하는 것이 목표

객체를 RDB에 관리해야 하기 때문에 개발자 입장에서는 SQL 중심적인 개발 (개발자가 객체를 SQL로 변환해서 RDB에 저장하는 변환 과정을 직접 해야 함)이 된다는 문제가 있다.

역할

JPA는 반복적인 CRUD SQL을 처리해준다. 따라서 어떤 SQL이 실행될지만 생각하면 된다.

CRUD = CREATE + READ + UPDATE + DELETE 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능

이를 통해 궁극적으로는 SQL이 아닌 객체 중심의 개발이 가능해진다는 점으로 생산성이 나아지고 유지보수도 수월해진다.

생산성 향상

JPA를 사용함으로써 지루하고 반복적인 코드를 개발자가 직접 작성하지 않아도 되고, DDL문도 자동 생성해주기 때문에 DB 설계 중심을 객체 설계 중심으로 변경할 수 있다.

유지보수성 향상

필드를 하나만 추가해도 관련 SQL문과 JDBC 코드를 전부 수정해야 하는 번거로움이 있었는데 JPA가 이를 대신 처리해준다.
DB가 변경되더라도 JPA에게 알려주면 비교적 간단하게 수정이 가능하다.

성능 향상

- Application과 DB 사이의 성능 최적화 기회를 제공한다.    
- 같은 transaction 안에서는 같은 entity를 반환하기 때문에 DB와의 통신 횟수를 줄일 수 있다.
- transaction을 commit하기 전가지 메모리에 쌓고 한번에 SQL을 전송한다.

데이터 접근 추상화와 벤더 독립성

RDB는 같은 기능이라도 벤더마다 사용법이 다르기 때문에 처음 선택한 DB에 종속되고 변경이 어려운데, JPA는 application과 DB 사이에서 추상화된 데이터 접근을 제공하기 때문에 종속이 되지 않도록 한다. 

+ JPQL (Java Persistence Query Language)

JPA에서 제공되는 SQL을 추상화한 형태의 객체 지향 쿼리 언어로 식별자를 통한 단순 조회가 아닌 추가 조건들(query)을 통해 조회를 하고자 할 때 사용

Ref

JPA, Hibernate, Spring Data JPA 차이 https://suhwan.dev/2019/02/24/jpa-vs-hibernate-vs-spring-data-jpa/

JDBC와 Hikari Connection Pool (cp) https://velog.io/@miot2j/Spring-DB%EC%BB%A4%EB%84%A5%EC%85%98%ED%92%80%EA%B3%BC-Hikari-CP-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0