🎉 berenickt 블로그에 온 걸 환영합니다. 🎉
Front
Front 로드맵

Front 로드맵

1. 네트워크과 인터넷

  • 인터넷의 탄생과 발전 과정 (일괄처리, 시분할 시스템, www 발명, 닷컴버블)
  • 웹의 변천사와 역사 (웹 1.0, 웹 2.0, 웹 3.0)
  • Ajax, Flash, 웹 대용량화, 프런트엔드와 백엔드 분리
  • 프런트엔드 개발자가 하는 일 : UI/UX 개발, 애니메이션 구현, 디버깅, 웹 사이트 성능 최적화, 테스트 코드 작성

2. HTML, CSS

  • HTML ✅

  • CSS ✅

    • 캐스케이딩 중요도, 명시도, 작성 순서, 상속

    • CSS 전처리기 : 기존 CSS를 확장 및 개선해, 기존 CSS 코드로 변환하는 도구

    • CSS 후처리기 : CSS 문법 그대로 사용하고, 필요한 확장 기능은 JS플러그인을 이용해 CSS 문법 스타일을 변환하는 도구✅

      • e.g. PostCSS - CSS로 작성된 코드를 추상구문트리(AST)로 변환 후 JS 플러그인을 사용해 CSS 스타일로 변환하는 도구
        • cf. 추상구문트리 : 코드에서 계층 구조로 정보를 추출해 트리형태로 만든 것
        • 공식문서. https://postcss.org/

    • CSS 방법론 : 전처리기, 후처리기를 사용하지 않고, 문법적인 규칙을 작성해 효율성을 개선하는 방법론

      • e.g. OOCSS : 구조와 외형의 분리, 컨테이너와 콘텐츠의 분리
      • e.g. SMACSS : 확장가능한, 모듈러방식의 아키텍처를 지원하는 방식
      • e.g. BEM : class 속성명을 각각 Block, Element, Modifier로 구분해 유지보수✅

2.1 CSS 프레임워크

3. JavaScript & TypeScript

3.1 JS 프레임워크

  • SPA : 웹페이지에서 처음 응답 시, 한 번만 HTML, CSS, JS를 받고, 다음 요청부터는 응답 데이터로 필요한 부분만 변경하는 방식
  • SSR : SPA가 검색 엔진 최적화에 불리해서, 웹페이지를 서버에서 렌더링

4. 개발도구

  • 코드 에디터
  • 버전 관리 시스템
    • 중앙집중식 버전 관리 시스템(CVCS) : 별도 서버에 시스템 구축 후, 각 파일 변경사항을 서버에 기록
    • 분산 버전 관리 시스템(DBCS) : 변경사항을 자기 컴퓨터와 서버에 동시에 기록, (e.g. Git) ✅
    • 웹 기반 버전 관리 저장소 : Github, GitLab
  • 코드 포매터 : 코드를 보기 좋게 바꿔주는 도구 (e.g. Prettier)
  • 린터 : 코드를 정적(실행하지 않고)으로 분석해, 문법적 오류가 발생한 곳을 사전에 검사하는 도구 (e.g. ESLint)
  • 패키지 매니저 : 패키지를 관리하는 작업을 자동화하고 안전하게 처리해주는 도구 (e.g. npm, yarn, pnpm)
  • 모듈 번들러 : JS 파일 여러 개를 웹 브라우저에서 실행할 수 있는 하나의 파일로 묶어주는 도구

