Mo's Develog

[프로그래머스/코딩테스트] 코딩테스트 입문 뽀개기 2/5 완료

MoZZANG — Mon, 1 Apr 2024 20:55:21 +0900

퇴근 후 조금씩 문제푸는 습관을 들이는게 역시 생각보다 쉽지않네. 하지만 고작 Lv.0으로 가타부타 하면 안되지.

근데 왜 자꾸 1페이지에 풀지 않은 문제가 계속 생기는거지?

이것도 무슨 알고리즘 같이 비슷한 문제 계속 추천해주는건가??

무튼 빨리 입문 뿌시고 Lv.1 부터 가보즈아!

[프로그래머스/코딩테스트] 코딩테스트 입문 뽀개기 1/5 완료

MoZZANG — Fri, 22 Mar 2024 18:59:24 +0900

앞으로 알고리즘과 코딩테스트를 준비하기 위해 0부터 시작해보자고 결심했다.

처음에는 백준에서 단계별 문제로 시작하려고 했는데, 백준은 뭔가 IDE와 가깝지 않아서 그런지 거부감(?)같은게 들었다.

그리고 문제를 확인하는 공간과 정답을 입력하는 공간이 나누어져 있어 보기가 탭으로 전환해야하는 불편함 때문에 UX가 좀 떨어지는 맛이 있어서 아쉬웠다.

그래서 바로 프로그래머스로 넘어갔는데 이게 왠걸?!

프로그래머스는 기업들의 실제 코딩테스트가 진행되는 사이트 답게 문제풀이와 제출 등이 정말 잘 되어있었다. 오히려 문제 푸는 맛이 난다랄까?

다시한번 UX의 중요성을 느낀거 같다. 같은 서비스를 제공해도 UX가 좋지 않다면 사용자를 놓칠 수 밖에 없는 것이 지금 시대의 흐름이니까.

무튼 프로그래머스에서 제공해주는 입문 100선(Lv.0) 문제부터 뽀개고 알고리즘공부와 함게 Lv.1부터 뿌셔나가보자잉

아직 Lv.0이라 그런지 퇴근하고 대여섯개씩 풀다보니 우선 1페이지 완료!

문제를 풀다가 느낀점이나 다른분들의 풀이를 보고 무릎을 탁칠만한 배움이 있다면 같이 남기도록 해보자.

별거아니지만 꾸준히 글로써 기록을 해보는 습관도 같이 키워보자.

향로님의 블로그명처럼 "기억보다는 기록을"

[AWS]S3 버킷 생성 및 권한 설정

MoZZANG — Wed, 13 Dec 2023 23:05:59 +0900

하드디스크 클라우드 서비스로 유명한 AWS S3 사용방법을 알아보자

AWS S3에서 버킷만들기

AWS가입하고 로그인 하면 콘솔홈으로 접속될 것이다.

콘솔 홈

여기서 우측 상단 아이디 왼쪽에 region, 그러니까 지역을 선택하는 dropdown이 있을텐데 클릭 후 자신이 위치하는 곳에서 가장 가까운 곳으로 선택하자.

본인은 서울이므로 서울로 선택함

자 그리고 검색창에 s3라고 입력 후 나오는거 클릭하자

그리고 새 버킷, 즉 저장소를 만들기 위해 노랑버튼을 누르자

자 그러면 다음과 같은 창으로 넘어갈텐데

위에서 보듯이 버킷이름은 유니크한 이름으로 적어주자.

그리고 다른건 특별히 건드릴 것 없고 퍼블릭 엑세스 차단을 해제해주고 경고창의 체크박스에 체크를 해서 위험은 내가 감수하겠다는걸 얘기해준 후

최하단에 버킷만들기를 눌러 생성해주자.

버킷정책을 수정해주자

이제 자신만의 버킷이 생성되었을 것인데, 만든 사이트에서 파일이나 이미지등을 이 버킷에 업로드하고 그 파일이나 이미지등을 사이트에서 표출하기 위해 약간의 권한 설정들을 해줘야 한다.

방금만든 버킷을 클릭해서 들어오면

버킷 상세페이지로 들어오게 되고 상단 탭중에 권한을 클릭해주자

그리고 중간쯤에 보면 버킷정책이라는 것이 있을텐데 편집을 눌러 정책을 설정해주자.

이 정책이라는 건 말 그대로 이 버킷에 업로드 될 파일이나 이미지 등에 대한 정책을 정해주는 곳인데 여러 많은 옵션들이 있겠지만 베이직한 옵션으로 설정정도만 해줘도 충분할 것이라고 생각한다.(일단은)

신속하고 간단한 정책생성을 위해 새 문 추가라는 버튼을 눌러주면 되는데 하단이나 우측에 있는 버튼 모두 동일한 버튼이니 맘에 드는걸로 골라서 눌러주면 다음과 같이 정책이 하나 간단하게 생성될 것이다.

그리고는 다음과 같이 적어주자. 자세한 정책 설명은 다음과 같다

위 이미지에는 조금 빠진부분들이 있어서 붙여넣기를 위해서는 아래 코드를 참고바란다.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "Statement1",
			"Effect": "Allow",
			"Principal": "*",
			"Action": "s3:GetObject",
			"Resource": "arn:aws:s3:::당신 버킷명/*"
		},
		{
			"Sid": "Statement2",
			"Effect": "Allow",
			"Principal": {
				"AWS": "arn:aws:iam::당신AWS계정ID:root"
			},
			"Action": [
				"s3:PutObject",
				"s3:DeleteObject"
			],
			"Resource": "arn:aws:s3:::당신 버킷명/*"
		}
	]
}

정책에서는 탭 들여쓰기와 띄어쓰기가 매우 중요하므로 간격을 맞춰서 꼭 해주자

그리고 아래쪽에 CORS설정하는 곳도 있는데 여기도 설정해주어야 한다.

편집을 눌러 수정해주자.

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "PUT",
            "POST"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": [
            "ETag"
        ]
    }
]

CORS는 개발하는 사람이라면 한번쯤은 들어봤을테니 구글링 해보시면 매우 양질의 정보가 있을 것이다. 꼭 찾아서 읽어보자

위 내용은 결국 어떤 사이트에서 이 버킷안의 파일들을 PUT, POST요청할 수 있는지를 등록해주는 것이다.

AllowedOrigins 배열안에 등록해준 사이트들에서만 이 버킷안의 파일들을 대상으로 읽기, 쓰기, 삭제할 수 있는데,

개발중이라면 *을 넣어줘서 모든사이트를 허용해주고, 나중에 사이트를 오픈하게 되면 그 사이트 주소를 AllowedOrigins안에 넣어주자.

Access 키 발급

그대가 만든 서버에서 S3로 접속하고 파일들을 업로드 하고 싶으면 Access key를 넣어줘야 한다.

우측 상단에 프로필을 눌러서 '보안 자격 증명'으로 들어가자.

그리고 스크롤 조금 해보면 '액세스 키' 라는 타이틀로 엑세스 키를 만드는 섹션이 있을텐데

거기서 액세스 키 만들기를 눌러서 엑세스 키와 비밀번호를 발급받자.

이 엑세스 키랑 비번은 정말 소중하다. 혹시 털리면 AWS 털려서 난리날 수도 있으니 조심하자

아무튼 위에서 발급받은 키와 비밀 엑세스키를 s3파일 업로드하는 api같은 곳에 넣어서 사용하면 된다.

[NextJS] Github 로그인 연결해보기

MoZZANG — Sat, 9 Dec 2023 20:15:25 +0900

요즘은 소셜로그인이 대세다. 왠만한 곳들은 회원가입하기를 들어가보면 카카오톡, 페이스북, 구글 등의 소셜회원가입이 가능하다.

그중에서 오늘은 가장 쉽게 붙여볼 수 있는 github 로그인을 nextjs에 붙여보자

소셜로그인이라는건

예를 들면 철수가 내가 만든사이트(A.com)에 회원가입 페이지에 있는 '카카오톡으로 회원가입하기' 버튼을 누르면

카카오톡 아이디랑 비번을 넣어서 로그인 하라는 페이지를 보여주고,

거기서 철수가 카카오톡 아이디랑 비번을 입력하고 '카카오톡 로그인하기' 버튼을 누르면 카카오톡은 철수에게 '야 A.com에 님 정보 주는거 동의함?' 이라고 물어 볼 것이다.

