현직 개발자입니다. 생각이 많아져서 질문드립니다. SSR(타임리프, JSP), CSR(Vue3) 을 프로젝트 경험하면서.. 이런저런 생각이 드는데요. 1.CSR은 SEO문제 해결이 가능한가요? 2.CSR은 컴포넌트 재사용이 장점이나 화면복잡도가 높아질 경우 코드 복잡도가 높아진다고 생각되는데 어떻게 생각하시는지요? 3.SSR이 화면 깜빡임이 있다고 하는데, 실은 비동기 통신하면 화면 깜빡임은 제어 가능합니다. html자체를 바꿔서 렌더링 하는게 아닌 화면 하나당 html하나로 렌더링하는거죠.(메뉴이동시에만 html이동하니 메뉴이동시 초기화면은 깜빡임은 있음) 강의 내용에 있는 Tab은 한화면에 구성하면 깜빡일 일도 없고, 내부 공통 기능들은 공통JS로 빼고 틀은 같이 쓰고, 공통부분은 템플릿관련 JS로 처리하면 크게 다른부분을 모르겠습니다. 화면 내에서는 전부 비동기 통신 Ajax로 처리하면 깜빡임은 없더라구요. 4.CSR은 SPA기반이라 초기화면이 모바일쪽이 더 심플해서 나을거 같다라는 생각이 듭니다. 대형 포털을 CSR기반으로 하면 복잡도도 높아지고, 제 경험엔 초기화면 또는 복잡한 화면들이 많이 느려지더라구요. 어떻게 생각하시는지요? SSR, CSR이 어떤 상황에 적용되는게 나을지에 대한 의문이 항상 있습니다. 그냥 강의듣다가 개인적인 질문 드려봅니다. cf. 강의 내용은 아주 잘 듣고 있습니다.^^
[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
3:23 (nickname에 unique: true 적용) 다름이 아니라 중복을 허용하지 않을 때 @Column({ unique: true })를 해도 되지만 @PrimaryColumn()을 해도 되지 않나해서 여쭤봅니다! 혼자 리서치해본 바로는 PrimaryColumn은 식별자로써 쓰일 수 있으면 쓰고 @Column({ unique: true})는 식별자로 쓰진 않아도 될 때 적용한다는 얘기를 들었습니다. 그런데 식별자가 많아서 나쁠건 없지 않나? 싶기도 하고 nickname을 식별자로 쓸 가능성도 있으면 좋을거 같기도 해서 PrimaryColumn으로 해도 괜찮을거 같다는 생각이 들었습니다. PrimaryColumn이 한 테이블에 너무 여러개 존재하면 안 좋다거나 그런 컨벤션이 있는 것일까요?
[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
코드팩토리 디스코드에 질문하면 더욱 빠르게 질문을 받아 볼 수 있습니다! [코드팩토리 디스코드] https://bit.ly/3HzRzUM - 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 강사님, PUT 요청에서 컨트롤러에서는 @Body() 를 optional ( ? )로 받았는데, 서비스 함수에서는 인자를 필수( string )로 선언하면 TypeScript 에러가 납니다. 이럴 땐 서비스 함수의 author, title, content를 string? 또는 string | undefined 로 바꿔줘야 하는 게 맞을까요?
[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
안녕하세요! pagination 강의를 듣고 서버에서 front로 보내는 방법은 정확히 이해했습니다. 감사합니다. 그런데 frontend에서 어떠한 방식으로 처리해야 하는지 감이 안 옵니다. 대략적으로 front에서 20개씩 요청하는 방식을 어떻게 해야 하는지 설명 부탁 드립니다. 그리고 혹시, 강사님이 해주시는 frontend pagination 강의가 있으면 추천 부탁 드립니다.
[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
37강 ( 모든 Route 기본 Private로 만들고 IsPublic Annotation 작업하기) 강의 에서 8분 50초에 아래의 코드에 @IsPublic을 해줘도 아래 가드를 통과해야 해서 괜찮다고 말씀해주셨는데요. //access 토큰 재발급 @Post('token/access') @IsPublic() // 여기가 퍼블릭이여도 밑에서 가드를 통과해야하기 때문에 괜찮다. @UseGuards(RefreshTokenGuard) postTokenAccess(@Headers('authorization') rawToken: string) { // 여기서 받는 rawToken은 Bearer 이다. const token = this.authService.extractTokenFromHeader(rawToken, true); // token은 refresh 토큰이다. false를 같이 던져줘서 acess 토큰이 나온다. const newToken = this.authService.rotateToken(token, false); /** * {accessToken: {token}} 이러한 형태로 리턴 */ return { accessToken: newToken }; } //refresh 토큰 재발급 @Post('token/refresh') @IsPublic() @UseGuards(RefreshTokenGuard) postTokenRefresh(@Headers('authorization') rawToken: string) { // 여기서 받는 rawToken은 Bearer 이다. const token = this.authService.extractTokenFromHeader(rawToken, true); // token은 refresh 토큰이다. true를 같이 던져줘서 acess 토큰이 나온다. const newToken = this.authService.rotateToken(token, true); /** * {refreshToken: {token}} 이러한 형태로 리턴 */ return { refreshToken: newToken }; } AccessTokenGuard, RefreshTokenGuard 모두 BearerTokenGuard를 먼저 수행하기 때문에 req에 IsRoutePublic가 true로 되어 있어서 AccessTokenGuard, RefreshTokenGuard 이 두 개 모두 바로 통과하는 것으로 알고 있습니다. 이렇게 되면 IsPublic 어노테이션을 사용한 상황에서는 전역으로 설정된 AccessTokenGuard는 통과하게 됩니다. 그리고 "token/access" API에 설정된 RefreshTokenGuard도 물론 통과하게 됩니다. 이렇게 되면 RefreshTokenGuard는 어디에서도 사용할 수 없는 게 아닐까요?? ///////////////정리//////////////////////////////// % 토큰 재 발급하는 상황이라고 가정 % IsPublic 어노테이션 설정됨 -> AccessToken 통과, RefreshTokenGuard 통과 BearerTokenGuard 통과 RefreshTokenGuard도 통과 즉, refreshToken 인지 검증 불가능 IsPublic 어노테이션 설정됨 -> AccessToken 검증 재검증 로직이므로 refresh 토큰을 보냈으므로 AccessToken 검증에서 accessToken이 아니라고 걸림 즉, RefreshTokenGuard는 사용할 수 없게 되는게 아닌가요?
프로젝트 구성 Dockerfile FROM node:14 RUN apt-get update && apt-get install -y bash COPY ./package.json /myfolder/ COPY ./yarn.lock /myfolder/ WORKDIR /myfolder/ RUN yarn install COPY . /myfolder/ CMD ["yarn", "start:dev"] docker-compose.yaml version: "3.7" services: node-server: build: context: . dockerfile: Dockerfile volumes: - ./index.js:/myfolder/index.js - ./email.js:/myfolder/email.js ports: - 3000:3000 database-server: image: mongo:5 ports: - 27017:27017 Window 환경입니다. 위와 같을 때 index.js 파일을 수정하여도 docker로 연동된 nodemon 재 실행이 안됩니다. docker-desktop 에서 container 에서보면 mount 라고 표기되어있고 위의 새로고침 버튼을 누르면 제대로 적용 됩니다. 원인이 뭘까요?
[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
@VersionColumn() 관련하여 'save()함수가 몇번 불렸는지 기억한다' 라고 하셔서 save함수가 불린 횟수에 따라 1씩 증가하는 것으로 처음에 이해를 했었는데, 강의 영상과 조금 다르게 service & controller 나눠 작성하는 연습을 하다가 아래와 같이 title을 동일한 값으로 수정하는 코드를 작성했었습니다 async PatchUsers(id: string) { const user = await this.userRepository.findOne({ where: { id, }, }); if (!user) { throw new NotFoundException(); } console.log('Before save - Version:', user.version); if (user) { user.title = '수정하기'; } const newUser = await this.userRepository.save(user); console.log('After save - Version:', user.version); return newUser; } 이때 title이 이전과 동일하면 실제로 save함수는 실행이 되지만 DB상에 변화가 없기 때문에 @VersionColumn() 으로 정의한 version에는 변화가 없는 것 같은데 save함수의 실행횟수보다 db의 변화가 있는지에 초점을 맞춰서 생각하면 될까요 ?
self-signed certificate in certificate chain 발생합니다. 1번 process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'; 2번 // SSL 인증 무시를 위한 Agent 생성 const httpsAgent = new https.Agent({ rejectUnauthorized: false }); await axios.get("target_url", { httpsAgent: agent }); 1,2 번 외 해결 방법이 있을까요? 또는 2번을 적용하려면 어떻게 해야하나요? 또는 Java에서 로컬 톰캣 서버에서 HTTPS 설정하듯이 할수있는 방법이 있나요?
아래 내용과 함께 .css파일도 추가해보세요 https://learn.microsoft.com/ko-kr/aspnet/core/blazor/components/layouts?view=aspnetcore-9.0 레이아웃 네임스페이스를 사용할 수 있도록 설정 프레임워크에 대해 시간이 지남에 따라 레이아웃 파일 위치 및 네임스페이 Blazor 스가 변경되었습니다. 빌드하는 앱의 BlazorBlazor 버전 및 유형에 따라 레이아웃의 네임스페이스를 사용할 때 표시해야 할 수 있습니다. 레이아웃 구현을 참조할 때 레이아웃의 네임스페이스를 표시하지 않고 레이아웃을 찾을 수 없는 경우 다음 방법 중 어느 것이든 수행합니다. @using 레이아웃의 위치에 대한 지시문을 _Imports.razor 파일에 추가합니다. 다음 예제에서는 이름이 Layout 있는 레이아웃 폴더가 폴더 내에 Components 있고 앱의 네임스페이스는 다음과 같습니다 BlazorSample . razor복사 @using BlazorSample.Components.Layout 레이아웃이 @using 사용되는 구성 요소 정의의 맨 위에 지시문을 추가합니다. razor복사 @using BlazorSample.Components.Layout @layout DoctorWhoLayout 사용되는 레이아웃의 네임스페이스를 정규화합니다. razor복사 @layout BlazorSample.Components.Layout.DoctorWhoLayout