5. 네트워크 통신

  • OSI 7계층, TCP/IP 4계층
  • 주요 프로토콜
    • 이더넷 : 데이터를 전송하기 위한 표준화된 방식을 제공 (e.g. LAN, MAC 주소) - (TCP/IP 1계층, 네트워크 계층)
      • IP 주소 : 최종 목적지를 나타내는 주소
      • MAC 주소 : 해당 기기와 물리적으로 연결된 장치와 통신할 떄 사용하는 주소 - (TCP/IP 2계층, 인터넷 계층)
    • IP : 데이터를 패킷(packet)이란 작은 단위로 분할해서 전송
    • TCP : 3-way Handshake, 4-way Handshake - (TCP/IP 3계층, 전송 계층)
      • 3-way Handshake : 두 장치 간 연결 시, 3단계를 거쳐 설정 (연결 요청(SYN) → 연결 응답(SYN ACK) → 응답 확인(ACK) )
      • 4-way Handshake : 연결을 끊을 떄, 4단계를 거쳐 연결을 종료 (종료 요청(FIN) → 요청 확인(ACK) → 종료 준비 완료(FIN) → 종료(ACK) )
    • UDP : TCP가 연결형, UDP는 비연결형으로 두 장치 간 연결을 하지 않고 데이터를 전송 (TCP/IP 3계층, 전송 계층)
      • 그래서 연결설정이 안해도 되서, TCP보다 빠르지만,
      • TCP와 같은 흐름 제어 및 혼잡 제어가 불가능, 즉 데이터 전송의 신뢰성을 보장하지 못함
      • UDP는 신뢰성있는 데이터 전송보다 속도가 중요한 인터넷 전화, 멀티미디어 스트리밍, 온라인 게임 등에 주로 사용
    • QUIC : 2000년대까지 전송 계층에 TCP, UDP만 있었지만, 구글이 만듬
      • TCP의 신뢰성과 UDP의 속도를 합친 새로운 프로토콜, (기본 토대는 UDP를 커스터마이징해서 만듬)
    • HTTP : HTML 문서를 전송하기 위한 프로토콜 - (TCP/IP 4계층, 응용 계층)
      • 주요 특징 : 클라이언트-서버 구조, 비연결성, 무상태
      • 클라이언트-서버 구조 : 클라이언트가 서버에 데이터를 요청하고, 해당 요청에 서버가 응답하는 구조
      • 비연결성 : 클라이언트가 서버로 작업을 요청해 응답을 받으면 연결을 끊음, 즉 요청이 있을 떄만 연결을 유지해 통신 과부하를 줄임
        • But. 요청이 있을 떄마다, 연결 설정을 새로 해야 하는 부담이 있음
      • 무상태 : HTTP는 상태를 유지하지 않는 무상태(stateless) 프로토콜
        • 상태를 유지하지 않는다는 것은 서버가 클라이언트의 이전 요청이나 세션 정보를 기억하지 않는다는 의미.
        • 장점 : 무상태로 동작하는 HTTP를 따르면 서버의 부담이 줄어들고, 네트워크 확장성이 향상됨

5.1 HTTP 메시지

  • HTTP 메시지 : 응용 계층에서 데이터 요청 및 응답 시, 원활한 데이터 전송을 위한 데이터 형식을 의미
  • HTTP 메시지는 요청 메시지, 응답 메시지 2가지로 구분됨
    • 요청 메시지 : 클라이언트가 서버에 요청할 떄, 사용
    • 응답 메시지 : 서버가 클라이언트에 응답할 떄, 사용
  • 위 두 메시지는 모두 시작행(start line), 헤더(header), 공백행(blank line), 본문(body)로 구성
    • 시작행 : HTTP 메서드(요청 내용), 요청 URL(요청을 보내는 서버 주소), HTTP 버전이 포함
    • 헤더 : 요청과 관련된 부가 정보가 포함
    • 공백행 : 헤더의 끝을 표시하기 위해 빈 행을 넣음
    • 본문 : 요청 내용에 따라 생략 가능, 어떤 데이터를 저장-수정하는 요청인 경우 본문이 들어가고, 단순 조회-삭제 요청인 경우 본문이 생략됨
1
/** 요청 메시지 시작행 구성

2
 * GET         ---> HTTP 메서드

3
 * /index.html ---> 요청 URL

4
 * HTTP/1.1    ---> HTTP 버전

5
 */

6


7
(시작행)   GET /index.html HTTP/1.1

8


9
(헤더)     Accept: text/html,apllication~~~

10


11
(공백행)

12