거기서 동의를 하면 이제 철수의 카카오톡은 A.com에 철수의 이메일, 이름, access token 등의 정보를 넘겨주게 된다.

그러면 이것들을 가지고 회원가입 및 로그인 처리를 하면 그게 소셜로그인 중 카카오톡으로 로그인 하기이다.

그걸 대충 그림으로 보면 아래와 같다.

수채화라도 기대했냐?

거의 모든 소셜로그인이나 회원가입이 위와 같은 방식이고 이럴때 사용자의 권한을 OAuth라고하며, 소셜로그인이나 회원가입을 붙이려는 사이트에서는 이 OAuth를 가져와서 구현하는 개념이다.

자자 거두절미하고, Github 로그인을 붙여보자.

환경은 NextJs v13, node v^18, React v^18 이며 Next-Auth라는 아주아주 기똥찬 라이브러리로 쉽게 구현해보자

1. Github OAuth 가져오기

깃헙에서 권한을 등록하고 가져와야한다.

1. 깃헙로그인 후 우측상단에 자기 프로필을 누르면 나오는 메뉴들 중 settings를 클릭하자.

2. 이동된 페이지 좌측메뉴 최하단에 'Developer settings'로 진입

3. 누가봐도 여기요 하고 손흔드는 메뉴로 진입

처음이면 긍정적으로 초록버튼을 누르자

개발중 또는 연습중일때는

로컬이 아니고 서비스하거나 배포할 사이트에는 Homepage URL에 해당 URL넣어주고

callback URL도 원하는 URL입력해주고 등록하기 버튼 누르자

그러면 다음과 같은 화면으로 넘어 갈껀데

비번 보여주는 버튼도 누르고 인증과정 거치면

자 이제 발급이 끝났으니 id와 비번을 까먹지 않게 어디 꼭 적어두자

2. Next-Auth로 연결하기

https://next-auth.js.org/

NextAuth.js

Authentication for Next.js

next-auth.js.org

1. 설치하기

npm install next-auth

또는

yarn add next-auth

2. api 만들어주기

https://next-auth.js.org/getting-started/example

Getting Started | NextAuth.js

The example code below describes how to add authentication to a Next.js app.

next-auth.js.org

현재 NextJS 13에서는 app폴더 하위에 api를 만드는 것을 권장하고 있지만 next-auth 라이브러리는 NextJS 12버전에서 사용하던 page폴더 하위에 api폴더를 만들고 auth 폴더 > [...nextauth].js(ts)를 만들라고 한다.

그리고 [...nextauth].ts에서 다음과 같이 적고 저장해주자

//[...nextauth].ts
import nextAuth from "next-auth";
import GithubProvider from "next-auth/providers/github";
export const authOptions = {
  providers: [
    GithubProvider({
      clientId: "아까 적어둔 깃허브에서 발급받은 id",
      clientSecret: "아까 적어둔 깃허브에서 발급받은 비밀번호",
    }),
  ],
  secret: "jwt만들때 쓸 암호",
};
export default nextAuth(authOptions);

기본적으로 OAuth는 jwt방식으로 진행되기 때문에 secret에 토큰 만들때 사용할 보안수준 높은 비밀번호를 정해주자.

3. 준비 끝, 로그인 해보자

로그인 버튼은 onClick이벤트에 의해 작동할테니 server component로 만들 수 없다.

따라서 client component로 만들어서 layout파일에 넣자.

//LoginButton.tsx
"use client";
import { signIn } from "next-auth/react";

export const LoginButton = () => {
  const handleLogin = () => {
    signIn();
  };
  return <div onClick={handleLogin}>로그인</div>;
};

next-auth에서는 signIn이라는 함수를 제공해주는데 이 함수를 사용하면 그냥 로그인 기능이 작동된다.

(signOut이라는 함수도 있는데 이건 로그아웃 시켜주는 개꿀함수)

~~앙개꿀띠~~

//layout.tsx
import { LoginButton } from "@/app/LoginButton";
import type { Metadata } from "next";
import { Inter } from "next/font/google";
import "./globals.css";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
  title: "Create Next App",
  description: "Generated by create next app",
};

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body className={inter.className}>
        <LoginButton />
        {children}
      </body>
    </html>
  );
}

자 이제 버튼을 눌러보면

누르면

아까 개념정리할때 얘기했던 4번 '님 진짜 정보넘길꺼임?'을 물어본다.

긍정적으로 우측버튼을 누르면

아까 callback URL에 기입해뒀던 곳으로 돌아가게된다.

4. 근데 이거 로그인 된거임?

뭔가 로그인 됐는지 않됐는지 모를정도로 아무 변화가 없을 것이다.

하지만 로그인된 상태이다.

확인해보려면

또 다음과 같은 함수를 가져다 사용하면 된다.

import { LoginButton } from "@/app/LoginButton";
import type { Metadata } from "next";
import { getServerSession } from "next-auth";
import { Inter } from "next/font/google";
import { authOptions } from "../../pages/api/auth/[...nextauth]";
import "./globals.css";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
  title: "Create Next App",
  description: "Generated by create next app",
};

export default async function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  // next-auth에서 제공해주는 서버세션정보를 가져오는 함수
  // Promise를 반환하니까 async await ㄱㄱ
  const loginData = await getServerSession(authOptions);
  console.log(loginData);

  return (
    <html lang="en">
      <body className={inter.className}>
        <LoginButton />
        {children}
      </body>
    </html>
  );
}

getServerSession이라는 서버 서버세션정보를 가져다 주는 함수에 아까 [...nextauth].ts에 만들었던 options를 넣어주면 끝이다.

자 이걸 콘솔찍어보면 터미널에 짠하고 다음과 같은 정보가 넘어온다!

바로 님 깃헙에 등록해둔 email과 이름 그리고 깃헙은 프로필 이미지까지 보내준다!!

~~와 진짜 개편해~~

그럼 이제 이걸로 로그인 로그아웃을 구현해보면 아주 간단한 깃허브 소셜로그인을 만들어 볼 수 있겠제?

docs보면 다양한 옵션들도 많으니까 필요하면 가져다 사용해서 강려크한 로그인기능으로 업그레이드도 해보셈

MongoDB)가입부터 초기 세팅까지 해보자

MoZZANG — Sat, 2 Dec 2023 11:37:09 +0900

사이드 프로젝트 하나 하고잡은데 백엔드 구하기 귀찮거나 아싸라서 그런거 못하는 프론트엔드를 위해 mongodb를 사용해서 간단하게 db구축해보자

mongodb는 본인기준 비관계형 db중에 가장(?) hot한데 관계형 db보면 갑자기 속 울렁거리는 프론트들을 위해 아주 친숙한 object형으로 db가 만들어져있으니까 속 편하게 해볼 수 있을 듯하다.

(관계형 비관계형이 뭔지는 핑프아니면 검색해보자)

자 그럼 바로 레쓰기릿해보자

최초에 mongodb사이트에 가입을 하자.

1. ??? : 설치와 가입은 항상 긍정적인 마음으로 하거라

처음 가입하는 과정에 막 설문조사 같은거 물어볼텐데 친절하고 긍정적으로 답변 해도되고 안해도 나중에 바꿀 수 있으니까 하자.

그리고 혹시 님 돈 좀 있는지를 물어보는데

우린 항상 돈이 없으니까 무료로 선택해주고 (혹시 돈좀 있으면 유료버전으로 해도 됨)

자기가 현재 있는 국가나 지역을 선택하면 되는데 난 서울에 있으니 서울로 선택

(대전, 대구, 부산 등 없으니까 그냥 대한민국 살면 서울로 ㄱㄱ)

2. 야너두 DB 가질 수 있어

화면 좌측에 다양한 탭 메뉴중에 Databse Access로 들어가자.

그리고 새 계정 기준 아무 db가 생성되어 있지 않을 거니까 다음과 같은 화면에서 추가 버튼을 눌러주자.

그러면 모달창이 뜰텐데 다음과 같은부분을 선택하거나 채워주자

여기서 주의사항은 Built-in-Role을 atlas admin으로 해야 위에 적은 아이디로 DB 접속 시 뭐든 다 할 수 있다. 즉 슈퍼계정인것

다음으로 DB에 접속할 수 있는 IP를 등록해야하는데,

로 ㄱㄱ 하자

마찬가지로 생성 버튼을 누르면

