먼저 id값에 int보다는 long을 더 선호하는 이유는

1. 범위 자체가 더 넓기 때문에 db에 저장되는 레코드 양이 많아질 수록 더욱 안전
2. 서비스가 성장하면서 데이터 양이 많아지면 추후 발생할 수 있는 id 충돌 문제 예방 가능

-> 즉, 데이터베이스 규모 + 추후 확장성까지 고려해 사용하게 되는 것

본론으로 돌아와서 long형과 Long형의 차이점을 알아보자

long

• 원시 타입(primitive type) : 메모리에서 직접 값 저장하는 자바의 기본 데이터 타입
• 기본타입이기 때문에 null값 가질 수 없음
• 직접 값을 할당하기 때문에 참조 타입에 비해 성능 좋음

Long

• 참조 타입(wrapper class) : 메모리 주소값으로 객체를 참조하기 때문에 null값 가질 수 있음
• db상 id 설정되지 않았을 경우 유용
• 기본 타입-객체 타입 간 자동 변환(박싱&언박싱) 지원
• 상대적으로 속도 느림

➡ 그렇다면 엔티티 객체 ID에는 어떤 타입이 적합할까?

기본적으로 Long 사용하는 것이 일반적

• 유연성 : id가 null일 수 있는 경우
• ORM 프레임워크 호환성 : JPA나 Hibernate 같은 ORM에서는 관행상 Long으로 선언

그러나!! 해당 객체가 not null 보장이 된다면 long 사용하는 것이 더 좋음

OCP(Open-Closed Principle)

개방-폐쇄 원칙

확장에는 열려있고, 수정/변경에는 닫혀있다

스프링의 DI를 사용하면 기존 코드를 전혀 손대지 않고, 설정만으로 구현 클래스를 변경할 수 있다 데이터를 DB에 저장하기 때문에 스프링 서버를 다시 실행해도 데이터가 안전하게 저장된다

출처 : 김영한님 스프링 입문 강의

assertThat()은 Assertions라는 클래스에서 import해주어야 인식이 되는데 org.junit.jupiter.api.Assertions가 아니라 org.assertj.core.api의 Assertions를 import 해주어야 한다

따라서 이 클래스에 속한 정적 메서드인 assertThat()을 입력했을 때

이런식으로 클래스명까지 붙어서 나타나게 된다 ➕ 자동완성도 불가..

이럴 땐 Assertions 뒤에 커서를 놓고, [Alt] + [Enter]로 static import를 해주면 된다!

그럼 아래처럼 깔끔하게 assertThat() 메서드만 표시되는 것을 알 수 있다

정적 임포트

하지만!!!!!!!!!! 공식 문서에 따르면 static import는 되도록이면 지양하라고 되어있다

So when should you use static import? Very sparingly!

출처 : https://docs.oracle.com/javase/1.5.0/docs/guide/language/static-import.html

그리고 *을 사용해 전체를 받아오는 것도 권장하지 않는다고 되어있다

+++ 내용 추가 예정

Settings - Editor - Live Templates 에서 '+'를 눌러서 커스텀 라이브 템플릿을 추가해주면 된다 !

나는 아래와 같이 가장 기본적인 틀로 구성했다

• @Test 어노테이션
• 리턴타입 void
• 괄호
• //given, //when, //then

이제 test만 입력하더라도 기본 테스트코드 템플릿이 자동으로 입력되는 것을 확인할 수 있다 😊

🔎 모듈(Module)이란

• 특정 기능이나 책임을 가진 코드의 집합
• 소프트웨어 개발에서 코드의 구성 단위
• 각 모듈은 독립적이면서도, 다른 모듈과 상호작용 가능
• 보통 파일이나 디렉토리 단위로 나누어 관리
  

조금 더 쉽게 생각해보자 개발을 하면서 규모가 커지면 파일을 여러 개로 분리해야 하는데, 이때 분리된 파일을 각각 모듈이라고 한다 ➡ 파일 하나 또는 특정 기능을 갖는 작은 코드 단위를 의미 ➡ 목적별로, 기능별로 여러 개의 파일로 분리해 관리 가능 ➡ 이렇게 모듈로 분리하는 과정 : 모듈화

❓ 모듈이 왜 필요할까