13
(본문)     (단순 조회-삭제 요청인 경우 생략 가능)
1
/** 응답 메시지 시작행 구성

2
 * HTTP/1.1        ---> HTTP 버전

3
 * 304             ---> 상태 코드

4
 * Not Modified    ---> 상태 메시지

5
 */

6


7
(시작행)   HTTP/1.1 304 Not Modified

8


9
(헤더)     Vary: Origin

10
          Access-Control-Allow-Credentials: true

11
          ~~~~

12


13
(공백행)

14


15
(본문)     (단순 조회-삭제 요청인 경우 생략 가능)
  • HTTP 헤더는 개발자가 별도 설정하지 않아도, 기본 정보가 자동으로 포함되는데,
    • 개발자가 인위적으로 헤더의 값을 추가할 수도 있다.
    • 헤더 정보는 웹 브라우저 개발자 도구 Network 탭에서 확인 가능하다.
  • 특정 Name를 클릭하면, Header 정보가 General, Response Header, Request Headers 3개로 구분된 것을 볼 수 있다.
    • General : 요청 또는 응답의 일반적인 헤더 정보가 포함됨
      • Request URL(요청을 보내는 서버 주소), Request Method(요청 메서드), Status Code(상태 코드) 등이 포함
    • Response Header : 응답에만 있는 헤더 정보,
      • Set-Cookie(클라이언트에 쿠키 생성), Server(응답을 생성한 서버의 소프프웨어나 버전정보), Location(페이지 이동 지시) 등이 포함
      • cf. 쿠키(Cookie) : 웹 서버가 생성해 웹브라우저로 전송하는 작은 정보 파일을 의미
    • Request Headers : 요청에만 있는 헤더 정보
      • Host(요청을 보내는 서버주소), User-Agent(클라이언트 정보), Accept(허용 미디어 범위) 등이 포함

5.2 HTTP 메서드

클라이언트는 HTTP Method를 요청 메시지에 넣어 전달하고, 서버는 요청에 대한 상태코드(Status Code)를 응답 메시지에 넣어 전달한다.

메서드설명
GET데이터 조회
POST데이터 등록
PUT데이터 전체 수정
PATCH데이터 일부 수정
DELETE데이터 삭제
OPTIONS서버가 어떤 메시드를 지원하는지 확인
HEADGET 메서드와 같은 역할을 하지만, 시작행과 헤더만 반환받음
TRACE클라이언트와 서버 간 루프백 테스트(loopback test)를 할 떄 사용, 루프백 테스트를 하면 통신의 어느 시점에 에러가 발생했는지 디버깅 가능
CONNECT프록시 서버 같은 중간 서버 경유를 요청할 때 사용

HTTP 메서드는 크게 안전성(safe)과 멱등성(idempotent)라는 속성으로 구분가능하다.

  • 안전성 : HTTP 메서드로 보낸 요청이 서버의 상태를 변경하지 않으면, 그 메서드는 ‘안전하다’고 말함
    • e.g. GET, OPTIONS, HEAD, TRACE
  • 멱등성 : 서버로 보낸 요청이 몇 개이든 상관없이 항상 서버에서 동일한 처리과 응답을 받는 메서드를 ‘멱등하다’라고 말함
    • “멱등” : 수학에서 연산은 여러 번 적용해도 결과가 달라지지 않는 성질을 의미
    • 즉, 멱등한 메서드는 여러 번 요청하더라도 동일한 응답을 받는 메서드를 말함
    • e.g. GET, PUT, DELETE, OPTIONS, HEAD

5.3 HTTP 상태 코드

그룹상태코드설명
1xx정보 응답요청에 대한 처리가 진행 중
2xx성공 응답요청에 대한 응답이 성공
3xx리다이렉션 메시지요청을 완료하기 위해 리다이렉션(새 URL로 재요청)이 필요
4xx클라이언트 오류 응답요청을 처리하던 중 오류가 발생
5xx서버 오류 응답클라이언트의 요청을 받았으나, 서버가 적절하게 응답 불가