▲ 또 다시 선택을 강요받게 되는데, 님 스벅에서도 할꺼아니까 조용히 그냥 오른쪽꺼 선택합시다잉

그래서 오른쪽 버튼 누르면

자동으로 IP가 세팅될테고 확인버튼 누르면 끝

자 그러면 등록이 막 되고 있을거고 Active상태로 되면 등록 끝

등록중...

등록 완료!

3. MZ세대는 찍먹부터 해봐야제

자 이제 우리는 DB 오너니까 한번 맛 좀보자

'내가 만든 내 세상에 데이터 넣어볼꺼임' 버튼을 누르면 다음과 같은 모달창이 뜬다

mongodb는 데이터를 다음과 같은 식으로 저장하는데

collection이라는 폴더 안에 데이터라는 파일(문서)들을 저장한다라고 생각하면 쉬울라나

나는 DB이름을 dbName이라고 하고 collection이름을 Post라고 했다.

Insert document 버튼을 눌러서 데이터를 넣어보자

이런 모달창에다가

이렇게 기입하고 insert누르면

(id)는 자동생성되므로 손대지 않아도 된다.)

잘 등록이 되었다.

자 다음포스팅에서는 Nextjs(v13)에서 mongodb와 연결하는 법을 알아보자

react + typescript로 github package화 하기(feat. rollup)

MoZZANG — Thu, 9 Feb 2023 17:00:30 +0900

package화 하게 된 계기

회사에는 그 회사만의 컬러나 디자인 시스템이 있을 것이다. 때문에 클라이언트에게 서비스하는 다양한 도메인에서 고작 버튼이라도 동일하거나 비슷한 버튼을 사용할 것이다. 그럴 때마다 동일한 코드를 계속해서 작성해서 동일한 컴포넌트를 만드는 것은 재사용성이나 유지보수 측면에서 절대 좋지 않을 것이다.

때문에 디자인 시스템이 정해진 곳이라면 모든 도메인에서 공통적으로 사용하는 컴포넌트들은 라이브러리화하여 가져다 쓸 수 있다면 정말 좋지 않을까?

그러기 위해서 아주아주 유명한 npm에 publish하여 npm install로 사용할 수도 있겠지만...

보통 회사에서는 private repo로 서비스를 관리하는데 이런 private repo를 npm에 registry하려면 돈을 내야한다. 심지어 그 private레포를 공유하는 사람 머릿수 곱하기 $7였던거 같은데 이렇게 되면 금액적으로도 큰 지출이 될 수 있기 때문에 다른 방법을 찾아야 했다.

그래서 찾은 방법이 바로 github package이다.

github package란?

npm에 publish하듯이 github에서 제공해주는 publish 기능이다. 보통 회사에서 github 유료계정을 사용하기 때문에 유료계정을 하용하게 되면 같이 제공해준다.

시작하기

1. Access Token 생성

먼저 해당 repo에 접근권한을 위해 token을 생성합니다.

순으로 진입해줍니다.

기본적으로 위와 같이 3개의 옵션을 선택해주고 나머지는 옵션으로 필요에따라 선택해주면 됩니다.

⚠️ 다들 아시겠지만 현재 화면을 벗어나면 해당 토큰값은 두 번 다시 볼 수 없으니 복사를 꼭 해줍시다!!

2. package.json 설정

프로젝트를 배포하기 위해서는 조건에 맞춰 수정해주어야 합니다.

// package.json
// 추가 설정해야할 내용들

{
  "name": @github 개인아이디 또는 github 회사 계정명/프로젝트 명
  "version": "1.0.0",
  "main": 모듈 실행하는 시작할 파일(ex. index.js)
  "scripts": {
    ...
  },
  "author" : 사용자
  "license": "MIT",(알아서)
  "repository": {
  	"type" : "git",
    "url" : 패키지화 할 repo의 github 주소
  },
  "publishConfig": {
    "registry":"https://npm.pkg.github.com"
  }
}

✅ 중요

name : @를 꼭 붙여주세요!
publishConfig : 어디에 publish 할 것인지에 대한 registry 주소 정보
=> github package repo경로를 넣으면 npm publish 할 때 npm 저장소가 아닌 github의 패키지 저장소에 저장이 됩니다.
repository: repo가 어떤 타입이고 어디인지

3.tsconfig 설정하기

//tsconfig.json
{
  "compilerOptions": {
    // Default
    "target": "es5", 
    "esModuleInterop": true, 
    "forceConsistentCasingInFileNames": true,
    "strict": true, 
    "skipLibCheck": true,

    // Added
    "jsx": "react-jsx",
    "jsxImportSource" : "@emotion/react",
    "noEmit" : false,
    "module": "ESNext",  
    "declaration": true,
    "declarationDir": "types",
    "sourceMap": true,
    "outDir": "dist",
    "moduleResolution": "node",
    "allowSyntheticDefaultImports": true,
    "emitDeclarationOnly": true,
    ...
  }
}

4. rollup 설치하기

rollup이 뭐지?

rollup 라이브러리를 설치하여 사용할 것인데, rollup은 webpack과 같은 번들링 툴인데, 각각의 JS module들을 브라우저가 이해하기 더 쉽게 하나의 source로 해준다.

또한, commonJs 모듈 형태뿐만 아니라 esModule형태로도 번들링이 가능하기에 cjs나 esm을 사용하는 곳 모두에서 사용할 수 있으므로 library처럼 범용성이 필요한 곳에서 사용하기 좋다

webpack은 esModule로 번들 불가하다.

webpack과 rollup 모두 궁극적으로는 번들링을 위한 도구이지만

일반적으로 webpack은 응용프로그램 번들에 사용되는 툴이라면 rollup은 특히 라이브러리 번들에 적합하다.

유지관리도 잘 되고 있고 해외에서는 많이 쓰이는 라이브러리화 번들링 도구이다.

https://npmtrends.com/rollu

npm trends: Compare NPM package downloads

Which NPM package should you use? Compare packages download stats, bundle sizes, github stars and more. Spot trends, pick the winner.

npmtrends.com

또한 rollup은 commonJS와 ESModule 모두에서 사용가능하도록 각각의 폴더로 번들링을 해서 생성해주기도 하는 것도 장점이다.

자, 이제 기본적으로 필요한 것들을 설치해보자

✔️ 설치하기

--기본적인 설치

@rollup/plugin-node-resolve : node_modules에서 third party module들 사용하는 용도로 사용. js외의 확장자(ts, tsx)를 불러오기 위해서도 필요함.
@rollup/plugin-typescript : typescript 지원 플러그인
@rollup/plugin-commonjs : commonJS 를 ES6로 변환해준다.
rollup-plugin-dts : d.ts파일들을 번들링 해준다.
rollup-plugin-terser: 생성된 es번들을 최소화하기 위한 플러그인

-- 필요시 추가 플러그인

+ 필요시 rollup-plugin-peer-deps-external : peerDependency로 설치된 라이브러리의 코드가 번들링 결과에 포함되지 않고 import를 통해 불러와서 사용할 수 있게 해주는 플러그인
@rollup/plugin-url: 파일을 데이터 URI 혹은 es모듈로 가져오는 플러그인
@rollup/plugin-commonjs: CommonJS 모듈을 es 모듈로 변환하는 플러그인
등등

만약 peerDependency설치를 했다면 package.json에 아래와 같이 필요한 라이브러리들을 추가해주면 된다.

//package.json
"peerDependencies": {
  "@emotion/react": "^11.5.0",
  "react": "^17.0.2",
  "react-dom": "^17.0.2"
}

npm i -D rollup @rollup/plugin-node-resolve @rollup/plugin-typescript @rollup/plugin-commonjs rollup-plugin-dts

✔️ rollup.config.mjs 세팅하기

import resolve from "@rollup/plugin-node-resolve";
import commonjs from "@rollup/plugin-commonjs";
import typescript from "@rollup/plugin-typescript";
import dts from "rollup-plugin-dts";

const packageJson = require("./package.json");

export default [
  {
    input: "src/index.ts",(경로는 사용자 환경세팅에 맞춰서)
    output: [
      {
        file: packageJson.main,
        format: "cjs",
        sourcemap: true,
      },
      {
        file: packageJson.module,
        format: "esm",
        sourcemap: true,
      },
    ],
    plugins: [
      resolve(),
      commonjs(),
      typescript({ tsconfig: "./tsconfig.json" }),
    ],
  },
  {
    input: "dist/esm/types/index.d.ts",
    output: [{ file: "dist/index.d.ts", format: "esm" }],
    plugins: [dts()],
  },
];

