Beginning Kubernates-Based MSA (with Spring Boot) - Part 1
안녕하세요. 자문자답해봅니다. PowerShell 7.6.6 PS C:\Users\MZC-USER> kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo base64: 'base64' 용어는 cmdlet, 함수, 스크립트 파일 또는 실행 프로그램의 이름으로 인식되지 않습니다. 이름의 철자를 확인하거나 경로가 포함되어 있으면 경로가 올바른지 확인하고 다시 시도합니다. 명령 파이프라인 위치 1에서 cmdlet Write-Output 다음 매개 변수에 대한 값을 제공하세요. InputObject: PS C:\Users\USER> $pwd = kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" PS C:\Users\USER> [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($pwd)) ................ PS C:\Users\USER>
next-themes 문서를 읽어보고 다른 분들 사용방법을 읽어봤는데, 따로 NextThemeProvier를 생성하지 않고 next-themes의 ThemeProvider를 layout.tsx에 바로 적용하는데 강의에서는 따로 provider를 생성해서 적용하고 있습니다. 혹시 유지보수를 좀 더 원활하게 하기 위함일까요?
안녕하세요, 저는 회사에서 next.js로 포팅하여 개인적으로 좀 공부하고 있는 학생입니다. 현재 2강 할 일 관리 앱을 보면서 저희 회사의 작업 방식을 함께 생각해봤는데 저희 회사는 꼭 필요한 부분 (iron-session을 이용하여 세션을 가져온다거나)을 제외하고는 죄다 클라이언트 컴포넌트로 바꿔서 사용하고 있습니다. 그래서 이 작업을 진행하면서도 클라이언트 컴포넌트로 모두 바꾸어 진행한다면 어떨까라고 생각이 들었었는데 과제에서는 최소한의 컴포넌트만 클라이언트 컴포넌트로 바꾸라고 하신 이유가 궁금합니다. 감사합니다!
카카오 데브톡 응답에 따르면 프론트/백엔드 분할 책임 방식이 지양한다고 합니다. 오히려 백에서 로그인 구현을 일임하는 것을 권장합니다. https://devtalk.kakao.com/t/oauth/136448 해당 블로그에서도 책임을 프론트와 백엔드가 나누어 가지는 방식 이 잘못되었다고 합니다. https://cafe.naver.com/xxxjjhhh/296 카카오 로그인 REST API에서도 백에서 인가 코드를 받습니다. https://developers.kakao.com/docs/ko/kakaologin/rest-api#before-you-begin-process 어떤 방식이 맞는지 헷갈립니다.
강의에서 이해하기 쉽게 그림으로 설명해주시는데 예제코드에 따로 그림이 첨부되어있진 않던데 혹시 그림은 따로 제공이 안될까요? 그리고 중간 중간 편집이 어색하게 되어서 중복 대사가 있다보니 오히려 더 헷갈리게 되더라고요 강의 03-03 "클라이언트 컴포넌트에서 서버 컴포넌트 렌더링 하기 -1"에서 6분 18초 가량부터 시작해서 대사가 "페이지 컴포넌트에서 데이터 패치 컴포넌트로 props를 전달하는 건 가능하지만 그리고 페이지 컴포넌트에서 데이터 패치 컴포넌트로 props로 데이터를 전달하는 건 가능하지만 클라이언트 래퍼 컴포넌트에서 데이터 패치 컴포넌트로 props로 데이터를 전달하는 건 불가능한 그런 구조가 되게 되는 겁니다" 이러다보니 오히려 헷갈리게 되더라고요 이런 부분은 확실히 편집되면 좋겠습니다. 이미지도 오히려 설명이 달라서 "페이지 컴포넌트에서 클라이언트 래퍼 컴포넌트로 dataFetch를 props로 전달이 가능하고, 페이지 컴포넌트에서 데이터 패치 컴포넌트로도 props 전달이 가능하지만 클라이언트 래퍼 컴포넌트에서 데이터 패치 컴포넌트로 props를 전달하는건 불가능한 구조가 되게 되는겁니다"와 같이 수정이 좀 필요해보입니다.
말씀해주신 대로 브라우저의 쿠키 탭에서 데이터를 입력하니, 서버를 재실행했을 때 쿠키가 날라가서 올바르게 테스트를 할 수 없었습니다. Claude 로 확인해보니 headers.set('Set-Cookie', ...) 코드 작성 후 테스트 환경에서 직접 URI 를 입력하여 실행하여 쿠키를 심어보라고 해서 그렇게 했더니 쿠키가 잘 심어집니다! /* src/app/api/test-cookie/route.ts */ // localhost:3000/app/api/test-cookie 로 들어가 직접 쿠키를 입력해야 정상 작동 export async function GET() { const response = new Response('ok'); response.headers.set('Set-Cookie', 'name=kim; HttpOnly; Path=/; Max-Age=3600'); return response; }
revalidatePath("/about", "page") 로 설정을 하고 테스트를 하다 보면 /about 페이지에서 재검증 버튼을 누르면 AboutLayout의 데이터 패칭 결과와 AboutPage의 데이터 패칭 결과가 함께 바뀌는 것과, /about/detail 페이지에서 재검증 버튼을 누르면 아무런 변화도 없는 이유가 revalidatePath의 첫 번째 인자로 설정된 "/about" 이 아닌 /about/detail 페이지에 접속해 있기 때문이라는 것까지는 이해했습니다. 하지만 detail 페이지에서 재검증을 누르고 about 페이지로 이동하면 즉시 AboutPage의 결과는 변하는데 AboutLayout의 결과는 변하지 않는데 이유가 뭔가요?