5.4 HTTP 버전별 특징

  • HTTP/0.9 : HTTP 최초 버전, GET 메서드만 지원했음, 정적 HTML 문서 전달용
  • HTTP/1.0 : POST, HEAD 메서드 추가, 헤더와 본문이 메시지 형식에 추가, 미디어(이미지, 오디오, 비디오) 형식 전송 가능
  • HTTP/1.1 : 현재 사용하는 메서드가 모두 추가됨, 한 번의 연결로 여러 요청과 응답을 보낼 수 있게 됨
  • HTTP/2 : 1.1 버전의 한 번의 연결로 보내는 요청, 응답을 병렬로 보내서 처리 속도를 개선, 헤더를 압축해 네트워크 부하 감소
  • HTTP/3 : 이전 버전은 모두 TCP 프로토콜이지만, 3버전부터 QUIC 프로토콜로 데이터를 전송, 신뢰성, 속도가 향상, 암호화를 제공해 보안 우수
    • 현재 구글과 유튜브가 3버전 사용 중이며, 1.1버전과 2버전도 활발히 사용 중, 0.9버전과 1.0버전은 더 이상 사용되지 않음

5.5 HTTPS 보안 프로토콜

  • HTTP : 80 포트
    • TCP/UDP 위에서 동작
    • 구조 : 네트워크 접근 계층 → 인터넷 계층(IP) → 전송 계층(TCP, UDP, QUIC) → 응용 계층 (HTTP)
  • HTTPS : HTTP에 보안 요소를 강화한 프로토콜, 443 포트
    • TCP/UDP 위에 SSL(Secure Sockets Layer) 프로토콜을 추가해, 데이터 전송 시 암호화를 수행
    • SSL 프로토콜은 현재 TLS(Transport Layer Security)로 명칭이 변경됐지만,
    • SSL이란 이름이 안사라져서 SSL/TLS라고 부름
    • 구조 : 네트워크 접근 계층 → 인터넷 계층(IP) → 전송 계층(TCP, UDP, QUIC) → 보안 계층(SSL/TLS) → 응용 계층 (HTTP)

5.6 쿠키

5.6.1 쿠키

쿠키(cookie) : 웹 서버가 생성해 웹 브라우저로 전송하는 작은 정보 파일 (클라이언트의 요청을 기억하고 구분하는 용도로 사용)

  • 쿠키 전달 과정
    • 클라이언트가 서버에 어떤 요청을 보내면, 서버는 클라이언트에 응답할 때, 쿠키 정보를 포함해 응답함
    • 클라이언트는 응답받은 값에 쿠키가 있으면, 브라우저의 기억장치에 저장함
    • 이후 요청을 보낼 때 저장했던 쿠키를 넣어 전송함
    • 서버는 요청에 포함된 쿠키 정보를 보고 클라이언트를 식별하며, 클라이언트와 주고받은 과거 통신 내역에 대한 일부 데이터를 저장함
  • 쿠키는 서버에서 구동되는 도메인별로 관리된다.
    • e.g. 네이버에서 요청 및 응답받을 떄, 주고받은 쿠키는 naver.com 도메인에서만 사용 가능
  • 서버가 클라이언트로 요청을 받아 응답을 보낼 떄는 Set-Cookie라는 헤더 정보를 전송
    • Set-Cookie : <쿠키이름>:<쿠키값>

헤더에 쿠키 정보를 전송하는 코드

1
app.get('/', (req, res) => {

2
  res.setHeader('Set-Cookie', [username="뭐시기"]);

3
  res.sendFile(`${_디렉토리명`/index.html);

4
});

응답 메시지의 헤더에는 Set-Cookie가 포함되어, 클라이언트의 브라우저에는 username이 뭐시기라는 값을 저장함. 이후 전송하는 모든 요청에 대해 다음 쿠기를 넣어 보낸다.

1
GET /test.html HTTP1.1

2
Host : www.test.org

3
Cookie: username=뭐시기

5.6.2 쿠키 속성