기본적으로 rollup 은 우리의 모듈을 번들링할 때 단 하나의 객체를 내보내는 export default 인지, 아니면 default 없이 일일이 이름을 지어서 내보내는지 추측해서 번들링 하도록 되어있다.

output.exports 의 옵션으로 default, named 아니면 none 3가지 옵션을 주고 있다.

rollup 의 권장사항은 named 이다. 애초에 코드를 작성할 때도 마지막에 export default 를 하지 않기를 권장한다.

rollup 사용을 위해 아래 코드를 package.json에 추가해주자.

//package.json

"scripts" : {
	"rollup" : "rollup -c"
}
"main" : "dist/cjs/index.js",
"module" : "dist/esm/index.js",
"types" : "dist/index.d.ts"

이후 rollup을 하게 되면

아래와 같이 output폴더로 지정해두었던 곳에 commonjs에서 사용할 수 있는 버전(?)과 esModule에서 사용할 수 있는 버전 두 가지로 다 빌드가 잘 된 모습을 볼 수 있습니다.

위의 빌드된 폴더로 npm publish를 하게되면 package.json에서 설정해두었던 publishConfig에 의해 github package로 배포가 되게 된다. github repo에 가면 우측어딘가에 아래와 같이 패키지가 생성 되어있을 것이다.

들어가보면

와 같이 마치 Npm처럼 설치 코드와 최신 버전등을 알려주고 있다.

그리고 가져다 사용하면 된다.

❗️주의 사항으로는 code상에서 수정이 이루어지고 다시 push를 할때는 package.json에 있는 version을 0.0.1 단위로 꼭 올려서 push해야 패키지가 업데이트 된다!!

가져다 사용할 때는

가져다 사용하는 곳에서는 .npmrc 를 만들고 아래와 같은 코드를 작성 후 npm install받아야 token값을 이용해 잘 설치된다.

package.json의 name에서 @뭐시기 : registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=아까 발급한 토큰값

불편함 해결

뭔가 작은 코드 수정을 하였을 때마다 version을 올려서 Push하고 잘 적용되는지 확인하고 하는 것이 많이 번거롭다...

이럴때는 local에서 확인 후 잘 적용된다면 version 올리고 push하는 방향으로 한다면 좀 더 효율적일 것이다.

나는 파일을 압축해서 local에서 npm install하는 방식으로 문제를 해결하였다.

//package.json
"scripts": {
		"publish:npm": "rm -rf ./dist && rollup -c && npm pack"
	},

이렇게 하면 라이브러리화 한 프로젝트의 root에 .tgz확장자로 된 압축파일이 하나 생성되고 이걸 Local에서 아래와 같이 가져다 사용하면 된다.

가져다 쓰고 싶은곳에서 압축파일과의 상대경로로 설치해주면 되는데,

설치하면

아까 압축한 그 파일을 마치 npm install한 것 마냥 설치해서 사용할 수 있다.

NextJS 정리(v13 이전)

MoZZANG — Mon, 30 Jan 2023 09:09:43 +0900

NextJS가 뭐죠?

https://nextjs.org/

Next.js by Vercel - The React Framework

Production grade React applications that scale. The world’s leading companies use Next.js by Vercel to build static and dynamic websites and web applications.

nextjs.org

The React Framework for the Web
NextJS는 React 프레임워크(Framework)이다.

프레임워크 vs 라이브러리

React는 라이브러리이고, NextJS는 그 React의 프레임워크라고 한다.

프레임워크와 라이브러리의 차이는 뭐지?

프레임워크 vs 라이브러리

프레임워크는 기반구조 vs 라이브러리는 개발 편의 도구들
제어 주도권을 프레임워크가 가짐 vs 제어 주도권을 사용자가 가짐
프레임워크는 기계(ex. 굴삭기) vs 라이브러리는 공구(ex. 삽, 망치)
프레임워크 자유도는 상대적으로 적음 vs 라이브러리 자유도는 상대적으로 큼

프레임워크의 장점

개인이 해야할 고민들을 프레임워크 개발자가 미리 하고 반영
특정 디자인 패턴이나 동작과 기능들을 위한 정의와 방식을 정리해둠
여러 개발자가 함께 협업할 때 기준점이 됨

Why NextJS

프론트엔드 개발자들이 가진 고민에 대한 적절한 해결책을 제공

규모가 있는 서비스 구조 설계를 어떻게 할 것인가?
개발환경 / 코드 분할 / 파일 기반 구조
SEO(검색 엔진 최적화)
프론트엔드에 필요한 간단한 API 구성
손쉬운 배포 시스템 Vercel

NextJS 시작해보기

기본적으로 nodejs가 설치되어 있어야 한다!

create-react-app과 동일한 형식으로 create-next-app을 하게되면 환경설정이 잘 된 프로젝트를 빠르게 실행해볼 수 있다.

npx create-next-app nextjs-blog

NexJS Data Fetching

NextJS가 제시하는 3 + 1가지 Data Fetching 방법

1. SSR(Server Side Render)

: 서버가 그린다

그린다 : 데이터를 가져와서 그린다

서버가 그린다 : 서버가 데이터를 가져와서 그린다

SSR을 담당하는 함수

: getServerSideProps

아까만든 CNA의 pages/index.js에서 Component 함수 바깥쪽에서 아래와 같이 getServerSideProps함수를 호출해준다.

그리고 props로 key를 time으로 value를 현재 시간으로해서 return 해주었다. 그러면 return 해준 Props들은 내부적으로 자동으로 props로 component에게 전달된다. 아래와 같이 말이다.

props로 내려온 time은 해당 component내부에서 사용할 수 있게 되는 것이다.

자 그러면 getServerSideProps가 진짜 서버에서 작동하는지 알아보기 위해 console.log('server')을 찍어두었으니 확인하러 가보자

✔️ yarn dev로 프로젝트를 Local 환경에서 실행시키고 개발자 도구를 연 후 새로고침을 해보면 console창에는 아무것도 찍히지 않는 것을 볼 수 있을 것이다. 대신 vscode의 터미널을 보게 되면 아래와 같이 server가 찍힌 것을 볼 수 있을 것이다!

새로고침을 몇번 해보아도 terminal에서만 console이 찍히는 모습을 볼 수 있을 텐데 이것이 바로 getServerSideProps라는 함수내부의 코드는 서버에서만 동작한다는 것을 알 수 있는 것이다!

2. CSR(Client Side Render)

: 클라이언트가 그린다.

그린다 : 데이터를 가져와서 그린다.

클라이언트가 그린다 : 클라이언트가 데이터를 가져와서 그린다.

즉, 브라우저가 유저가 보는 UI를 만드는 모든 것을 한다는 의미이다.

CSR을 담당하는 함수는 따로 없다. 기존 React처럼 사용하면 그것이 곧 CSR!! (ex. useEffect 등)

3. SSG(Static-Site Generation)

: 정적인 사이트를 생성한다.

생성한다 : 데이터를 가져와서 그려둔다

정적인 사이트를 생성한다 : 정적인 사이트를 데이터를 가져와서 그려둔다.

SSG를 담당하는 함수

: getStaticProps(with getStaticPaths)

index.js에 nextjs에서 제공해주는 Link 태그로 각각의 함수를 테스트 해볼 수 있도록 라우팅을 했다.(CSR도 해보려고)

NextJS는 React처럼 react-router-dom으로 라우팅을 해줄 필요 없이 폴더구조로 자동으로 라우팅이 된다.(이게 바로 프레임워크의 장점이지)

따라서 pages라는 폴더 하위에 파일들을 만들면 자동으로 라우팅시스템이 적용된다. 지금 같은 경우 /csr과 /ssg를 라우팅하려면 다음과 같이 폴더구조를 만들어주면 된다.

자 그리고 ssg.js에 가서 다음과 같이 getStaticProps함수를 이용해 data fetching 하는 척을 해보자.

⚠️ 근데 여기서 하나 주의해야하는 것이 있는데 npm run dev 그러니까 nextjs dev 로 로컬에서 실행을 시키면 마치 SSR처럼 작동하는 것을 볼 수 있다.

때문에 npm run build를 하고 npm run dev가 아닌 npm run start를 통해 실행시켜야 제대로 동작한다.

