[면접카타]
다음의 정렬을 설명하고 본인이 가장 편한 언어를 사용하여 로직을 구현해주세요.
- 병합 정렬(Merge Sort)
- 분할(Divide)
- 입력 배열을 같은 크기의 2개의 부분 배열로 분할한다.
- 정복(Conquer)
- 부분 배열을 정렬한다.
- 결합(Combine)
- 정렬된 부분 배열을 하나의 배열에 병합한다.
- 삽입 정렬(Insertion Sort)
Unexpected non-whitespace character after JSON at position 360 (line 1 column 361)
- JSON 파일에 잘못 입력된 값이 있었음 ➡️ 해결 완료
Error: The incoming JSON object does not contain a client_email field
- 인증 JSON 파일이 잘못 설정되어 있었다.
- 이전 프로젝트에서 사용했던 인증 파일이었고, 현재 프로젝트에서 사용하는 인증 파일을 다시 발급받아 경로 설정해주니 잘 해결됐다.
하지만 현재 지정된 이미지 파일에 대해서 분석했을 때, Label이 제대로 출력되고 있지 않은 것을 확인할 수 있다.
제대로 된 파일이 지정됐는지 확인하기 위해 파일명을 콘솔에 찍어보았다.
bucketName과 fileName이 제대로 지정되지 않았음을 알 수 있다.
코드에서 지정한 값이 그대로 입력되어 있는데, multipart를 통해 원하는 파일을 선택할 수 있도록 코드를 수정하는 것이 필요할 것 같다.
Q. DB와 연동하는 과정이 필요할 것으로 보인다. 코드 상에서는 경로만 지정해주도록 하고, 데이터는 실제 DB와
연동해서 데이터 처리를 해줄 수 있도록 한다. 현재 S3에서 데이터 처리를 해주고 있는 것으로 알고 있는데,
Google Cloud Storage에서 데이터 처리를 해주는 것으로 변경하려면 추가적인 과정이 필요할 것 같다.
근데 이러면 S3와 Google Cloud Storage를 동시에 사용하게 되는데, 여러 DB를 사용하는 것이 과연 적절한
구현 방법인지에 대한 의문이 든다.
문제 해결을 위해 여러분의 질문을 세부적으로 나누어 보겠습니다. 여기서 다루는 주요 포인트는 다음과 같습니다:
1. Label 출력 문제: 이미지 파일 분석 시 제대로 된 Label이 출력되지 않는 문제.
2. 파일 지정 문제: bucketName과 fileName이 제대로 지정되지 않은 문제.
3. Multipart를 통한 파일 선택: 파일 선택을 사용자가 할 수 있도록 코드 수정 필요성.
4. DB와의 연동: 데이터 처리를 위해 DB와의 연동 고려.
5. S3와 Google Cloud Storage 동시 사용: 여러 DB 사용의 적절성에 대한 의문.
1. Label 출력 문제
문제의 원인은 여러 가지가 있을 수 있습니다. 가장 먼저 확인해야 할 것은 이미지 파일이 올바르게 지정되었고,
해당 파일이 올바른 형식과 내용을 가지고 있는지 입니다. 이미지 처리에 사용되는 라이브러리나 도구가 올바르게
설치되어 있고, 최신 버전인지도 확인해야 합니다. 또한, Label을 추출하는 로직이 올바르게 구현되어 있는지
검토해야 합니다.
2. 파일 지정 문제
bucketName과 fileName이 제대로 지정되지 않았다면, 입력 파라미터를 확인해야 합니다. 코드 상에서
하드코딩된 값이 아니라 사용자 입력이나 다른 메커니즘을 통해 동적으로 입력받는 경우, 입력 과정에서의
오류 가능성을 검토해야 합니다. 정확한 값을 지정하기 위해 사용자 인터페이스에서 선택한 파일의 정보를
정확하게 전달하도록 하는 것이 중요합니다.
3. Multipart를 통한 파일 선택
웹 애플리케이션에서 사용자가 파일을 선택하고 업로드할 수 있도록 하려면, <form> 태그의 enctype 속성을
multipart/form-data로 설정해야 합니다. 이후 서버 측에서는 multipart 요청을 처리할 수 있는 로직을
구현해야 합니다. 예를 들어, Java Spring에서는 MultipartFile 인터페이스를 사용하여 파일을 처리할 수
있습니다.
4. DB와의 연동
DB와의 연동은 데이터를 안정적으로 저장하고 관리할 수 있게 해줍니다. S3나 Google Cloud Storage는
객체 스토리지 서비스로서, 대용량 데이터를 저장하는 데 적합합니다. 코드 상에서 경로만 지정하고 실제 데이터
처리는 DB와 연동하여 수행하려면, 애플리케이션 레벨에서 DB 연동 로직을 구현해야 합니다. 이 때,
ORM(Object-Relational Mapping) 라이브러리를 사용하면 편리합니다.
5. S3와 Google Cloud Storage 동시 사용
S3와 Google Cloud Storage를 동시에 사용하는 것은 기술적으로 가능합니다. 각각의 장점을 활용해
다양한 요구 사항을 충족시킬 수 있습니다. 예를 들어, 특정 지역에서의 접근 속도 최적화, 비용 최적화,
데이터 백업 및 재해 복구 등의 목적으로 여러 스토리지 서비스를 사용할 수 있습니다. 그러나 이를 위해서는
데이터 관리와 접근 제어, 비용 관리 측면에서 복잡성이 증가할 수 있으므로, 체계적인 설계와 관리 전략이
필요합니다. 여기에는 몇 가지 고려해야 할 중요한 요소들이 있습니다:
데이터 관리
* 일관성: 두 스토리지 서비스 간 데이터 일관성을 유지하는 것이 중요합니다. 이를 위해 데이터 동기화 전략을
세워야 합니다. 예를 들어, 주기적인 데이터 동기화 작업을 스케줄링하거나, 데이터 변경 시 자동으로 다른
스토리지에도 반영되도록 이벤트 기반 트리거를 설정할 수 있습니다.
* 접근 제어: 데이터 보안을 위해 권한 기반의 접근 제어를 구현해야 합니다. 사용자 또는 시스템이 필요한
데이터에만 접근할 수 있도록 세밀한 접근 정책을 설정해야 합니다.
비용 관리
* 비용 최적화: 두 스토리지 서비스를 사용함으로써 발생하는 비용을 면밀히 분석하고 최적화하는 것이 중요합니다.
데이터 전송 비용, 저장 비용 등 다양한 측면에서 비용을 절감할 수 있는 방안을 모색해야 합니다.
* 용량 계획: 데이터의 양이 증가함에 따라 저장 공간을 효율적으로 활용하기 위한 용량 계획이 필요합니다.
예를 들어, 자주 접근하지 않는 데이터는 더 저렴한 스토리지 옵션으로 이동시킬 수 있습니다.
기술 통합
* API 통합: S3와 Google Cloud Storage의 API를 애플리케이션에 통합하여, 하나의 인터페이스를 통해
두 스토리지 서비스를 관리할 수 있도록 구현하는 것이 좋습니다. 이를 위해 추상화 레이어를 구축하여,
스토리지 서비스 간의 차이를 최소화할 수 있습니다.
* 성능 최적화: 두 스토리지 서비스를 사용함에 따라 발생할 수 있는 성능 저하를 최소화하기 위한 전략이 필요합니다.
데이터 캐싱, 지연 시간 최소화 등의 방법으로 응답 시간을 개선할 수 있습니다.
결론
S3와 Google Cloud Storage를 동시에 사용하는 것은 특정 상황에서 유용할 수 있지만, 추가적인 관리 및
비용이 발생할 수 있습니다. 따라서 이러한 결정을 내리기 전에 비즈니스 요구 사항과 기술적 요구 사항을 면밀히
검토하고, 전체 시스템 아키텍처에 대한 체계적인 계획을 수립해야 합니다. 또한, 두 스토리지 서비스를 효율적으로
관리하고 최적화하기 위해 지속적인 모니터링과 평가가 필요합니다.
[우성종 질문]
Q. 사용자가 인증했던 사진들을 모아두고 확인할 수 있는 갤러리를 만들어두면 좋을 것 같은데,
이러한 사진들을 어떻게 처리해야 할까요? 갤러리는 미션과 1:1 관계이고, 갤러리에 있는 사진에는
업로드한 사용자의 정보가 담겨 있습니다. 사용자는 마이페이지에서 자신이 업로드한 사진을 확인할 수 있고,
그렇다면 { 사용자 : 사진 } : { 1 : N }, { 미션 : 갤러리 } : { 1 : 1 },
{ 갤러리 : 사진 } : { 1, N } 관계가 될 것인데, 이렇게 중간에 연결되는 무언가가 또 필요할 것 같습니다.
그렇다면 추가적인 테이블을 만들고 이를 처리해주는 코드가 필요할 거 같고, 지금 당장 이렇게 하는 것보단
우선 업로드한 이미지를 분석하고, 해당 이미지는 저장하지 않고 분석한 결과만 리스트로 저장해주는 방식으로 해두고,
사진 저장은 추후 구현하는 것으로 할까 싶은데, 이렇게 하는 것이 괜찮을까요?
갤러리 - 해당 미션에 관련된 사진 : 다양한 사람들의 업로드
마이페이지 - 해당 사용자가 업로드한 모든 사진 : 다양한 미션
[창민 튜터님 답변]
A. 당장 하는 것보다는 추후 구현하는 것이 좋을 것 같습니다. 무조건. 인증 .. 퍼포먼스 ..
Vision API 해서 나름 괜찮게 나오는지 .. 책 읽는 사진 .. 어떤 텍스트가 나오는지 .. 그것 확보하고 ..
// 텍스트 데이터 나와서 인증할래 안 할래? 텍스트 저장하는 것도 힘들다면 .. 저장할 수 있으면 저장하는 것으로!
그렇다면 지금 우선 순위는 무엇일까?
우선 bucket과 fileName에 대한 것부터 해결해야 한다.
버킷이란 무엇일까?
- 버킷은 Amazon S3에 저장된 객체에 대한 컨테이너입니다.
- 버킷에 저장할 수 있는 객체 수에는 제한이 없습니다.
- 또한 계정에 버킷을 최대 100개까지 포함할 수 있습니다.
- 증가를 요청하려면 Service Quotas 콘솔을 방문하세요.
Q. Insomnia의 Multipart에서 image라는 이름으로 ‘전공 공부_02.jpeg’ 파일을 가져와서
아래 코드에서 분석해주려고 하는데, 아래 코드의 일부 코드를 수정해야 할 것 같아.
수정 필요한 부분 수정해주고, 왜 그렇게 수정했는지에 대해서 미친 디테일로 설명해줘.
근데 보니까 Service 코드에서 Google Cloud Service에 접근하는 것 같다.
Google Cloud Client와 버킷에 접근하는 것 같다. 그렇다면 Google Cloud Storage를 만들어야겠지?
- 모르겠고 ...
우선 데이터베이스를 연결하기 전에 로컬에서 파일 업로드하는 것부터 구현해야 한다.
로컬에서 파일 업로드할 때에는 어떤 버킷과 어떤 경로를 사용해야 할까?
- 모르겠고 ...
지금 보니까 미션 인증을 하기 위한 API도 존재하지 않았다.
미션 인증을 해주기 위한 API는 어떻게 작성해주어야 하는 걸까?
- User에서 코드를 수행해야 할 것으로 보인다. 매개변수 값으로는 사용자 아이디와 미션 아이디를 입력받고 ..
원하는 사용자가 원하는 .. ??
- 우선적으로 미션 업로드할 때, AuthGuard를 통해서 사용자 검증을 해야 한다.
@UserGuards(AuthGuard(‘jwt’))를 통해서 현재 로그인한 사용자에 대한 정보를 가져올 수 있는가?
네, @UserGuards(AuthGuard(‘jwt’))를 사용하여 현재 로그인한 사용자의 정보를 가져올 수 있습니다.
이는 NestJS 프레임워크에서 제공하는 기능으로, JWT(Json Web Tokens)를 이용한 인증 방식을 구현할 때
주로 사용됩니다. 여기서 AuthGuard는 인증을 위한 커스텀 가드를 구현할 때 사용되며, 'jwt'는 이 가드가
JWT 기반 인증을 처리하도록 지정합니다.
1. AuthGuard('jwt')의 작동 원리
NestJS에서 AuthGuard는 특정 경로(route)에 접근하기 전에 실행되는 미들웨어의 일종입니다.
AuthGuard('jwt')는 요청(request)이 들어올 때 요청 헤더에 포함된 JWT를 검증합니다.
JWT가 유효하다면, 해당 요청이 처리됩니다. 그 과정에서 JWT에 포함된 사용자 정보(예: 사용자 ID)를
요청 객체에 추가할 수 있으며, 이를 통해 API 내부에서 현재 로그인한 사용자의 정보에 접근할 수 있습니다.
2. 구현 방법
a. 모듈 설치
먼저, JWT 인증을 위해 필요한 @nestjs/jwt와 @nestjs/passport 모듈을 설치합니다.
npm install @nestjs/jwt @nestjs/passport passport passport-jwt
b. JWT 전략 설정
jwt.strategy.ts 파일을 생성하고 JWT 전략을 정의합니다.
여기서는 Passport의 JwtStrategy를 활용합니다.
import { Injectable } from '@nestjs/common';
import { PassportStrategy } from '@nestjs/passport';
import { ExtractJwt, Strategy } from 'passport-jwt';
@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
constructor() {
super({
jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
ignoreExpiration: false,
secretOrKey: process.env.JWT_SECRET,
});
}
async validate(payload: any) {
return { userId: payload.sub, username: payload.username };
}
}
validate 메소드는 JWT 토큰이 유효한 경우 실행되며, JWT 페이로드에서 사용자 정보를 추출하여 리턴합니다. 리턴된 값은 후속 요청에서 사용할 수 있습니다.
c. 가드 사용
이제 컨트롤러에서 @UseGuards(AuthGuard('jwt')) 데코레이터를 사용하여 특정 경로를 보호할 수 있습니다.
import { Controller, Get, Request, UseGuards } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';
@Controller('profile')
export class ProfileController {
@UseGuards(AuthGuard('jwt'))
@Get()
getProfile(@Request() req) {
return req.user;
}
}
위 예제에서 getProfile 메소드는 @UseGuards(AuthGuard('jwt'))로 보호되므로, 유효한 JWT가 없는 경우 접근할 수 없습니다. req.user는 JwtStrategy의 validate 메소드에서 리턴한 사용자 정보를 담고 있습니다.
3. 정리
@UseGuards(AuthGuard('jwt'))를 사용하면 JWT를 이용한 인증을 쉽게 구현할 수 있으며, 이를 통해 API 경로를 보호하고 현재 로그인한 사용자의 정보를 안전하게 관리할 수 있습니다. 이 방법을 통해 인증된 사용자의 요청만을 처리하도록 하여 애플리케이션의 보안을 강화할 수 있습니다.
- 이건 우선 지금 해결할 문제는 아닌 것 같음. 우선 나중으로 미뤄두자.
출처
https://velog.io/@wanzekim/ERROR-ExceptionHandler-metatype-is-not-a-constructor
[Nest.js] ERROR [ExceptionHandler] metatype is not a constructor
@UseGuards(AuthGuard()) 로 발생한 이슈
velog.io
1 mission.module.ts에 ‘PassportModule.register({defaultStrategy: ‘jwt’}) 코드를 작성해줘야 한다.
2. @UseGuards(AuthGuard)가 아니라 @UseGuards(AuthGuard())를 사용해주어야 한다.
Q. @UseGuards(AuthGuard)와 @UseGuards(AuthGuard())의 차이?
A.
NestJS에서 @UseGuards 데코레이터는 미들웨어나 인터셉터와 유사하게, 특정 경로(또는 전역적으로)에
대한 액세스를 제어하는 데 사용됩니다. AuthGuard는 인증을 처리하는 데 사용되는 가드의 한 예입니다.
@UseGuards(AuthGuard)와 @UseGuards(AuthGuard()) 사이에는 중요한 차이가 있습니다.
1. @UseGuards(AuthGuard): 이 형태는 클래스를 직접 전달하는 것입니다. NestJS는 이 정보를 사용해
내부적으로 인스턴스를 생성하고, 이 인스턴스는 요청마다 재사용됩니다. 이 방식은 단순한 인증 메커니즘을 구현할 때
유용합니다. 클래스 자체를 전달하면, NestJS가 필요에 따라 해당 클래스의 인스턴스를 생성하고 관리합니다.
2. @UseGuards(AuthGuard()): 이 형태는 함수 호출을 통해 가드의 인스턴스를 직접 생성하고,
이 인스턴스를 사용합니다. 이 방식은 가드에 추가적인 옵션을 전달할 필요가 있을 때 유용합니다.
예를 들면, @UseGuards(AuthGuard('jwt'))는 'jwt' 전략을 사용하는 AuthGuard의 인스턴스를 생성합니다.
이 경우, AuthGuard 함수는 팩토리 함수로, 필요한 설정을 가지고 가드의 새로운 인스턴스를 생성합니다.
요약하자면, @UseGuards(AuthGuard)는 가드의 클래스를 직접 전달하는 방식으로, NestJS가 인스턴스를 관리하며,
@UseGuards(AuthGuard())는 가드의 인스턴스를 직접 생성하고, 이를 통해 더 세밀한 설정이나 옵션을 가드에
전달할 수 있는 방식입니다. 후자는 특정한 구성이나 동적인 옵션을 가드에 적용하고자 할 때 선택적으로 사용됩니다.
현재 로그인한 사용자에 대한 정보를 UseGuard를 통해서 가져오고 콘솔에 찍고 싶으면 코드를 어떻게 작성해야 할까??
- 여차저차 하면 되겠다.
웹에 배포했을 때에도 Barer 토큰을 활용해서 사용자 정보를 가져올 수 있을까?
- 그런 거 같다.
- 아직 Google Cloud Storage 굳이 사용하지 않으려고 했는데, 아무래도 필요할 것 같다.
쿼리 매개변수 사용의 이점과 단점
이점:
1. 간단한 데이터 전송: URL의 일부로 데이터를 전송하기 때문에 간단한 데이터 조회에 적합합니다.
fileName이나 bucketName처럼 간단한 문자열 정보를 전달할 때 유용합니다.
2. 캐싱과 기록: 쿼리 매개변수를 사용한 요청은 URL에 모든 정보가 포함되므로, 브라우저나 서버 측에서
쉽게 캐싱할 수 있습니다. 또한, 로그에 남기기 쉬워 접근성이 높아집니다.
3. 직관적인 API 디자인: RESTful API 디자인에서 리소스의 조회는 주로 쿼리 매개변수를 통해 이루어지며,
이는 사용자가 API를 이해하기 쉽게 만듭니다.
단점:
1. 보안 취약성: 민감한 정보를 쿼리 매개변수로 전송할 경우, URL에 그대로 노출되므로 보안에 취약합니다.
2. 길이 제한: 일부 브라우저나 서버에서는 URL 길이에 제한이 있어, 많은 양의 데이터를 전송하기
어려울 수 있습니다.
3. 구조적 한계: 복잡한 데이터 구조를 전송하기 어렵습니다. 예를 들어, 배열이나 객체를 쿼리 매개변수로
전달하기 위해서는 추가적인 인코딩이 필요할 수 있습니다.
Request Body 사용의 이점과 단점
이점:
1. 보안성: 데이터가 HTTP 메시지의 본문에 포함되므로 URL에 노출되지 않습니다. 민감한 정보를 전송할 때 보다
안전합니다.
2. 데이터 길이 제한 없음: 본문을 통해 전송되므로, URL 길이에 대한 제한이 없습니다. 큰 데이터를 전송할 때
유리합니다.
3. 구조적 유연성: JSON 형태로 복잡한 데이터 구조를 쉽게 전송할 수 있습니다.
단점:
1. 캐싱 어려움: POST 요청은 캐싱이 기본적으로 이루어지지 않습니다. 따라서 조회용으로 사용될 경우 캐싱 전략을
별도로 고안해야 합니다.
2. 로그 기록의 어려움: 요청 본문의 데이터는 로그에 바로 남기기 어렵습니다. 따라서 디버깅 시 별도의 로깅
메커니즘이 필요할 수 있습니다.
결론
이미지 파일의 라벨을 감지하는 경우, 쿼리 매개변수를 사용하는 것이 RESTful 원칙에 더 부합하며, 간단한 문자열
정보를 전달하는 데에 적합합니다. 또한, 이미지 이름이나 버킷 이름과 같은 조회 조건을 전달하기 위해선 쿼리
매개변수가 더 직관적이고 간편합니다. 이러한 정보는 보안상 크게 민감한 정보는 아니므로, URL에 노출되어도
큰 문제가 되지 않습니다. 따라서, 주어진 상황에서는 쿼리 매개변수를 사용하는 것이 바람직합니다.
로컬에 저장된 파일에 대한 label Detect
http://localhost:3000/vision/detect-labels?fileName=/Users/your_username/Desktop/your_folder/your_image.jpg
GCS에 저장된 파일에 대한 label Detect
http://localhost:3000/vision/detect-labels-gcs?bucketName=your_bucket_name&fileName=your_image.jpg
[기술면접]
테스팅 ..
Express가 뭐고 왜 사용하나요?
Node 라이브러리 중 하나로 알고 있고 Low Level보다는 High Level로 사용하는가? HTTP 메소드를 다룰 때 ..
조금 더 풀어서 ..
-> 클라이언트와 서버가 REST API로 통신을 할 때 ..
어떤 특성들이 있을 텐데, Express란 무엇이고, 외우는 것보다 .. 개념 살짝만 정리하고 ..
[GPT4]
A.
Express는 Node.js를 위한 가장 인기 있는 웹 프레임워크 중 하나입니다.
이는 웹 애플리케이션과 API 개발을 위해 설계되었으며, Node.js의 핵심 모듈 위에 구축되어 있어서 더 쉽고,
빠르며, 유연한 웹 개발 경험을 제공합니다. Express를 사용하는 이유는 여러 가지가 있지만,
주요한 몇 가지를 아래에 소개하겠습니다:
1. 간결한 라우팅 시스템: Express는 URL 경로와 HTTP 메소드(GET, POST 등)를 처리하는 간단하고
효율적인 방법을 제공합니다. 이를 통해 개발자는 애플리케이션 내에서 다양한 요청 경로를 쉽게 설정하고
관리할 수 있습니다.
2. 미들웨어 지원: Express는 미들웨어를 사용하여 요청-응답 사이클 내에서 재사용 가능한 코드를 쉽게
삽입할 수 있게 해줍니다. 이를 통해 개발자는 애플리케이션의 기능을 모듈화하고 확장성 있게 관리할 수 있습니다.
3. 빠른 개발 속도: Express는 기본적인 웹 서버 기능을 추상화하여 제공하기 때문에,
개발자는 복잡한 설정 없이도 빠르게 웹 애플리케이션을 구축할 수 있습니다.
4. 풍부한 생태계: Express는 Node.js 커뮤니티에서 널리 사용되기 때문에, 다양한 서드파티 미들웨어,
라이브러리, 툴이 존재합니다. 이러한 풍부한 생태계는 개발 과정을 더욱 효율적이고 간편하게 만들어줍니다.
5. 유연성과 확장성: Express는 매우 미니멀리스틱한 프레임워크입니다.
개발자는 자신의 필요에 맞게 Express 애플리케이션을 쉽게 확장하고, 필요한 기능만을 추가하여 사용할 수 있습니다.
이러한 이유들로 인해, 많은 개발자들과 기업들이 Express를 선택하여 웹 애플리케이션과 API를 개발하고 있습니다.
Express는 Node.js 개발에 있어서 필수적인 도구 중 하나로 자리 잡았습니다.
라벨링을 하고 ..
인증 ..
인증에 대한 이야기를 한번 살짝이라도 하시면 좋겠다.
갓생살기 프로젝트 하고 있는데 .. 아무나 갓생 살았다고 하면 안 되니까..
사진 업로드하게 하면 안 되고 .. 아무 사진 X ..
사람이 한 명이 하나씩 올라올 때마다 검수를 하는 것도 사실상 불가능하니 어느 정도 자동화를 하려고 합니다.
NPM이란 무엇일까요?
- 라이브러리를 간편하게 설치할 수 있는 도구로 알고 있다.
Node Package Manger의 약자 ..
말씀하신 게 맞는데 .. 설치/삭제 .. 중요한 건 ..
패키지가 필요한 이유는 어떤 프로젝트를 구현함에 있어서 .. 기존 도구 활용 .. 세팅이 되면 ..
협업을 하기 위해서 package.json, package-lock.json .. 의존성 .. 일관된 환경에서 작업을 할 수 있다
[GPT4]
A.
NPM은 Node Package Manager의 약자로, Node.js의 패키지 매니저입니다.
NPM을 통해 개발자들은 Node.js 패키지(라이브러리 또는 모듈)를 관리하고 공유할 수 있습니다.
NPM은 다음과 같은 주요 기능을 제공합니다:
1. 패키지 설치 및 관리: NPM을 사용하면 개발자들은 필요한 Node.js 패키지를 쉽게 설치, 업데이트,
삭제할 수 있습니다. 이는 package.json 파일을 통해 관리되며, 이 파일에는 프로젝트의 의존성 정보가
명시되어 있습니다.
2. 패키지 검색 및 공유: NPM은 전 세계의 Node.js 개발자들이 만든 수많은 패키지를 호스팅하는 중앙 저장소
역할을 합니다. 개발자들은 NPM 웹사이트나 CLI(Command Line Interface)를 통해 필요한 패키지를
검색하고, 자신이 만든 패키지를 공유할 수도 있습니다.
3. 버전 관리: NPM은 패키지의 버전을 관리할 수 있게 해줍니다. 개발자들은 특정 버전의 패키지를 지정해
설치할 수 있으며, 패키지의 업데이트를 다룰 때도 유용하게 사용됩니다.
4. 스크립트 실행: package.json 파일 내에 스크립트를 정의하여, 일반적인 작업을 자동화할 수 있습니다.
예를 들어, 애플리케이션을 시작하거나 테스트를 실행하는 작업을 NPM 스크립트로 설정할 수 있습니다.
NPM의 이러한 기능들은 Node.js 개발의 효율성과 편의성을 크게 향상시켜 줍니다.
대규모 프로젝트에서는 패키지의 관리와 협업이 매우 중요한데,
NPM은 이러한 측면에서도 개발자들에게 큰 도움을 제공합니다.
따라서 NPM은 Node.js 생태계에서 중요한 역할을 하며, 거의 모든 Node.js 프로젝트에서 사용됩니다.
말씀을 못하지는 않는데 깊이가 부족하다..
마지막은 거의 없는데 .. 깊이 채우는
Q. RESTFUL API란?
A.
RESTful API는 Representational State Transfer의 약어로, 웹에서 사용되는 아키텍처 스타일입니다.
이는 웹 애플리케이션 간에 정보를 교환하기 위한 규칙, 원칙, 제한 조건의 집합을 정의합니다.
RESTful API를 사용하면, 클라이언트와 서버 사이에서 HTTP 프로토콜을 통해 데이터를 주고받을 수 있습니다.
RESTful API의 핵심 개념에는 여러 가지가 있지만, 주로 자원(Resource), 메서드(Method),
표현(Representation)의 3가지로 요약할 수 있습니다.
자원(Resource)
* REST에서 모든 것은 자원으로 표현됩니다. 자원은 문서, 이미지, 서비스 처리 결과 등 웹에서 접근할 수 있는
모든 것을 의미하며, 각 자원은 고유한 URI(Uniform Resource Identifier)를 가집니다.
예를 들어, 'https://example.com/users'는
"사용자"라는 자원을 나타낼 수 있습니다.
메서드(Method)
* RESTful API는 자원을 처리하기 위한 표준 HTTP 메서드를 사용합니다.
주로 사용되는 메서드에는 GET(자원 조회), POST(자원 생성), PUT(자원 업데이트), DELETE(자원 삭제)
등이 있습니다. 예를 들어, 'GET /users'는 모든 사용자의 정보를 조회하는 요청이 될 수 있습니다.
표현(Representation)
* 클라이언트가 서버로부터 자원의 상태(데이터)를 받을 때, 그 표현에는 JSON, XML 같은 여러 형식이
사용될 수 있습니다. 서버는 클라이언트가 이해할 수 있는 형태로 자원의 상태를 전달(표현)해야 합니다.
RESTful API의 특징
* 상태없음(Stateless): 서버는 클라이언트의 상태를 저장하지 않습니다.
각 요청은 독립적이며 필요한 모든 정보는 요청과 함께 전달되어야 합니다.
* 캐시 처리 가능(Cacheable): RESTful API 응답은 캐시될 수 있어야 합니다.
이는 네트워크 트래픽을 줄이고 성능을 향상시킵니다.
* 계층화(Hierarchical): RESTful API는 다중 계층으로 구성될 수 있습니다.
예를 들어, 클라이언트와 서버 사이에 보안 계층, 로드 밸런싱 계층 등이 존재할 수 있습니다.
* 유니폼 인터페이스(Uniform Interface): RESTful API는 통일된 인터페이스를 제공하여 플랫폼과
언어에 독립적인 통신을 가능하게 합니다.
RESTful API의 이러한 원칙과 특징을 이해하고 적용함으로써,
개발자는 분산 시스템에서 효율적이고 유연하며 확장 가능한 웹 서비스를 설계할 수 있습니다.
이러한 접근 방식은 웹의 성장과 발전에 크게 기여해왔으며, 현대 웹 애플리케이션 개발의 핵심 요소 중 하나입니다.
Q. 깃허브 커밋 기록이 중요할까?
디렉토리 구조 중간중간에 바꾸거나 해도 이게 마이너스가 되는 포인트가 되고 그러진 않을까?
A.
깃허브의 커밋 기록의 중요성에 대해 상세히 설명해드리겠습니다. 깃허브 커밋 기록은 매우 중요한 요소이며,
프로젝트의 진행 과정과 변화를 기록하는 데에 있어 필수적인 역할을 합니다.
하지만, 디렉토리 구조를 중간중간에 변경하는 것이 반드시 마이너스 포인트가 되는 것은 아닙니다.
이에 대해 미치도록 상세하게 설명해 드리겠습니다.
깃허브 커밋 기록의 중요성
1. 변경 사항 추적: 커밋 기록을 통해 프로젝트의 어느 부분이 언제, 누구에 의해, 왜 변경되었는지를 명확하게
파악할 수 있습니다.
2. 협업의 효율성: 여러 사람이 하나의 프로젝트에 참여할 때, 커밋 기록은 작업의 협업을 용이하게 만들어 줍니다.
누가 어떤 작업을 했는지 명확히 알 수 있기 때문입니다.
3. 버그 추적 및 수정: 문제가 발생했을 때, 과거의 커밋을 찾아보고 해당 시점의 코드로 롤백하여 문제의 원인을
파악하고 수정할 수 있습니다.
4. 포트폴리오 구축: 깃허브 커밋 기록은 당신의 기술적 기여와 활동을 보여주는 포트폴리오 역할을 합니다.
적극적인 커밋 기록은 개발자로서의 성실성과 열정을 드러낼 수 있습니다.
디렉토리 구조 변경의 영향
디렉토리 구조를 변경하는 것은 프로젝트의 진행 과정에서 필요한 경우가 많으며, 이는 자연스러운 일입니다.
중요한 것은 그러한 변경 사항을 명확하게 문서화하고 커밋 메시지를 통해 변경의 이유와 내용을 잘 설명하는 것입니다.
* 가독성과 유지보수: 명확하고 잘 구조화된 커밋 메시지는 프로젝트의 가독성과 유지보수성을 높여줍니다.
* 변경 이유의 명확화: 왜 디렉토리 구조를 변경했는지 명확한 이유를 커밋 메시지에 기록함으로써,
추후 해당 변경사항을 이해하고, 필요한 경우 원상 복구하는 데 도움을 줍니다.
결론
깃허브 커밋 기록은 매우 중요하며, 디렉토리 구조 변경과 같은 중대한 변경사항이 있다면,
이를 잘 기록하는 것이 중요합니다. 이러한 기록들은 프로젝트의 진행 상황을 이해하고, 협업을 용이하게 하며,
문제 발생 시 해결을 돕는 등 다양한 이점을 제공합니다. 따라서, 커밋 기록을 잘 관리하는 것은
프로젝트 성공의 중요한 열쇠 중 하나입니다.
개발 중일 때 아이디 등록해둬야 가능한 것 같다.
탈퇴 .. 비밀번호 있어야 하는데 소셜 로그인은 비밀번호 로그인 .. ]]
- 제일 잘 되는 로그인으로 보여주는 것으로 하고
[중간 시연 피드백]
“시연하는 것 순서 다 맞춰야 한다
시연하는 순서 미리 맞춰야 하고
시연하다가 안 되는 것 다시 맞춰야 하고 ..
에러를 빠르게 수정하셔야 할 거 같고
시연 순서 확실히 하셔서 ..
임팩트 있는 부분들 분량 늘리고 ..
수정/삭제 .. 이런 거 할 필요 없고 ..
수정 살짝 해보고 미션 해보고 ~
우리가 이 미션을 이렇게 수행했으니 인증을 해보곘습니다~
사진을 했을 때 .. 텍스트 보여주는 건 지금이지만
인증이 되었다
이상한 사진 올려서 인증 안 되는 거 보여주고
관련 있는 사진 올려서 인증 되는 건 보여주고 ~ “
'Coding > 내일배움캠프' 카테고리의 다른 글
| [내일배움캠프] 최종 프로젝트 Day 19 | Node.js 4기 | Day 100 | 24.04.13.(토) (0) | 2024.04.14 |
|---|---|
| [내일배움캠프] 최종 프로젝트 Day 18 | Node.js 4기 | Day 99 | 24.04.12.(금) (0) | 2024.04.13 |
| [내일배움캠프] 최종 프로젝트 Day 16 | Node.js 4기 | Day 97 | 24.04.10.(수) (0) | 2024.04.11 |
| [내일배움캠프] 최종 프로젝트 Day 15 | Node.js 4기 | Day 96 | 24.04.09.(화) (0) | 2024.04.10 |
| [내일배움캠프] 최종 프로젝트 Day 14 | Node.js 4기 | Day 95 | 24.04.08.(월) (0) | 2024.04.09 |