1. 코드의 재사용성 모듈화된 코드는 다른 프로젝트나 애플리케이션에서 재사용 가능 ➰ ex. 유틸리티 함수 or 라이브러리 모듈 ➡ 여러 프로젝트에서 사용 가능
2. 유지보수성 특정 모듈만 수정해도 나머지 코드에는 영향 ❌ ➡ 버그 수정/기능 추가 용이
3. 네임스페이스 변수와 함수가 모듈 범위 내에서만 유효하기 때문에 전역 네임스페이스 오염 방지 가능 ➡ 코드 충돌 ⬇, 코드 안정성 ⬆
4. 의존성 관리 모듈 간 의존성 명확하게 정의하고 관리 가능 각 모듈이 필요한 다른 모듈을 명시적으로 선언하기 때문에 의존성 추적/관리 더욱 용이
5. 조직화 매우 방대한 대규모 애플리케이션에서 코드를 기능별로 나누어 체계적 구성/관리 가능
   

🔎 모듈 번들러(Module Bundler)

모듈 번들링

웹 애플리케이션을 구성하는 수많은 자원들을 하나로 병합/압축해주는 동작

모듈 번들러

번들링을 할 수 있게 합쳐주는 도구 ➡ 여러 개의 파일을 하나의 파일로 합쳐주는 역할

❓ 모듈 번들러는 왜 필요할까

모듈을 이용하려면 모든 파일을 네트워크 통신을 통해 가져와야 한다 파일 하나하나를 요청하고 가져온다면 로딩 속도는 당연히 느려질 것 추가로, 웹 서비스를 개발/배포할 때 HTML, CSS, JS 압축, 이미지 압축, CSS 전처리기 변환 등과 같은 작업을 해야했기 때문에, 로딩 속도를 개선함과 동시에 이런 작업들을 자동화해주는 도구들이 필요했다!

✅ 최신 프론트엔드에서 가장 많이 사용되고 있는 웹팩(Webpack)이 모듈 번들러 중 하나

🔎 웹팩이란?

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

주로 자바스크립트 애플리케이션의 파일을 관리하고, 여러 모듈을 하나의 번들로 묶어주는 역할 -> 웹 개발에서 많이 사용

주요 기능

1. 모듈 번들링 웹 애플리케이션에서 사용하는 자바스크립트 파일, css, 이미지 등을 하나의 파일 또는 여러 개의 파일로 묶어 웹 브라우저가 효율적으로 로드할 수 있도록 함

2. 코드 스플리팅 애플리케이션의 크기를 줄이기 위해 필요한 코드만 로드할 수 있게 해줌 ➡ 페이지에 필요한 코드만 로드하고, 나머지는 필요할 때 로드하는 방식

3. 트랜스파일링 최신 자바스크립트 문법을 구형 브라우저에서도 호환되도록 변환 ➰ ex. Babel 사용 ➡ ES6 문법을 ES5로 변환

4. 플러그인과 로더 다양한 플러그인과 로더를 통해 번들링 과정에서 파일을 변환하거나 다양한 파일 포맷 지원 ➰ ex. css파일을 자바스크립트 파일에 통합, 이미지 파일을 인라인으로 처리

5. 디버깅과 최적화 개발 과정에서의 디버깅을 용이하게 하고, 배포 시 파일 크기를 줄여 성능 최적화

Webpack 설정 파일

Vue3 이상부터는 웹팩 설정 파일을 /node_modules/@vue/cli-service/webpack.config.js 디렉터리에 넣어놓았다

✅ 해당 설정 파일 안의 내용들은 디폴트값들이다. 프로젝트를 진행하면서 webpack 설정 파일은 아직 건드리지 않았기 때문..! ✅ 멘토님이 피드백 주시면서 이런 설정 파일 안에서 속성값들을 지정해주어야 동작하는 부분들도 있다고 하셔서 webpack에 대해서 조금 더 깊게 공부를 해봐야 할 것 같다 !!! ✅ 어제 간단히 설명을 들었을 때에는 모듈 번들링과 트랜스파일링 기능에 집중해서 들었는데, 다른 기능들도 수행하고 요즘 프론트 개발에서 많이 쓰이는 기능이라고 하니 어떤 역할을 하는지에 대해서 혼자 더 공부해봐야 될 것 같다 💪🏻

문제