아무튼 build 후 start로 실행을 시킨 후 새로고침을 해보면 sever와 client쪽에서 모두 아무런 로그가 찍히지 않는 것을 볼 수 있다.

이는 getStaticProps는 파일을 build할 때 실행이 되기 때문이다.

이처럼 getStaticProps는 build시 데이터를 fetching받아와 정적 페이지를 만드는데 getStaticPath는 build시 어떤 어떤 것들을 SSG할 건지를 정해주는 역할을 하는 함수이다.

4. ISR(Incremental Static Regeneration)

: 증분 정적 사이트를 재생성한다.

재생성한다 : (특정 주기로) 데이터를 가져와서 다시 그려준다.

증분 정적 사이트를 재생성한다. : (특정 주기로) 정적인 사이트를 데이터를 가져와서 다시 그려준다.

쉽게 얘기해서 정적으로 만들어 놓은 사이트들도 업데이트가 가능하도록 한다는 것이다. 이를 이용한다면 정적생성의 장점을 취하되 단점을 보완할 수 있게 되는 것이다.

ISR을 담당하는 함수

: getStaticProps with revalidate

위에서 했던 방식과 동일하게 isr용 파일을 하나 만들고 getStaticProps를 호출한다.

여기서 ISR을 하기 위해서는 revalidate를 설정 해주어야 하는데, 초단위로 입력할 수 있다.

위와 같이 revalidate를 5초 주었다는 의미는

최초 페이지로 진입하게 되면 SSG에 의해 미리 만들어 놓은 페이지를 제공해준다. 이후 5초가 지나면 server에서 해당페이지의 업데이트가 이루어지고 이 업데이트가 완료되면 앞으로 새롭게 만들어진 페이지를 사용자에게 제공해주는 방식이다.

❓ 자 여기서 헷갈리고 오해할 수 있는 것이 SSG, SSR 개념이 들어가 있으니 모든 페이지 이동마다 SSR을 하는 것은 아니라는 것이다.

첫 요청하는 페이지에 대해서만 SSG 혹은 SSR로 server side에서 미리 만들어 놓은 파일을 응답하는 것이고 그 이후부터는 router를 통해 CSR로 이동하는 것이다.

Pre-render

Pre - rendering

기본적으로 NextJS는 모든 페이지를 pre-rendering 한다.

https://nextjs.org/learn/basics/data-fetching/pre-rendering

Pre-rendering과 SEO의 상관관계

CSR만 제공한다면, Client(브라우저)처럼 동작하지 않는 검색엔진의 경우 즉, JS를 해석할 수 없는 엔진에서는 아무런 데이터도 조회해갈 수 없다.

Pre-render를 해두면 Client 처럼 동작하지 않는 검색엔진에게 필요한 데이터를 제공할 수 있다.

NextJS의 pre-rendering 방식

SSG(recommended) & SSR

- SSG는 build시 pre-render

- SSR은 요청 시 pre render

사실 NextJS에서 말하는 SSG와 SSR은 server side에서 build시점에 페이지를 만들어줄까?(SSG) 아니면 요청마다 만들어줄까?(SSR)라고 볼 수 있는 것이다.

Layouts

여러 page들의 공통 처리를 위한 component로써 root에 components/Layout.js라는 파일을 만들면 NextJS가 자동으로 인식하게 된다.

이후 컴포넌트 하나를 pages/_app.js에서 활용하면 되는데 여기서의 _app.js 또한 NextJS가 제공해주는 모든 파일을 품을 수 있는 파일이라고 보면된다.

children으로 다른 페이지들을 자식요소로서 품을 수 있는 컴포넌트이다.

참고로 Layout에서는 SSR이 안된다. Layout은 컴포넌트이지 페이지가 아니기 때문이다.

그리고 아래와 같이 파일을 만들어주면 끝이다.

props로 받는 Component에는 pages의 모든 파일을이 들어올 수 있다.

SubLayout

Layout처럼 모든 페이지에서가 아닌 특정 페이지에서만 보여주고 싶은 내용이 있을 수 있다.

그럴 때는 SubLayout을 사용하면 되는데

컴포넌트에 SubLayout이라고 하나 만들어주고

홈으로 갈 수 있는 링크를 하나 만들어줘보자.

홈으로 가는 링크를 보여주고 싶은 특정 페이지에 가서 아래와 같이 만들어 주자

그리고는 _app.js로 가서 아래와 같이 분기처리(?)를 해주면 된다.

위 코드를 해석해보자면 getLayout이라는 것을 가져있으면 그것을 보여주고, 없으면 || 뒤에 것을 보여줘라 라는 의미이다.

Images

NextJS가 제공하는 최적화 Image Component

성능 향상(Improved Preformance)
Visual Stability(CLS-Cumulative Layout Shift방지)
Faster Page Loads(viewport 진입시 로드 / blur처리)
Asset Flexibility(resizing)
lazy loading

routing

Nested routes

/settings/my/info 라는 경로로 routing을 하고 싶으면 pages/settings/my/info.js 와 같이 폴더와 파일구조만 지켜주면 자동으로 routing이 된다.

Slug

파일 slug화

/category/food나 /category/item 과 같은 경우는 어떻게 하면 될까? 물론 pages/category/food.js 그리고 pags/category/item.js와 같이 필요한 만큼 파일을 만들 수도 있지만 만약 상품이 1억개라면 힘들지 않을까?

그럴 때는 slug를 사용하면 훨씬 편하게 만들 수 있다.

pages/category/[slug].js 처럼 만들면 category/ 뒤에 뭐가 오든 다 받을 수 있게 되는 것이다.

폴더 slug화

pages/[slug]/info.js와 같이 말이다. => /:username/info(ex. /jane/info)

무한 depth routing

pages/category/[...slug].js 처럼 만들면 category/ 뒤에 depth가 아무리 많아도 다 받을 수 있다.

NextJS 13버전에서 바뀐점 : https://velog.io/@hang_kem_0531/Next.js-13%EC%9D%B4-%EB%82%98%EC%99%80%EB%B2%84%EB%A0%B8%EB%8B%A4

애플 사이트 인터렉션

MoZZANG — Fri, 13 Jan 2023 13:30:31 +0900

HTML, CSS, JS => 리액트화 시 어려웠던 점

useEffect안에서 closures

뷰 포트의 스크롤에 따른 섹션인덱스 값을 관리하기 위해 addEventListener scroll을 useEffect에서 걸었는데 eventListener의 callback 함수안에서 section index값이 변하지 않는 문제를 맞이했다.

⚠️scroll Event처럼 정말 예민한(?), 변화가 엄청 많은 이벤트 콜백함수안에서 setState를 사용한다는 것은 솔직히 좋지 못한 것이라고 생각한다. 내부에서 state가 변경될 때마다 리렌더링이 일어나기때문이다. 하지만 다행히도(?) 위 콜백함수 안에서는 뷰포트에 따른 섹션이 변경될 때만 setState가 작동하므로 사용하는 것이 무리없다고 생각하였다.

자, 문제로 돌아가서

위와 같이 했을 경우 스크롤을 계속 해도 scrollLoop함수 내부에서는 sectionIndex가 계속 0인 문제가 생겼다. 하지만 함수 밖에서는 잘 증가하였다. 왜지??

찾아본 결과 react hooks 에서는 closures를 사용하고 있다고 한다.

즉, useEffect 실행시점에 scrollLoop는 sectionIndex가 0인 렉시컬 환경을 기억하고 있는 것이다. 이후에 sectionIndex가 업데이트가 되어 새로운 함수가 생성되더라도 useEffect에서 기억하는 함수는 sectionIndex가 0인 함수를 실행하기 때문이다.

⛔️ sectionIndex가 변화하지 않으면 scrollLoop안의 로직은 무의미하기 때문에 로직을 작동시킬 수 있는 변화하는 section Index값이 필요했다.

돌파구 1. - useRef()

그래서 이후 useRef를 이용하여 section Index를 관리하려고 하였다.

하지만 변화하는 section Index에 따라 chlid component에서 사용을 해야하는데 ref는 불가능 하였기에 최종적은 해결법이 아니었다.

돌파구 2. - useState와 useRef() 혼용

현재 최종적으로 선택한 방법이다.