Set-Cookie에는 expires, path, domain, priority 등 여러 값이 붙어있는데, 이를 쿠키 속성이라 부름

  • 쿠키 만료시간(expires, max-age) : 모든 쿠키는 브라우저가 닫히면 삭제됨.
    • But. expires 속성으로 날짜를 명시하거나, max-age 속성으로 기간을 명시하면, 해당 기간까지 쿠키를 저장할 수 있음
    • expires=Wed, 3 Sep 2024 09:00:00 GMT
    • max-age=3600
  • 쿠키 범위(domain, path) : 쿠키 범위에 따라 쿠키를 보낼 URL과 경로를 설정 가능
    • domain=test.com : test.com 도메인과 서브 도메인에서 접근 가능
    • path=/mypage : /mypage 경로와 그 하위 경로에서 접근 가능
  • 쿠키 보안(secure) : 쿠키는 HTTP 메세지에 전송되므로 중간에 탈취당하기 쉽다.
    • 따라서 민감한 정보는 쿠키로 전달하면 안된다.
    • 그래도 굳이 쿠키를 쓸려면, secure 속성을 지정한다.
    • Secure 속성으로 지정하면, HTTP가 아닌 HTTPS를 사용할 떄만 쿠키 값을 전송함
  • XSS 공격 방지(HttpOnly) : XSS(Cross-Site Scripting)는 웹 사이트에 악성 스크립트를 심어 쿠키를 탈취하는 기법
    • 이러한 XSS 공격을 막으려면 HttpOnly 속성을 사용해 클라이언트가 쿠키에 접근하지 못하게 할 수 있다.
    • 이러면 해커가 쿠키를 탈취하려 해도, 클라이언트에 저장된 쿠키에 접근 권한이 없기에 탈취를 막을 수 있음.
  • CSRF 공격 방지(samesite) : CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)는 원치 않는 사이트로 쿠키를 보내는 공격 기법
    • 인증된 사이트에 저장된 쿠키를 해커가 만든 다른 사이트에 전송하는 방식으로 쿠키를 악용함
    • 이러한 CSRF 공격을 막으려면, samesite 속성을 사용하는데, samesite 속성을 다음 3가지가 있다.
      • strict : 다른 사이트로 쿠키 전송 불가
      • lax : 안전한 HTTP 메서드(e.g. GET) 외에 최상위 경로에서 이뤄지는 경우를 제외하고 그 밖의 사이트에 쿠키 전송 불가
      • none : 다른 사이트로 쿠키를 전송할 수 있음 (이 옵션은 사용하면 안됨)

cf. https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies

5.7 세션

세션(session) : 서버가 자신에게 요청을 보낸 클라이언트의 상태를 유지하기 위한 방법

  • 쿠키는 민감한 정보를 담기에 취약하기에, 좀 더 안전한 방법으로 세션이 있음
  • 세션 전달 과정
    • 클라이언트가 서버에 어떤 요청을 보내면, 서버는 무작위로 생성한 고유한 세션 ID를 응답 메시지의 Set-Cookie 헤더 정보에 포함해 전달
    • 이후 클라이언트는 요청 메시지를 보낼 때마다 응답받은 세션 ID를 포함해서 보냄
    • 서버는 클라이언트의 요청 메시지에 있는 세션 ID를 보고 해당 ID가 유효한지 확인한 뒤 요청을 처리함
    • 세션은 웹 브라우저와 같은 클라이언트가 종료되면 즉시 삭제됨.
    • 또한 새 클라이언트가 요청을 보내면 세션 ID를 주고받는 과정을 처음부터 다시 수행

5.8 웹 소켓

HTTP의 단점 - 채팅 서비스 구현 힘듬

  • HTTP는 클라이언트와 서버의 연결을 유지하지 않는 비연결성이라는 특징이 존재
  • 또한 연결 설정이 클라이언트에서 서버로 요청이 발생할 때만 이뤄지므로 요청 없이 서버에서 응답을 보낼 수 없음
  • 즉, 비연결성이란 특징때문에 HTTP는 채팅과 같이 양방향으로 계속 요청과 응답을 보내는 서비스를 구현하기에는 부족