remote: Permission to <git url> denied to <github 계정>
fatal: unable to access '<git url>/': The requested URL returned error: 403

너무 정신없어서 캡쳐를 못했는데, 기억을 더듬어 작성해보자면 이런 식의 오류였다

원인

검색을 하며 찾아보니 명확한 답변은 나오지 않았고, 유추를 해보자면

1. 이전에 사용하던 git 계정 기록이 내 노트북에 남아있고
2. 그 계정이 내 컴퓨터(로컬)에 저장되어 있어 모든 tool에는 그 계정이랑 연동이 되어있는 듯..? 했다
3. 실제로 이번 교육과정에 참가하면서 블로그도 새로 시작하고, 각종 계정들을 다른 구글 계정으로 변경해서 사용하는 중이었음

해결

제어판 ➡ 사용자 계정 ➡ 자격 증명 관리 ➡ 웹 자격 증명 관리 ➡ github 웹 계정 선택 후 삭제

해당 과정을 거친 후 다시 현재 사용하는 github 계정으로 연동해주었더니 push 명령 시 오류가 발생하지 않았음

Model-View-Controller 구조의 디자인 패턴 사용자 인터페이스, 데이터 및 논리 제어 구현

1. 모델(Model) : 데이터와 비즈니스 로직 관리
2. 뷰(View) : 레이아웃과 화면 처리
3. 컨트롤러(Controller) : 사용자의 입력 처리와 흐름 제어 담당, 모델과 뷰로 명령 전달

➡️ 사용자가 컨트롤러를 조작하면 컨트롤러는 모델을 통해 데이터를 가져오고, 그 데이터를 바탕으로 뷰를 통해 시각적 표현을 제어해 사용자에게 전달

💬 [web]에 적용하면

1. 사용자가 웹사이트에 접속
2. 컨트롤러는 사용자가 요청한 웹페이지를 제공하기 위해 모델 호출 -> Manipulates
3. 모델은 데이터베이스나 파일과 같은 데이터 소스 제어 후 결과 리턴
4. 컨트롤러는 모델이 리턴한 결과를 뷰에 반영 -> Updates
5. 데이터가 반영된 뷰는 사용자에게 보여짐

❓ MVC 패턴 사용 이유

• 비즈니스 로직과 UI 로직 분리 -> 독립적인 유지보수
• 모델과 뷰가 다른 컴포넌트에 종속되지 않음 -> 애플리케이션 확장성/유연성
• 중복 코딩 문제점 제거

API 인증 (API Authentication)

: API를 호출하는 대상을 확인하는 절차

API 인증 방식

• API Key 방식
• API Token 방식

➡️ 인증 방식에 따라 구현 난이도와 보안 수준이 달라짐!

API key란?

특정 사용자만 알 수 있는 문자열

• 개발자는 API key를 발급 받고 API key를 메세지 안에 입력해 API 호출
• 서버는 메세지 안의 API key를 읽고 누가 호출한 API인지 인증

그런데!!

이 API key로 인해 과금이 발생할 수 있음

✔️ 내 프로젝트에 필요한 API 과금 기준을 잘 확인 후 활용해야 하고 ✔️ 사용자가 얼마나 자주 API를 호출했는지 확인할 때도 API key가 사용되기 때문에 ✔️ API key는 나만 알 수 있는 곳에 보관해야 함

❓ 왜 HTTP 요청이 필요한가

1. 데이터 전송

웹 애플리케이션은 보통 서버-클라이언트 간 데이터를 주고받음 ex. 유저 로그인 정보, 상품 목록, 유저 프로필 등

2. 비동기 통신

페이지를 다시 로드하지 않고 데이터 갱신 가능 -> 사용자 경험 향상

3. 서버와의 상호작용

CRUD 작업을 서버와 통신하여 처리

❓ 왜 axios나 fetch를 사용하는가

1. 편리성

이 라이브러리들은 HTTP 요청을 쉽게 보낼 수 있는 인터페이스 제공

2. 에러 핸들링

HTTP 요청 성공/실패에 대한 적절한 처리 가능

3. 비동기 처리

Promise 또는 async/await 사용해 비동기 작업 간편하게 관리 가능

4. 유연성

다양한 요청 설정이 쉬움 ex. 헤더 추가, 타임아웃 설정, 요청 취소 등