scrollLoop 내부 로직을 돌리기위해 변화하는 section index를 ref에 담아 사용하였고 ref가 변할 때마다 sectionIndex state도 업데이트해줘서 외부에서 state값을 이용해 section index 를 참조할 수 있게 되었다.

위 방법이 최적의 방법은 아니라고 생각한다. 따라서 좀 더 좋은 방법이 있다면 업데이트 하도록 하겠다.

HTTP, 이정도면 어디가서 아는척 쌉가능

MoZZANG — Mon, 21 Nov 2022 13:57:47 +0900

HTTP가 뭥미?

HTTP란 개발자라면 한번 쯤은 들어봤을 겁니다. HyperText Transfer Protocol의 약자로, 직역하자면 HyperText(링크를 통해 다른문서로 연결될 수 있는 문서)를 Transfer(전송하는) Protocol(규격이 정해진 규칙 체계)입니다.

쉽게 얘기해보자면 인터넷 브라우저와 서버간에 이런 저런 정보를 주고 받으면서 우리가 여러 사이트들을 이용하는 건데 여기서 브라우저와 서버사이에 이런 저런 정보를 주고받을 때 다 자기스타일대로 주거니 받거니 하면 주는 쪽과 받는 쪽이 달라질 때마다 매번 서로의 방식을 물어보고 맞춰야 하는 아주 비효율적인 일이 발생할 겁니다.

때문에 정보를 주고 받을 때 국제적으로 이런 방법으로 주고 받자~ 라고 약속을 한 것이 HTTP라고 생각하면 도움이 될 겁니다.

주로 텍스트 위주의 예전 웹 페이지와는 달리, 이미지가 포함되고 그 이미지의 용량이 점점 커지고, 동영상의 수요와 공급이 증가하면서 기존의 통신 프로토콜을 변경해야 할 필요성을 느끼게 됩니다. 이로인해 현재 HTTP3 까지 발전해왔고 이에 대해 알아봅시다.

HTTP/0.9

HTTP/0.9는 One-Line Protocol로 불리며, 초기 HTTP는 버전 번호가 없는 상태로 발표되었습니다. HTTP는 요청이 단일 라인으로 구성되며 GET 메서드만이 존재했습니다. 서버에 연결되면 프로토콜, 서버, 포트는 불필요해지기 때문에 아래와 같이 아주 단순한 형태를 띄었습니다.

//Request Message
GET /mypage.html

//Response Message
<HTML>
A very simple HTML Page
</HTML>

이 때는 Header도 없었는데, HTML만이 전송될 수 있었음을 의미합니다. 또, 요청에 대한 상태나 오류 코드도 없었습니다.

HTTP/1.0

HTTP1.0은 일단 해보자는 'try-and-see' 방법으로 시작되었습니다. 서버와 브라우저에 기능을 추가했고, 상호운용성 문제가 일반적이었습니다. 1996년에 이러한 문제를 해결하고자 일반적인 관례들을 적은 문서를 발행했고, 이것을 RFC 1945라고 하며 HTTP/1.0으로 정의했습니다.

HTTP/1.0의 특징은 아래와 같습니다.

✔️ 버전 정보를 명시하기 시작

✔️ 응답에 status code 추가

브라우저가 요청에 대한 성공과 실패를 구별

✔️ 요청과 응답에 header 개념 추가