위 양방향 데이터 전송 문제를 해결하기 위해 등장한 것이 웹소켓(web socket) 프로토콜

  • 웹 소켓은 HTTP처럼 TCP/IP 4 계층 중 응용 계층에서 동작
  • HTTP와 달리 한 번 연결되면 끊어지지 않으며, 클라이언트의 요청이 없어도 서버에 서 응답을 보낼 수 있음
  • 웹 소켓 전달 과정
    • 웹 소켓의 초기 연결 설정은 HTTP로 진행. (클라이언트와 서버가 웹 소켓을 지원하는지 사전에 알 수 없기 때문)
    • HTTP 요청 메시지의 헤더에 Upgrade 값으로 websocket을 보내 서버가 웹 소켓을 지원하는지 확인
    • 요청을 받은 서버는 웹 소켓을 지원하는 경우, 응답에 상태 코드 101, 상태 메시지 Switching Protocols를 담아 보냄
    • 요청과 응답을 주고받으면, 웹 소켓 연결 설정이 완료되고, 이후 양방향으로 데이터 전송 가능

cf. https://developer.mozilla.org/ko/docs/Web/API/WebSockets_API

6. API

  • API(App Programing Interface) : 앱에서 사용하도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
  • 인터페이스 : 각기 다른 사물이나 시스템 간의 커뮤니케이션이 가능하도록 설계된 상호작용 방식
  • 브라우저 API : 웹 브라우저에서 제공하는 API 집합 (e.g. DOM, Geolocation, Storage API)
    • DOM API : 요소 선택과 탐색, 요소 생성과 조작, 문서 조작, 이벤트 처리하는 브라우저 API
    • Geolocation API : 사용자 위치 정보를 가져오는 기능을 제공하는 브라우저 API
    • Storage API : 데이터를 웹 브라우저에 저장하는 방법을 제공하는 브라우저 API
      • 스토리지 API는 크게 다음 웹 스토리지 API와 인덱스드DB API로 구분

6.1 브라우저 API

브라우저 API : 웹 브라우저에서 제공하는 API 집합 (e.g. DOM, Geolocation, Storage API)

  • DOM API : 요소 선택과 탐색, 요소 생성과 조작, 문서 조작, 이벤트 처리하는 브라우저 API
  • Geolocation API : 사용자 위치 정보를 가져오는 기능을 제공하는 브라우저 API
  • Storage API : 데이터를 웹 브라우저에 저장하는 방법을 제공하는 브라우저 API
    • 스토리지 API는 크게 다음 웹 스토리지 API와 인덱스드DB API로 구분
    • 웹 스토리지 API : 키-값 형태의 데이터를 웹 브라우저에 저장하는 API
      • 로컬 스토리지 : 브라우저를 종료해도 데이터가 유지됨
      • 세션 스토리지 : 브라우저가 종료하면, 데이터도 값이 삭제됨
    • 인덱스드DB API : 브라우저에 데이터를 저장하기 위한 고급 메커니즘을 제공
      • 브라우저에 제공하는 NoSQL 기반의 데이터베이스
      • 데이터를 고정되지 않는 객체 형태로 웹 브라우저에 저장하며, 저장된 데이터는 별도 삭제하지 않는 이상 영구적으로 존재

6.2 API 디자인 패턴

6.2.1 SOAP

SOAP(Simple Object Access Protocol) : 네트워크 상 데이터 교환 포맷을 표준화하기 위한 프로토콜

  • 기본 데이터 포맷으로 XML(eXtensible Markup Language)를 사용
  • 보안 처리를 위한 SSL를 지원, WS-Security 자체 표준 보안 기능 존재
  • 단점으로 작은 데이터를 전송하려고 해도, XML 구조로 인해 많은 코드를 작성해야 함

6.2.2 REST

