안녕하세요 선생님 front, back nginx 한 뒤로 둘다 https라고 바뀌고 인증서도 있긴한데, Front(502 Bad Gateway)라고 나오고 back(welcome to nginx) 라고만 나오는 상태입니다. (설치는 Nginx Ubuntu20보고 했습니다 https://certbot.eff.org/instructions?ws=nginx&os=ubuntufocal&tab=standard ) 문제1)그래서 첫번째 문제로 back에서 sudo npx pm2 logs --err --lines 200를 해보았을 땐 아래와 같은 경고가 나왔습니다. 0|app | Warning: connect.session() MemoryStore is not 0|app | designed for a production environment, as it will leak 0|app | memory, and will not scale past a single process. 질문1)찾아보니까 express-session 미들웨어의 기본 메모리 저장소( MemoryStore )를 사용할 때 MemoryStore 가 개발 환경에서는 적합하지만, 실제 프로덕션 환경에서는 메모리 누수 문제와 단일 프로세스 제한으로 인해 적합하지 않아 프로덕션 환경에서는 Redis, MongoDB 등의 세션 저장소를 사용하라는데, 그럼 front 화면이 나오는건지 궁금합니다,, 문제2)그리고 두번째 문제로 back에서 tail /var/log/nginx/error.log를 했을 땐 아래와 같은 에러가 나왔습니다. ubuntu@ip-172-31-12-59:~/react_nodebird/back$ tail /var/log/nginx/error.log 2024/01/24 12:19:54 [warn] 420260#420260: conflicting server name "api.luckyhaejin.com" on 0.0.0.0:80, ignored 2024/01/24 12:19:54 [notice] 420260#420260: signal process started 질문2)찾아보니 Nginx 설정 파일 내에 서 api.luckyhaejin.com 이라는 서버 이름(server name)이 80 포트에서 두 번 이상 선언되었음을 나타내는 에러라는데 어떤 부분이 잘못되었는지 잘 모르겠어서 어딜 확인하면 좋을지 문의 드립니다. 질문3)강의에서 Ubuntu서버만 바꿔주고 로컬은 바뀌는 부분 이없는거같아서 Ubuntu서버에서만 바꿔줬는데, 그럼 로컬에도 Ubuntu에 설치한 것 다 포함해서 코드까지 다 바꿔준 뒤 Ubuntu에서 git pull 다시 해줘야할까요,,? 현재 설정된 내용) front=> /etc/nginx/nginx.conf => server관련 (글을 옮겨적으니까 들여쓰기 해서 정리 한게 코드가 전부 합쳐져서 사진으로 올립니닷,,) front/pacakage.json에서 start부분에 3060 잘 되어있음 front => /etc/nginx/nginx.conf front/config/config.js에서 backUrl설정 잘 되어있음 back => /etc/nginx/nginx.conf back => app.js(사진이 보기 편하실거같아서 코드랑 둘다올려욧) const express = require('express'); const cors = require('cors'); const session = require('express-session'); const cookieParser = require('cookie-parser'); const passport = require('passport'); const dotenv = require('dotenv'); const morgan = require('morgan'); const postRouter = require('./routes/post'); const postsRouter = require('./routes/posts'); const userRouter = require('./routes/user'); const hashtagRouter = require('./routes/hashtag'); const db = require('./models'); const passportConfig = require('./passport'); const path = require('path'); const hpp = require('hpp'); const helmet = require('helmet'); dotenv.config(); const app = express(); db.sequelize.sync() .then(() => { console.log('DB 연결 성공'); }).catch(console.error); passportConfig(); if(process.env.NODE_ENV === 'production'){ app.use(morgan('combined')); app.use(hpp()); app.use(helmet()); app.use(cors({ origin: 'https://luckyhaejin.com', credentials: true })); } else { app.use(morgan('dev')); } app.use('/', express.static(path.join(__dirname, 'uploads'))); app.use(express.json()); app.use(express.urlencoded({extended:true})); app.use(cookieParser(process.env.COOKIE_SECRET)); app.use(session({ saveUninitialized: false, resave: false, secret: process.env.COOKIE_SECRET, cookie: { httpOnly: true, //자바스크립트로 접근하지못하게 secure: true, //일단 false로 하고 https적용할 땐 ture domain: process.env.NODE_ENV = 'production' && '.luckyhaejin.com' //도메인 사용할 경우 }, })); app.use(passport.initialize()); app.use(passport.session()); app.get('/', (req, res) =>{ res.send('hello express'); }); app.use('/posts', postsRouter); app.use('/post', postRouter); app.use('/user', userRouter); app.use('/hashtag', hashtagRouter); app.listen(3065, () => { console.log('서버 실행 중'); }); back => /etc/nginx/nginx.conf 사용중인 Os) macOS
강의에서 알려주신 router.replace() 를 사용하지 않고 // @/app/(beforeLogin)/@modal/(.)login/page.tsx import { redirect } from "next/navigation"; export default function Login() { redirect("/i/flow/login"); } 기존의 이 코드를 인터셉트 라우팅으로 줘서 홈페이지 -> 인터셉트 라우팅된 /login -> 인터셉트 라우팅된 /i/flow/login 으로 이동하도록 폴더를 구성해서 구현해 봤습니다. 이 방식으로 구현해도 문제 없을까요?
안녕하세요 선생님! 좋은 강의 정말 감사하게 듣고 있습니다. 선생님의 강의를 듣다보니, Next.js 13의 Data Fetching 방법이 React Query과 유사함을 느꼈습니다. (주니어라 부족함이 있어 실제론 유사하지 않을 수도 있지만..!) Next 13의 데이터 패칭 방법이 react 에서 React Query를 사용하여 서버 API의 데이터를 일정 시간동안 fresh 상태로 갖고 있는것 stale한지 chach로 체크하는 것 모두 흡사 하다고 느꼈습니다. React Query의 가장 큰 강점은 클라이언트-서버간의 데이터 동기화가 가장 큰 장점이라고 생각하는데 만약 Next 13의 데이터 패칭 방법을 사용한다면 번거로운 React Query의 보일러코드들을 사용하지 않아도 React Query의 장점을 그대로 살려 쉽게 사용할 수 있을 것 같아보입니다! 따라서, Next 13에선 React Query가 무한스크롤 외에 사용할 일이 거의 없을 것만 같아보이는데...! 어떻게 생각하실지 의견이 궁금합니다...! next 13과 react query 조합은 앞으로 거의 사용하지 않게 되는 걸까요? 선생님의 고견을 나눠주시면 감사하겠습니다~! 바쁘실텐데 번거롭게 해드려서 죄송합니다! 감사합니다!
서버 컴포넌트가 프론트 서버에서 미리 렌더링되는 것으로 알고 있었습니다. 이것이 맞을까요?? 클라이언트 컴포넌트랑 서버 컴포넌트의 렌더링 방식을 찾아봤음에도 여전히 헷갈리는데 시간적 여유가 되신다면 쉽게 알려주실 수 있을까요?? 클라이언트 컴포넌트 사이에 서버 컴포넌트를 넣으면 렌더링 동작이 어떻게 수행되는지 궁금합니다. 강좌에서는 PostArticle이라는 클라이언트 컴포넌트의 자식으로 서버컴포넌트를 넣는데, 공식문서에서는 클라이언트 컴포넌트가 DOM Tree의 끝에 오도록 하는 것을 권장하는 것으로 알고 있었는데 제가 잘못 알고 있던 것이었을까요??
안녕하세요! 제로초님! 보너스 강의까지 잘 챙겨보고 있습니다. 매번 감사합니다! 제 질문은..! server action 함수쪽에서 fetch config 객체에 credentials 을 include로 해줘야 쿠키(세션)를 API 요청 시 같이 태워서 보낼 수 있다고 설명해주셨는데, 혹시 이것이 next-auth 로부터 도움을 받는 것일까요? 강의 수강 후, next 14로 프로젝트를 구현하고 있는데, fetch 할 때, credentials 를 include 해주었음에도 불구하고, 브라우저 application 탭에서 확인 할 수 있는 쿠키가 태워지지 않아서요. 해당 쿠키는 서버에서 로그인 시에 set-cookie 해준 쿠키이고, 프론트엔드는 localhost , 서버는 ec2에 배포된 서버입니다. 그래서 현재는 server action 함수내에서 next.js에서 지원해주는 cookie() 를 이용해서 fetch config 객체 내 headers 에 직접 쿠키를 넣어주고 있는데, 강의에서는 credentials 만으로 API 요청시 쿠키(세션)을 잘 태워서 보내주고 있는 것 같아 질문을 남기게 되었습니다.
콘솔로그 결과 안녕하세요 선생님, 강의를보고 간단하게 따라해보았는데요 NextRequest 타입의 req를 매개변수로 받아와서 req를 console.log 에 찍어보면 undefined가 뜹니다. 혹시 NextRequest 사용에 조건이 따로 있을까요? req.nextUrl.pathname 으로 url 도 가져와보고 싶고한데 생각처럼 잘 안되네요..
선생님, 안녕하세요. 너무 기초적인 질문일 수 있지만, 갑자기 궁금해져서 질문드립니다. 서버사이드 렌더링의 경우, 서버에서 pre-render된 코드를 만들어서 보내주고, 클라이언트에서 hydrate를 해서 페이지를 만든다고 알고 있습니다. 클라이언트 사이드 렌더링의 경우는 html코드와 js코드를 함께 보내서, 클라이언트에서 페이지를 만들구요. 서버사이드 렌더링을 할 때, pre-render된 코드를 만드는 서버는 각 클라이언트들의 컴퓨팅 자원을 사용하는 건지(클라이언트의 컴퓨터에서 만드는 건지), 아니면 배포하는 중앙(?)서버(aws ec2 또는 이 강의에서 처럼 vercel)의 컴퓨팅 자원을 사용하는 건지(서버에서 만드는 건지) 궁금합니다. 클라이언트 측에서 다 계산을 한다고 하면, 중앙(?)서버의 부담이 적을테지만, 중앙(?)서버에서 한다고 하면, 부담이 갈 수 있을 것 같아서요. 최근 next.js 14버전이 되면서 디비와 직접 통신하는 등 기능이 많이 생겼는데, 이 통신하는 등의 역할은 client side가 아닌 server side에서만 가능하더라구요. 그래서 server side라는 게 중앙서버 하나에만 있다면, 계산이 오래걸린다거나 트래픽이 늘어나거나 한다면 다른 사용자들에게도 영향을 끼치지 않을까 궁금했습니다.(자동 확장이 되지 않을때) 또, 이런식으로 간다면 따로 백엔드 서버가 필요없게 될 수도 있겠다라고도 생각해봤는데, 어떻게 보고계시는지도 궁금합니다.
SSR 방식에 서버 컴포넌트와 클라이언트 컴포넌트를 둘 다 적절히 사용하는 것인가요?? 서버 컴포넌트는 데이터 페칭, 보안, 캐싱, JS 번들크기 감소와 같은 장점이 있고 event와 hook을 사용하지 못한다는 특징도 이야기해주셨는데, 그렇다면 데이터를 받아서(페칭해서) 클라이언트 컴포넌트에 데이터를 뿌려주는 느낌으로 조합해서 사용하는 건가요?? 서버컴포넌트는 event를 사용하지 않으므로, TTI를 개선하기 위해 나온 개념은 아닌거죠???
안녕하세요. test를 하던 중 오류가 발생하여 문의드립니다. 지금 현재 코드를 import { setupServer } from "msw/node"; import { apis } from "./apis"; export const server = setupServer(...apis); 위에처럼 입력해 놓은 상태입니다. 하지만 테스트 실행 시 아래와 같이 발생합니다. Cannot find module 'msw/node' from 'src/commons/mocks/index.js' Require stack: src/commons/mocks/index.js jest.setup.js > 1 | import { setupServer } from "msw/node"; | ^ 2 | import { apis } from "./apis"; 추가적으로 지금 jest관련 페이지에서 Parsing error: ESLint was configured to run on `<tsconfigRootDir>/src\commons\mocks\index.js` using `parserOptions.project`: <tsconfigRootDir>/tsconfig.json However, that TSConfig does not include this file. Either: - Change ESLint's list of included files to not include this file - Change that TSConfig to include this file - Create a new TSConfig that includes this file and include it in your parserOptions.project See the typescript-eslint docs for more info: https://typescript-eslint.io/linting/troubleshooting#i-get-errors-telling-me-eslint-was-configured-to-run-- 위와 같은 오류가 발생합니다. 해결 부탁드립니다!
안녕하세요 강의 정말 잘 듣고있습니다! SSG가 SSR보다 사용자 경험이 좋은건 이해했습니다! 근데 한가지 더 의문점인건 SSG가 아니고 SSR을 선택해야하는 케이스가 있을까요? 라는 의문이 듭니다! 예를 들면 검색결과 페이지라던가 매번 매순간 페이지의 내용이 달라지는 페이지라면 SSG가 아니고 SSR로 만드는게 더 적합한 그런 케이스가 실무에서 있을까요?
안녕하세요 강사님. 마이페이지 내 포인트 화면의 구매내역 조회기능을 구현 중에 있습니다. fetchPointTransactionsOfBuying API 로 구매내역을 조회하는데 판매자의 이름이 불러와지지 않습니다.. const FETCH_POINT_TRANSACTIONS_OF_BUYING = gql` query fetchPointTransactionsOfBuying($search: String, $page: Int) { fetchPointTransactionsOfBuying(search: $search, page: $page) { _id impUid amount balance status statusDetail useditem { _id name price seller { _id # name # email } buyer { _id name email } soldAt } createdAt } } `; useditem.seller._id 까지는 조회가 되는데 name 과 email 은 조회가 되지않습니다. 혹시나 해서 buyer 정보를 불러왔는데 buyer 도 _id 만 조회가 되고 name 과 email 는 조회가 되지 않습니다. 위와 같은 오류가 나오는데 제가 모르는 부분이 있는건지 데이터에 문제가 있는건지 잘 모르겠습니다.. !
Next.js로 Google Cloud Platform에 App Engine 서비스 배포를 진행하고 있습니다. 문제는 production ( 실 서비스 )와 development ( 개발용 )으로 나누어서 .env.development, .env.production의 두개의 환경변수를 가지고있습니다. 배포 시 실서비스 에서는 .env.production을 사용하도록 개발용 에서는 .env.development를 사용하도록 설정하려는데 이것저것 만져보아도 production만 사용하는 문제가 발생해버리네요. 현재 프로젝트구조와 설정코드는 이렇습니다. project ├── local └── Dockerfile └── docker-compose.yml ├── resource └── .next └── ... (Next.js 빌드 파일) └── node_modules └── package.json └── dev_app.yaml └── prd_app.yaml └── .env.development └── .env.production └── next.config.js └── ... (기타 Next.js 프로젝트 파일) 여기서 package.json의 script설정은 다음과 같습니다. { dev: "next dev", start: "next start", lint: "next lint", deploy: "npm run build && gcloud app deploy --project='production' -q --appyaml=prd_app.yaml", deploy:dev: "npm run build:dev && gcloud app deploy --project='development' -q --appyaml=dev_app.yaml", build: "dotenv -e .env.production next build", build:dev: "dotenv -e .env.development next build" } next.config.js는 특별히 건드리지 않았습니다. dev_app.yaml, prd_app.yaml파일은 서비스명만 각각 설정해 주었습니다. runtime: nodejs20 # or another supported version service: development 질문 1. 현재 app engine 업로드된 용량, 로직을 보니 빌드파일이 아닌 프로젝트 그대로 들어가는 것 같습니다. 빌드는 환경변수파일도 정상적으로 분기되는데 앱엔진에서 해당문제가 발생하는 것으로보아 혹시 Next.js에서 빌드된 파일로 app engine에 배포할 수 있는지 궁금합니다. 질문 2. 빌드파일만 올릴수 없다 라고 하더라도 프로젝트 그대로 올리면서 환경변수를 분기할 방법이 있는지 궁금합니다. 정말 문서건 블로그건 구글서칭, 깃허브검색, GPT 모두 끈질기게 시도해봤지만 능력부족 탓인지 성공하지 못했습니다.. 능력자분들께서 도움주시면 잊지않겠습니다!!