metadata 전송 허용 (metadata란? https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header , https://terms.naver.com/entry.naver?docId=1224192&cid=40942&categoryId=32840 )

유연성 및 확장성

Content-Type을 명시하면서 다른 타입의 문서도 전달가능(ex. text, gif 등)

//Request Message
GET /mypage.html HTTP/1.0
User-Agent : NCSA_Mosaic/2.0(Window 3.1)

//Response Message
200 OK
Date : Tue, 15 Nov 1994 08:12:31 GMT
Server : CERN/3.0 libwww/2.17
Content-Type : text/html
<HTML>
  A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

//Request Message
GET /mypage.html HTTP/1.0
User-Agent : NCSA_Mosaic/2.0(Window 3.1)

//Response Message
200 OK
Date : Tue, 15 Nov 1994 08:12:31 GMT
Server : CERN/3.0 libwww/2.17
Content-Type : text/gif

HTTP/1.1

HTTP/1.1은 HTTP/1.0이 나온지 몇 달 안돼서 1997년 초에 공개되었습니다. HTTP/1.0에서의 모호함을 없애고 명확한 정의를 내리게 됩니다.

✔️ 커넥션의 재사용 가능

Keep-Alive header를 통해 기존 연결과의 handshake 생략가능

✔️ Pipelining 추가

이전 요청의 응답이 완전히 전송되기 전에 다음 요청을 가능하게 해서 통신 대기 시간을 낮춤

✔️ chunk된 응답 지원

✔️ 추가적인 cache 제어 메커니즘 도입

✔️ Language, Encoding, Type 등을 포함한 컨텐츠 전송

가장 적합한 컨텐츠를 교환

✔️ Header 의 "Host" field

동일한 IP 주소에 다른 도메인을 호스트하는 기능이 가능해짐

//Request Message
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US, en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

//Response Message
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

많은 내용들이 담기고 특히 header가 무거워진 형태의 메세지를 볼 수 있습니다. HTTP/1.1은 확장성이 뛰어나서 1999년부터 새로운 RFC 문서 시리즈와 HTTP/2 release를 예견하는 상황에도 15년동안 확장되고 안정성을 유지해왔습니다. 15년 동안 변화와 확장이 일어났고, 계속해서 알아가보도록 하죠

HTTPS

TCP/IP 스택을 통해 HTTP를 전송하는 대신, 암호화된 전송 계층인 SSL(Secure Sockets Layer)을 만들었습니다. 웹에서 주소록이나 이메일, 사용자의 위치 저보나 개인정보 등에 접근하면서 점점 보안의 중요성이 대두되면서 생겨났으며, SSL은 TLS(Transport Layer Security)로 발전 해왔습니다. 혀재는 SSL이 아닌 TLS를 사용하지만, 보편적으로 SSL이라고 부르기 때문에 SSL/TLS를 혼용하여 부른다고 합니다.

RESTful API

2000년에 HTTP 사용에 대한 새로운 사용 패턴으로 REST가 등장했습니다. 표준규격이 없다는 단점이 있지만, 2010년 부터는 매우 일반적으로 사용되었습니다.

HTTP/1.1 동작 원리

왼쪽은 HTTP/1.1 Baseline 통신 규약이고, 우측은 Pipelining 기능이 도입된 통신과정입니다.

보시다시피 HTTP/1.1의 동작은 커넥션 하나를 열어 하나씩 요청을 보내야합니다. 하나의 요청이 끝나야 다음 요청을 보낼 수 있기 때문에 요청이 많을수록 비효율적입니다. 또 HTML 문서 안에 포함된 다수의 리소스(이미지, CSS, Script)를 처리하려면 요청할 리소스 개수에 비래해서 Latency가 길어지게 되죠.

하지만 파이프라이닝은 이전 요청의 응답이 끝나기 전에 다음 요청을 가능하게 해서 요청을 여러개 보낼 수 있는데 이것도 동시에 6개 정도 뿐이기 때문에 궁극적인 방법이라고는 할 수 없습니다. 때문에 요청의 수를 줄이기 위해 이미지는 스프라이트로 만들어 한 번에 받고, 걸프, 그런트 같은 번들러로 js파일이나 css파일을 하나로 합치곤 했습니다.

HTTP/1.1 단점

⚠️ HOL Blocking(Head of Line Blocking)

HTTP/1.1의 Pipelining은 한 커넥션에 순차적인 여러 요청을 연속적으로 하고, 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄였습니다. 하지만 순차적으로 응답을 받다보니 이전에 받은 응답이 길어지면 그 이후의 응답들까지 지연되는 문제점이 있죠.

예를 들어 3개의 이미지를 받기 위해 아래와 같이 순서대로 요청을 보냈다고 했을 때, 보낸 순서에 맞게 응답을 받아야 합니다.

| ---- a.png ---- |
		| ---- b.png ---- |
				| ---- c.png ---- |

a.png의 응답이 길어지면 자연스레 뒤에 있는 응답도 지연되게 되는거죠.

⚠️ RTT(Round Trip Time) 증가

HTTP/1.1의 동작원리에서 일반적으로 커넥션 하나에 요청 한 개를 처리한다고 했죠? 매번 요청 별로 커넥션을 만들고 TCP상에서 동작하는 HTTP의 특성상 HandShake가 반복적으로 일어나며, 불필요한 RTT증가와 네트워크 지연을 초래하여 성능을 지연시킬 수 있습니다.

❓RTT란, 요청을 보낼 때부터 요청에 대한 응답을 받을 때까지의 왕복 시간을 말합니다.

⚠️ 무거운 Header

HTTP/1.1은 발전을 해오면서 헤더에 많은 메타 정보들을 저장하게 되었습니다. 사용자가 방문한 웹페이지는 다수의 http요청이 발생하게 되는데, 이 경우 매 요청시 마다 중복된 헤더값을 전송하게 됩니다. 또한 해당 domain에 설정된 쿠키정보도 매 요청시 마다 헤더에 포함해서 전송되므로 성능을 저하시킵니다.

SPDY

웹 환경이 계속해서 바뀌면서(리소스 증가, 다수의 도메인, 동적 웹 서비스, 보안의 중요성 대두 등) 구글은 전송지연 문제의 해결을 집중하며 HTTP를 고속화한 새로운 프로토콜인 SPDY를 구현했습니다. SPDY는 '빠른'이라는 의미의 'speedy'라는 단어를 기반을 구글이 만든 단어로, 구글이 자신들의 'Make the Web Faster'노력의 하나로 제안한 새로운 프로토콜입니다.

SPDY는 실제로 HTTP/1.1에 비해 상당한 성능 향상과 효율성을 보여주었고 이는 HTTP/2 초안의 참고 규격이 되었습니다.

https://d2.naver.com/helloworld/140351

SPDY의 특징을 정리하면 아래와 같은데 개념적인 부분은 HTTP/2와 겹치는 부분이 많습니다.

✔️ 항상 TLS 위에서 동작

HTTPS로 작성된 웹 사이트만 적용 가능

✔️ HTTP header 압축

요청이 많아질 수록 압축률 증가, 대역폭이 작은 모바일 환경에서 효과 증대

✔️ 텍스트가 아닌 binary protocol

파싱이 더 빠르고, 오류 발생 가능성이 낮음

✔️ Multiplexing

하나의 connection 안에서 다수의 독립적인 stream을 동시에 처리

✔️ Full-duplex interleaving & prioritization

다른 stream이 끼어드는(interleaving) 것을 허용

결국, SPDY는 HTTP의 데이터 전송 포맷과 connection 관리 부분을 고쳐서 TCP connection을 보다 효율적으로 쓰도록 만든 것이라 볼 수 있습니다.

위에서 언급했듯, SPDY는 HTTP/2의 참고 규격이 되었습니다. 때문에 비슷한 구조가 많습니다. 그래서 위 특징들의 대부분이 HTTP/2에서도 보이고 있습니다.

HTTP/2

HTTP/2 공식 github 페이지의 서문을 보면 HTTP/2의 목적을 명확히 알 수 있다.

HTTP/2 is a replacement for how HTTP is expressed “on the wire.” It is not a ground-up rewrite of the protocol; HTTP methods, status codes and semantics are the same, and it should be possible to use the same APIs as HTTP/1.x (possibly with some small additions) to represent the protocol.

The focus of the protocol is on performance; specifically, end-user perceived latency, network and server resource usage. One major goal is to allow the use of a single connection from browsers to a Web site.

The basis of the work was SPDY, but HTTP/2 has evolved to take the community’s input into account, incorporating several improvements in the process.

https://http2.github.io/

요약하자면 완전히 새로운 프로토콜이 아닌 SPDY의 개선사항을 적용해 수정된 성능향상에 초점을 맞춘 프로토콜이라고 할 수 있다.

HTTP/2의 특징들은 다음과 같습니다.

✅ Multiplexed Streams

HTTP/2는 하나의 TCP 연결을 통해 여러 데이터 요청을 병렬로 전송할 수 있습니다.

HTTP/2는 Multiplexed Streams를 이용하여 connection 한 개로 동시에 여러 개의 메세지를 주고 받을 수 있으며 응답은 순서에 상관없이 stream으로 주고 받습니다. RTT 시간이 줄어들어 별도의 최적화 과정이나 도메인 sharding 없이 웹 사이트 로드 속도가 빨라집니다. HTTP/1.1의 connection Keep-Alive, Pipelining의 개선된 점도 볼 수 있습니다.

✅ Header Compression

HTTP/2는 중복 헤더 프레임을 압축해서 전송합니다. HPACK 규격을 사용하는데, 클라이언트와 서버에서 모두 이전 요청에 사용된 헤더 목록을 유지관리합니다. HPACK은 서버로 전송되기 전에 각 헤더의 개별 값을 압축한 다음 이전에 전송된 헤더 값 목록에서 인코딩된 정보를 조회하여 전체 헤더 정보를 재구성합니다.

모바일과 같이 업로드 대역폭이 상대적으로 작은 경우에는 이런 HTTP 헤더 압축방법이 특히 유용합니다.

✅ Binary Protocol

텍스트 프로토콜에서 바이너리 프로토콜로 변화했습니다. 기존 HTTP/1에서 사용된 frame의 복잡성을 편리하게 해주고, 텍스트와 공백들이 섞여 혼동이 발생하던 명령들보다 명령어를 단순하게구현할 수 있습니다. HTTP/2구현을 사용하는 브라우저는 네트워크를 통해 전송하기 전에 동일한 텍스트 명령을 바이너리로 변환합니다.

Binary protocol의 장점

✔️ 데이터의 parsing이 더 빠르고, 오류 발생 가능성이 낮음

✔️ 네트워크 리소스의 효과적 사용

네트워크 지연 시간 줄이고 처리량 개선

✔️ 텍스트 특성과 관련된 보안 문제를 해결할 수 있음

✔️ HTTP/2의 다른 기능을 활성화

압축, 멀티플렉싱,우선 순위 지정, 흐름 제어 및 TLS의 효과적인 처리 등

✅ Server Push

서버는 요청되지 않았지만 향후 요청에서 예사오디는 추가 정보를 클라이언트에 전송할 수 있습니다.

예를 들어, 클라이언트가 리소스 X에 대해 요청하고 리소스 Y가 요청된 X파일에서 참조되는 경우, 서버는 클라이언트 요청을 기다리는 대신 X와 함께 Y를 푸시하도록 선택할 수 있습니다.

Server Push의 장점

✔️ 클라이언트는 푸쉬된 리소스를 캐시에 저장

캐시된 리소스를 여러 페이지에 걸쳐 재사용할 수 있음

✔️ 서버는 멀티 플렉싱으로 요청한 정보와 함께 푸시된 리소스를 전송가능

✔️ 서버는 푸시되는 리소스의 우선 순위를 지정할 수 있음

✔️ 클라이언트의 선택적 리소스 관리

푸시된 리소스를 거부하거나 서버 푸시를 비활성화 할 수 있음

✔️ 클라이언트가 멀티플렉싱되는 푸시 스트림 수 제한 가능

✅ Stream Prioritization

클라이언트가 선호하는 응답 수신 방식을 지정해서 응답을 받을 수 있습니다. 문서 내에 CSS 파일 1개와 이미지 파일 2개가 존재하고 이를 클라이언트가 요청한다고 해봅시다. 이미지 파일보다 CSS파일의 수신이 늦어진다면 브라우저 렌더링에 문제가 생기게 될 수 있는데, HTTP/2에서는 이러한 상황을 고려하여 리소스 간의 의존관계에 따른 우선순위를 설정하여 리소스 로드 문제를 해결할 수 있습니다.

자 그럼 단점은 없느냐

HTTP/2 단점

하지만 HTTP2는 여전히 TCP를 이용하기 때문에 Handshake의 RTT(Round Trip Time)로인한 Latency(지연시간), TCP의 HOLB 문제는 해결 할 수 없습니다.

사실 HTTP 레벨에서의 HOLB와 TCP 레벨에서의 HOLB는 다른 의미이기는 하나 결국 어떤 요청에 병목이 생겨서 전체적인 레이턴시가 늘어난다는 맥락으로 본다면 동일하다고 할 수 있습니다.

TCP를 사용한 통신에서 패킷은 무조건 정확한 순서대로 처리되어야 한다. 수신 측은 송신 측과 주고받은 시퀀스 번호를 참고하여 패킷을 재조립해야하기 때문입니다.

그래서 통신 중간에 패킷이 손실되면 완전한 데이터로 다시 조립할 수 없기 때문에 절대로 그냥 넘어가지 않죠. 무조건 송신 측은 수신 측이 패킷을 제대로 다 받았다는 것을 확인한 후, 만약 수신 측이 제대로 패킷을 받지 못했으면 해당 패킷을 다시 보내야 합니다.

또한 패킷이 처리되는 순서 또한 정해져있으므로 이전에 받은 패킷을 파싱하기 전까지는 다음 패킷을 처리할 수도 없습니다. 이렇게 패킷이 중간에 유실되거나 수신 측의 패킷 파싱 속도가 느리다면 통신에 병목이 발생하게 되는 현상을 HOLB라고 부릅니다. 이건 TCP 자체의 문제이므로 HTTP/1 뿐만 아니라 HTTP/2도 가지고 있는 문제입니다.

HTTP/3

가장 큰 특징은 TCP가 아닌 UDP를 사용한다는 것입니다.

정확히 말하면 HTTP3는 QUIC이라는 프로토콜 위에서 돌아가는 HTTP인데,

여기서 QUIC이란

Quick UDP Internet Connection의 약자로 UDP를 기반으로 TCP + TLS + HTTP의 기능을 모두 구현하는 프로토콜입니다.

구글에서 개발했던 SPDY 기술이 HTTP/2의 기반 기술이었는데 역시 구글에서 개발한 QUIC이 HTTP/3의 기반 기술이 되었습니다.

구글이 QUIC을 만들 때 UDP를 선택한 이유에는 기존의 TCP를 수정하기가 어려운데다가, 백지 상태나 다름없는 UDP를 사용함으로써 QUIC의 기능을 확장하기 쉬웠기 때문이라고 한다.

때문에 QUIC을 사용하므로써 나오는 HTTP/3의 장점은 다음과 같다.

HTTP/3 특징 및 장점

✔️ RTT감소로 인한 지연시간(Latency) 단축

QUIC은 TCP 사용하지 않기에 3 Way Handshake과정 불필요 => 기존 TCP 연결 +TLS 까지 = 3RTT 필요

QUIC은 첫 연결설정에 1RTT만 필요 => 연결 설정에 필요한 정보와 함께 데이터도 보내버리기 때문

그리고 한번 연결에 성공했다면 서버는 그 설정을 캐싱해놓고 있다가,다음 연결때는 캐싱해놓은 설정을 사용하여 바로 연결을 성립시키기 때문에 0RTT 필요

✔️ 패킷 손실 감지에 걸리는 시간 단축

QUIC은 header에 별도의 패킷 번호 공간을 부여해 패킷 고유의 번호를 가지고 있는다.

✔️ Multiplexing 지원

HTTP/2와 동일하게 지원

✔️ 클라이언트의 IP가 바뀌어도 연결이 유지됨

TCP의 경우 소스의 IP주소와 포트, 연결 대상의 IP 주소와 포트로 연결을 식별하기에 클라이언트의 IP가 바뀌는 상황이 발생하면 연결이 끊어짐 => 다시 연결위해 handshake 거쳐야 하고, 이 과정에서 다시 latency가 발생

반면 QUIC은 connection ID를 사용하여 서버와 연결을 생성한다. connection ID는 랜덤한 값일 뿐, 클라이언트의 IP와는 전혀 무관한 데이터이기 때문에 클라이언트의 IP가 변경되더라도 기존의 연결을 계속유지할 수 있다.

참고문서

https://http2.github.io/

https://velog.io/@ziyoonee/HTTP1-%EB%B6%80%ED%84%B0-HTTP3-%EA%B9%8C%EC%A7%80-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

https://gngsn.tistory.com/99

https://velog.io/@ziyoonee/HTTP1-%EB%B6%80%ED%84%B0-HTTP3-%EA%B9%8C%EC%A7%80-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

https://woojinger.tistory.com/85

[TS]함수에 사용하는 never 타입도 있긴 합니다

MoZZANG — Mon, 7 Nov 2022 14:45:12 +0900

Never type 을 알아보자

함수에 붙이는 return type으로 사용가능합니다.

근데 좀 특이합니다.

function 함수() :never{

}

어떤 함수가

조건 1) 절대 return을 하지 않아야하고