REST(Representational State Transfer) : HTTP 요청 메시지로 서버 데이터를 조작하기 위한 디자인 패턴이며, REST 디자인 패턴을 적용한 API를 의미

  • 자원, 행위, 표현을 포함해 API를 설계
  • REST API의 단점
    • 언더페칭 : API 요청 결과와 필요한 데이터를 한 번에 조회하지 못해, 한 번의 요청으로 목적을 달성하지 못하는 것을 의미
      • 따라서 REST API를 사용해 목적을 이루려면 여러 번 API를 호출해야 함
    • 오버페칭 : API 요청 결과와 필요 이상의 데이터를 조회하는 것을 의미
      • 특정 데이터 하나만 필요해도 그 이상의 것을 포함한 데이터를 응답받는다면, 네트워크 대역폭을 낭비하고 응답시간이 늘어남

6.2.3 GraphQL

GraphQL : API를 좀 더 쉽게 구축하고, 사용할 수 있도록 설계된 쿼리 언어 및 서버 측 런타임

  • REST API의 고질적인 문제인 언더페칭과 오버페칭을 해결한 차세대 API 디자인 패턴

6.3 API 호출 방법

  • 동기식 호출 : 코드가 순차적으로 실행되는 방식
  • 비동기식 호출 : 코드가 비순차적으로 실행되는 방식. 2005년 제시 제임스 개릿의 논문에서 비동기식 호출 방식을 Ajax라고 명명
    • Ajax를 구현하는 방법 : XMLHttpRequest, jQuery의 ajax(), Axios, Fetch API 등
    • XMLHttpRequest : 웹 브라우저의 내장 객체
      • open() : 통신을 초기화할 때, 사용
      • send() : 전송을 요청할 떄, 사용
      • abort() : 전송을 중지할 떄, 사용
      • onreadystatechange() : 응답 상태를 모니터링할 떄, 사용
    • jQuery의 ajax() : XMLHttpRequest의 코드 가독성이 떨어져 등장한 라이브러리의 함수
    • Axios : jQuery를 대체, 내부적으로 XMLHttpRequest 객체를 사용하지만, 좀 더 편한 인터페이스를 제공
    • Fetch API : 가장 최근 등장한 인터페이스, 요청에 대한 응답결과를 Promise 객체로 반환해 편리하게 사용 가능

6.4 비동기식 API 데이터 교환 형식

  • CSV
  • XML
  • JSON : 가장 많이 사용, 키-값 형태로 구성

6.5 API 테스트 도구

7. 테스트

7.1 테스트 유형

  • 유닛 테스트 : 독립접으로 분리할 수 있는 가장 작은 코드 단위를 테스트
  • 통합 테스트 : 여러 기능을 통합 해 한 번에 테스트
  • E2E 테스트 : 앱을 처음부터 끝까지 실행해보면서, 올바르게 동작하는지 테스트하는 것
  • 시각적 회귀 테스트 : 앱의 시각적인 디자인과 레이아웃을 확인하는 것
  • 접근성 테스트 : 시각, 청각, 운동, 인지 장애가 있는 사람이 웹 어플리케이션을 사용할 떄, 불편한 점이 없는지 테스트
  • 성능 테스트 : 앱을 사용하면서 데이터를 불러오거나, 사용자 입력 양식을 전송, 페이지 이동같은 행위에서 속도가 느려 불편하지는 않는지 테스트

7.2 테스트 도구

7.2.1 수동 테스트 도구

수동 테스트 도구는 브라우저 개발자 도구가 대표적

  • Elements 도구 : 웹 페이지 DOM(문서 객체 모델)을 테스트
  • Console 도구 : JS 디버깅하는 용도로 사용
  • Network 도구 : 웹 페이지를 불러오는데 사용한 모든 HTTP 요청 및 응답을 표시
  • Sources 도구 : 브라우저에 나타난 웹 페이지의 모든 리소스를 표시
  • Performance 도구 : 브라우저에 나타난 웹페이지의 성능을 측정할 떄 사용
  • Memory 도구 : 웹페이지의 메모리 누수 여부를 테스트
  • Lighthouse 도구 : 성능, 접근성, 모범 사례, 검색엔지 최적화, PWA 측면에서 앱의 품질을 검사하고 보고서를 만들어줌
  • Application 도구 : 스토리지, 캐시, 백그라운드 서비스, 프레임 등을 테스트

7.2.2 자동 테스트 도구

9. 배포

프론트엔드 역사와 미래