5. 인터셉터

요청이나 응답을 가로채 공통적인 작업 수행 가능 ex. 인증 토큰 추가, 로깅 등

⚡ 운영환경에서의 중요성

• 데이터 통신 대부분의 현대적인 웹 애플리케이션은 서버-클라이언트 간 데이터 통신이 빈번하게 발생 -> 안정적이고 효율적인 HTTP 클라이언트 필수적
• 유지보수 코드의 가독성과 유지보수성 측면에서 반복적인 HTTP 요청 코드를 깔끔하게 관리
• 성능 최적화 필요에 따라 요청 최적화, 불필요한 요청 최소화 -> 성능 개선

• Vue Resource
• GraphQL
• Firebase
• Socket.io
• RESTful 라이브러리들
  

그렇다면! 현재 진행하고 있는 프로젝트에는 axios와 fetch 중 어떤 것을 사용해야할까?

✅ 장단점을 분석해보자

Axios

장점

1. 간편한 사용법 XMLHttpRequest를 기반으로 한 라이브러리 -> 사용하기 쉬운 API 제공
2. 자동 JSON 변환 요청 및 응답 데이터를 자동으로 JSON으로 변환
3. 인터셉터 요청이나 응답을 가로채 로깅이나 인증 토큰 추가 등의 작업 쉽게 수행
4. 더 많은 기능 요청 취소, 타임아웃 설정, 응답 데이터 변환 등 fetch에 비해 더 많은 기능 제공
5. Node.js 지원 서버사이드에서도 동일한 API 사용 가능

   단점

6. 파일 크기 외부 라이브러리이기 때문에 프로젝트 빌드 크기 약간 증가
7. 의존성 추가적인 외부 라이브러리에 의존

Fetch

장점

1. 내장 함수 최신 브라우저에 내장된 기능이기 때문에 별도 설치 필요 X
2. Promise 기반 비동기 작업 관리 쉬움
3. 브라우저 친화적 최신 브라우저 환경에서는 네이티브로 지원되어 최적화

   단점

4. 지원 브라우저 구형 브라우저에서는 폴리필 필요 // todo - 폴리필 설명 추가
5. JSON 변환 필요 응답을 JSON으로 변환하려면 추가 처리 필요 ex. response.json()
6. 기능 제한 기본 기능만 제공하기 때문에 인터셉터나 자동 변환 등의 기능은 직접 구현
7. 에러 핸들링 네트워크 에러는 Promise를 거부하지만, 404나 500 같은 HTTP 에러는 거부하지 않기 때문에 추가 처리 필요

💡 결론

• 간편함과 기능성 -> axios
• 경량성과 최신 브라우저 지원, 기본적인 기능만 필요 -> fetch

궁금해서 gpt한테 물어봄 !

<답변>

vue 프로젝트에서 이미지 파일을 어디에 저장할지는 목적에 따라 달라진다

1. public 폴더

용도

• 정적 파일 저장
• 빌드 시점에 별도로 처리되지 않고, 그대로 출력 폴더(dist)로 복사

접근 방식

• public 폴더에 있는 파일은 절대경로로 접근 X

ex. public/logo.png

<img src='/logo.png'>

example

• 웹사이트 로고, 파비콘(favicon), 메타 태그에 사용되는 이미지 등
• 프로젝트 구조와 무관하게 고정된 위치에서 접근해야 하는 파일

2. src/assets 폴더

용도

• 웹팩(webpack)으로 처리되는 파일 저장
• 빌드 과정에서 웹팩에 의해 처리되고, 필요에 따라 최적화

접근 방식

• JavaScript나 Vue 컴포넌트 내에서 import 구문 사용해 접근

ex. src/assets/logo.png

import logo from '@/assets/logo.png';

example

• 컴포넌트 내에서 사용되는 이미지, 동적으로 불러오는 이미지 등
• 빌드 프로세스의 일부로 처리되어야 하는 파일

wrap-up

정적파일(고정된 경로에서 접근해야 하는 이미지) -> public 컴포넌트/자바스크립트 파일 내에서 사용되는 이미지 -> src/assets

➰ 프로젝트의 유지보수성과 효율적인 파일 관리 가능 ➰ 프로젝트의 요구사항에 맞게 두 폴더를 적절히 활용