조건 2) 함수 실행이 끝나지 않아야합니다 (전문용어로 endpoint가 없어야합니다)

그런 함수에 붙일 수 있는 타입니다.

실은 조건1, 2는 같은 소리인데 모든 자바스크립트 함수 맨 밑엔 return undefined 라는 숨겨진 코드를 가지고 있습니다.

그래서 조건2가 맞으면 1도 맞음

function 함수(){
  console.log(123)
}

이런 함수들에 never를 붙일 순 없습니다.

왜냐면 조건 1번은 만족하지만 2번은 만족하지 않습니다.

2번 조건은 함수 내부 코드 실행이 끝나지 않는 함수여야합니다.

function 함수() :never{
  while ( true ) {
    console.log(123)
  }
}

이런 함수엔 붙일 수 있습니다.

while 문법은 ( ) 소괄호안의 조건식이 true일 경우 계속 내부 코드를 실행해라~ 라는 뜻입니다.

무한히 실행되기 때문에 끝이안나죠? 그래서 never 타입을 사용가능합니다.

function 함수() :never{
  throw new Error('에러메세지')
}

이런 함수에도 붙일 수 있습니다.

throw new Error() 문법은 그냥 강제로 에러내라~ 라는 뜻인데

에러가 나면 전체 코드실행이 중단되니까 2번 조건도 나름 충족하는 것이기 때문에

never를 사용가능합니다.

그래서 1. 무언가 return 하지 않고 2. 끝나지도 않는 함수를 표현하고 싶을 때 never 타입을 지정하면 되는데

2번 조건의 함수를 만들 일이 거의 없기 때문에 never 타입은 쓸 일이 없습니다.

무언가를 return하고싶지 않을 경우 그냥 void 타입을 이용하시면 되며

배우는 이유는 가끔 코드 이상하게 짜다보면 자동으로 등장하기 때문입니다.

이 때 never 이게 뭘 의미하는지 이해만 잘 하면 됩니다.

어떨 때 등장하는지 알아봅시다.

파라미터가 never 타입이 되는 경우도 있음

function 함수(parameter: string) {
  if ( typeof parameter === "string"){
    parameter + 1;
  } else {
    parameter;
  }
}

위 함수는 뭔가 이상한 함수입니다.

지금 narrowing을 이용해서 파라미터의 타입이 string 이면 뭔가 해달라고 써놨는데

else 문이 존재합니다. 타입이 string이 아닐 경우 이거 해달라는 뜻입니다.

근데 else문은 말이 안되죠? 지금 파라미터가 string 밖에 못들어오는데 말입니다.

이런 잘못된 narrowing을 사용했을 때 파라미터의 타입이 never로 변합니다. 파라미터에 마우스 올려보셈

이런 건 있을 수 없다, 일어나면 안된다고 알려주는 느낌입니다.

그럴 때 never를 구경할 수 있으니 never 타입이 발견되는 경우 코드를 수정하는게 어떨까요.

자동으로 never 타입을 가지는 경우

자바스크립트는 함수를 만드는 방법이 2개 있습니다.

function 함수(){

}

let 함수2 = function (){

}

위는 함수 선언문,

밑은 함수 표현식이라고 부릅니다. 똑같이 함수만들 수 있는 문법입니다.

function 함수(){
  throw new Error()
}

let 함수2 = function (){
  throw new Error()
}

함수 선언문이 아무것도 return 하지 않고 끝나지도 않을 경우 void 타입이 자동으로 return 타입으로 할당되며

함수 표현식이 아무것도 return 하지 않고 끝나지도 않을 경우 never 타입이 자동으로 return 타입으로 할당됩니다.

마우스 올려보면 나옵니다.

또는 tsconfig.json에서 strict 옵션을 켜둘 경우

함부로 any 타입을 지정해주지 않는 경우가 있습니다.

그럴 때 array 같은거 대충 타입지정 안하고 만들면

let arr = [];

원래는 any[] 이런 타입이 되는데 any를 가질 수 없어서

never[] 이런 타입이 발견되기도 합니다.

아무튼 쓸 일이 별로 없기 때문에 이럴 때도 등장한다고 알아두기만 하면 됩니다.

<출처 : 코딩애플 - 빠르게 마스터하는 타입스크립트>