#캐싱

OAuth2 + jwt 환경 부하 테스트 방법에 대한 질문..

최근 성능 테스트의 중요성에 대해 알게 되어서 목표 성능치를 두고 부하테스트를 진행해보려는 계획에 있습니다! 테스트 툴로는 nGrinder를 사용할 생각인데요, 문제는 제 서버가 이메일 로그인을 지원하지 않고 oauth2와 jwt를 활용한 인증/인가 방식을 사용하는데 부하테스트 시 가상 유저에게 어떻게 accessToken을 발급해주어야 하는지에 대한 궁금증이 생겼습니다..! 제가 생각해본 방식들은 다음과 같습니다. 1. 실제 유저에 대한 accessToken을 하나 발급해두고 이를 고정값으로 사용한다. - 이 방식은 제일 편하지만 사실상 한명의 유저에 대한 시나리오만 테스트할 수 밖에 없고, 같은 유저에 대한 각종 캐싱된 데이터들로 인해 실제 상황과는 동떨어진 작업이 될 것 같아 채택하지 않았습니다. 2. FakeAuthServer와 같은 가상의 OAuth 서버를 만들어 로그인을 시도한다. - 구현하기는 어려워보이지만 그나마 가장 실제 서비스와 동일한 형태입니다. 하지만, 제가 테스트하려는 시나리오는 여러 요청에 대한 순차적인 테스트가 아닌 하나의 API가 얼마나 많은 부하를 견딜 수 있는지 보기 위한 테스트라서 굳이 로그인 과정을 테스트에 포함시킬 필요는 없어보입니다.. - 사실 하나의 API에 대한 테스트만 진행해도 괜찮은지 몰라서 이 방법을 버리지 못하고 있습니다 3. nGrinder의 테스트 스크립트에서 @BeforeThread에 jwt를 발급받는 로직을 작성해서 테스트 전 미리 토큰을 발급받아 요청한다. - 이 방식은 로그인 과정은 포함되어 있지 않고 이미 토큰을 발급받았다는 가정하에 하나의 API만 테스트하기 가장 적합한 방법이라고 생각이 되었습니다. - 번거롭지만 jwt를 직접 생성해주기 위해 jjwt 라이브러리를 nGrinder에 포함시켜야 될 것 같습니다 - 하지만 이렇게 스크립트에서 토큰을 발급해주는게 맞는지 실무에서도 이런식으로 사용하는 경우가 있는지 궁금합니다.. 처음 부하 테스트를 적용하려고 하는데 oauth2 + jwt로만 구성된 예제가 보이지 않네요 ㅠㅠ 어느 방법이 가장 적절한지 혹은 더 나은 방법이 있는지 조언을 구하고자 질문 남깁니다!

Next.js SSR CSR에서의 캐시 문제

메인 페이지의 컴포넌트는 무한 스크롤을 이유로 SSR안에 CSR이 작동하는 구조입니다. 거기서 제품 상세 페이지를 들어가면 현재 페이지는 RSC + 클라이언트 컴포넌트를 통해 이루어진 SSR 페이지입니다. 구매 또한 RSC / 클라이언트 컴포넌트를 구분 지어놓은 상태입니다. 구매를 하면 메인으로 와지구요. 이 경우 다시 제품 상세 페이지로 들어갔을 때 fetching을 다시 안하는 이슈가 있어(next-server 캐싱 문제) 동적 페이지로 작동해야하기 때문에 force-dynamic과 no-cache header를 달아줬습니다. 그 이후에 제대로 작동하는듯 하였는데 상세 페이지에서 클라이언트 컴포넌트에서 console.log를 찍었을 때 구매 한 이후에도 수량이 변하지 않는 것을 확인하였습니다. 이러한 문제를 해결하기 위해서 구매 페이지에서 onSuccess 됐을 때 router.refresh()를 해줬을 시에는 상세 페이지에서의 클라이언트 컴포넌트 console이 제대로 찍히는걸 확인하였습니다. 이에 대해 궁금점은 메인 페이지로 가는 router 이후 refresh를 하였고 메인에서 변경된 상황만 refresh 되는걸로 알고 있었는데 별개의 페이지인 상세 페이지에서 console이 제대로 찍히는 이유가 뭔지 모르겠습니다. 이러한 전처리를 하지 않으면 새로고침을 하지 않으면 이전의 data가 그대로 console에 찍힙니다. 또한 force-dynamic을 해줬는데도 불구하고 console.log를 SSR 페이지에서 찍었을 때 최초의 접근 할 때는 가져오지만 그 이후에 다시 들어올 때는 메인에서 refresh를 하고 나서도 console이 안찍히는데 왜 이런지 궁금합니다. next-server에서 매번 data를 fetching하지만 ui의 변경이 없다고 판단되면 클라이언트로 데이터를 보내지 않아 찍히지 않는걸까요.

next.js의 캐시와 react query 캐시 질문

next.js와 react query를 사용해 프로젝트를 진행하다가 이해가 안되는 현상이 있어서 질문드립니다. 어떤 A 라는 페이지에 들어오면 포스트와 포스트의 댓글들이 보이는 상황입니다. 첨부한 코드는 A 페이지를 담당하는 page.tsx 코드와 page 에서 사용중인 컴포넌트중 댓글 컴포넌트인 Comments 컴포넌트, 그리고 Comments 에서 useQuery의 queryFn으로 지정한 getComments 함수의 코드입니다. Comments 컴포넌트의 useQuery의 staleTime은 10초로 해두었고, queryFn인 getComments 함수의 fetch는 revalidate를 60초로 해둔 상황입니다. useQuery의 staleTime보다 fetch의 revalidate 시간을 길게 한건 react query로 인한 클라이언트측의 캐시와, next.js의 fetch에 의한 서버 측의 캐시의 차이점을 확인해보려고 그런것입니다. A 페이지에 처음 들어와 page 컴포넌트가 실행되면 ['posts', id, 'comments'] 쿼리로 인해 받아온 댓글(comments) 데이터가 화면에 보입니다. 이 댓글에는 랜덤으로 생성된 이미지가 있습니다. 우선 10초가 지나기 전에는 새로고침에도 기존의 데이터 그대로 보이고, fetch 요청을 받는 백엔드 api에도 요청이 들어오지 않습니다. react query로 인해 쿼리가 실행되지 않아서 그런 것이겠죠? 그러고 10초가 지나 ['posts', id, 'comments'] 쿼리가 stale 상태가 된 후에 A 페이지를 새로고침하면 ['posts', id, 'comments'] 쿼리는 다시 fresh 해지는데 백엔드 api에는 요청이 들어오지 않았더라구요. 화면상의 댓글의 이미지들도 이전과 동일하게 나옵니다. 저는 이게 "A 페이지에 들어와 page 컴포넌트가 실행되면 ['posts', id, 'comments'] 쿼리가 실행되어 fetch 요청이 실행되는데 이 ['posts', id, 'comments'] 쿼리는 서버 컴포넌트에서 프리패치 되는 거니까, 즉 fetch가 서버쪽에서 실행되는 거니까 react query의 캐시가 아닌 fetch의 캐시 설정을 따른다. 그렇기 때문에 ['posts', id, 'comments'] 쿼리가 실행되어 fetch가 실행되지만 fetch의 캐시는 남아있으니까 캐싱된 값을 사용해서 백엔드 api에는 요청이 안들어온것이다." 라고 생각했고 이걸 확인하기위해 새로고침을 해본것이었기 때문에 이 결과에 대해 납득하긴 했는데요.. 이 생각이 맞는건지가 일단 궁금합니다. 그리고 진짜 이해가 안되는건 이겁니다. A 페이지에 들어오고 10초가 지나 ['posts', id, 'comments'] 쿼리가 stale해지면 이번에는 다른 페이지로 이동했다가 A 페이지로 다시 돌아옵니다. A 페이지에서 새로고침을 하지 않고 사이트 내에서 페이지 이동으로 A 페이지에 다시 들어오는거죠. 이러면 백엔드 api에 요청이 들어오더라구요. 이게 왜 그런건지 모르겠습니다. 10초가 지나 ['posts', id, 'comments'] 쿼리는 stale 해졌지만 60초는 안지나서 fetch의 캐시는 유효한... 위의 새로고침 경우와 동일한 상황인데 새로고침 시에는 api로 요청이 안들어오고, 다른 페이지로 이동했다가 다시 돌아온 경우는 api로 요청이 들어오네요. A 페이지에서 새로고침을 하나, 다른 페이지에서 A 페이지로 페이지 이동을 하나, 둘 다 page 컴포넌트가 실행되고 ['posts', id, 'comments'] 쿼리가 서버에서 프리패치되니까 fetch가 서버에서 실행되는거 아닌가요? 근데 왜 새로고침하면 fetch의 캐싱이 적용되는것처럼 백엔드 api로 요청이 안들어오고 페이지 이동 시에는 들어올까요... 이걸 아무리 생각해도 모르겠습니다. 60초가 지난 후에는 새로고침 시에도 백엔드 api로 요청이 들어오더라구요. 이것으로보아 60초 전에는 새로고침 시 요청이 안들어오는게 fetch의 캐시 때문인것도 맞는 거 같은데, 왜 페이지 이동 시에는 60초 전에도 캐싱값을 안쓰고 api로 요청을 보내는지 모르겠습니다. 어떤 메커니즘으로 이렇게 되는것일까요? 아직 Next.js의 캐싱과 react query에 대해 잘 알지 못해서 이해가 안됩니다.. ㅠ 도와주십쇼..!

NextJs 확장 fetch로 서버 컴포넌트에서 동적으로 api를 받는 방법

안녕하세요. 선배 개발자 선생님들. 오늘도 한 단계 성장하기 위해 질문을 남겨봅니다. 저는 NextJs, App router 방식으로 코드를 구현중이며, 서버 상태는 React-Query로 상태값을 관리하고 있었습니다. 왜 리액트 쿼리를 사용했는가? why? 1. Optimistic update, 무한스크롤에 대해 공부하고 적용해보고 싶었습니다. 2. 클라이언트 상태, 서버 상태를 나눈다는 개념이 너무 좋아서 서버 상태는 React-Query로 다뤘습니다. 3. statleTime, gcTime을 조정하여 캐싱기능이 좋았습니다. 갑자기 문득 나는 NextJS를 잘 쓰고 있는건가? 리액트랑 폴더 구조 말고는 다른게 없는거 아닌가? 라는 생각이 들었고, NextJs의 기능을 최대한 활용하고 나머지 불편한 부분이 생긴다면 외부 라이브러리를 사용하자! 라는 생각이 들었습니다. 그래서 저는 React-Query로 상태를 관리하던걸 NextJs의 확장 fetch로 바꿀려고 합니다. Optimistic update, 무한스크롤 기능을 제외하고 나머지 모든 서버 상태는 확장 fetch로 바꿀려고 합니다. 페이지네이션 페이지네이션 처럼 사용자와 상호 작용하는 부분, 즉 동적으로 데이터를 받아오게 하기 위해 url을 변경한 뒤, [id]/page.tsx에서 param로 받던지 혹은 header()를 통해 params를 받아서 처리를 할 수 있다고 생각하고, 저는 header()로 params를 받아서 처리를 했습니다. 모달에서의 페이지네이션 그런데 문제는 모달을 띄우고, 모달 내부에서 페이지네이션이 있는 경우 어떻게 데이터를 동적으로 받아오는지 고민을 해봐도 방법이 없는 것 같습니다. 1. 모달에서 다음 페이지 클릭시 url을 변경한다. -> 안해봤지만 동작을 할 수 있더라도 뭔가 느낌적으로 아닌 것 같습니다. 2. 클라이언트 컴포넌트에서 상태값을 서버 컴포넌트로 전달한다 -> 불가능 궁금한 점 1. 모달 내부에서 페이지네이션을 처리할때 url을 변경해서 서버 컴포넌트에서 확장 fetch로 데이터를 관리하는 게 적절할까요? 2. 모달 내부에서는 페이지네이션을 처리할 때는 react-query로 데이터를 관리하는 걸 확장 fetch로 바꿀 수 없는 건가요?? 바꿀 필요가 없는 건가요? 3. 더 좋은 방법이 있는 건가요?

data fetching은 어디서 하는 게 좋은 것일까요?

안녕하세요. 저는 프론트엔드 개발자가 되기 위해 공부중인 취준생입니다. 피드백을 적극 환영하기에 많은 피드백 혹은 의견을 많이 남겨주시면 감사하겠습니다. 저는 데이터 페칭을 어디서 하는 게 좋을지 고민 중이라 글을 남깁니다. 아래와 같이 3개로 글을 구성해봤습니다. 1. 현재 개발상황 2. 현재 저의 데이터 페칭 위치 3. 궁금한 점 1. 현재 개발상황 저는 개인 프로젝트로 Next.js와 React Query를 사용하여 개발하고 있습니다. 현재 Next.js의 App Router를 사용 중이며, 프로젝트 구조는 아래와 같습니다. app: page.tsx, layout.tsx components: 최소 2번 반복 사용되는 재사용 가능한 컴포넌트 container: 일반적인 컴포넌트 (조합 등) hook, service 등 2. 현재 저의 데이터 페칭 위치 현재 데이터 페칭은 최상단의 app -> page.tsx에서 수행하고 있으며, 자식 컴포넌트에는 데이터를 props로 전달하고 있습니다. 이러한 이유는 prop drilling이 발생하더라도 데이터 페칭을 한 곳에서 처리하면 코드 이해가 쉬울 것 같아서입니다. 현재로서는 전역 상태 라이브러리를 사용하지 않아 최대 4단계까지 prop drilling이 발생하고 있지만, 전역 상태 라이브러리를 도입하면 prop drilling 문제는 해결될 것으로 생각하고 있습니다. 추가적으로 현재 이렇게 구현하면서 data fetch할때 필요한 query값들도 최상단에서 관리해야하는 불편함이 있었습니다. -> 최상단에서 관리해야 하는 상태값이 늘어남 3. 궁금한 점 3-1. 아래의 2가지 data fetching 방법 중 어느것이 적절한지? 합리적인지 의견이 궁금합니다. - 최상단에서 Fetching - 장점 : 한 곳에서 Fetching하기에 코드 일관성, 가독성, 코드를 이해하는데 좋다고 생각 - 단점 : prop drilling, 추가적인 전역 상태 관리 해야한다고 생각 - 필요한 컴포넌트에서 Fetching - 장점 : 필요한 컴포넌트에서 fetching 하기에 prop driling과 같은 불필요한 코드 작성 할 필요 x - 단점 : 어떤 컴포넌트에서 fetching 했는지 파악하기 힘들어짐 3-2. 현재 최상단에서 모든 데이터 페칭을 하고 props로 전달하는 방식 vs 필요한 컴포넌트에서 데이터 페칭을 하는 두 가지 방식 중 어느 것이 더 많이 사용되는 패턴인지 궁금합니다. 3-3. React Query는 서버 상태 관리, 캐싱, Optimistic Update와 같은 기능을 위해 도입했습니다. 그러나 prop drilling을 해결하기 위해 React Query에서 가져온 서버 데이터를 전역 상태 라이브러리에 담게 되면 서버와 클라이언트 상태를 구분하는 의미가 없어지는 것 같다는 생각이 듭니다. 제가 잘못 사용하고 있는것인지 궁금합니다.

신입 백엔드 개발자 이력서 질문 및 피드백 요청드립니다!

백엔드 개발자로 근무하길 희망하는 취업준비생입니다! 이력서 작성에 왕도는 없겠지만, 선배님들이 어떻게 작성했는지 혹은 채용자 입장에서 괜찮은 이력서를 찾는 기준이 무엇인지를 많이 찾아보다보니까 오히려 머리가 복잡해지는 것 같아서 최대한 제 얘기를 담은 이력서를 작성하려고 노력중입니다. 다만, 제가 작성하는 방법이 채용자가 원하는 방법이 아닐 수 있기에 몇가지 질문과 가능하시다면 피드백 해주실 수 있는 선배님들이 계실까 해서 글 남겨봅니다. Q1. 이력서 내 프로젝트에서 기여 혹은 개선사항을 작성할 때 사용한 기술을 상세히 적으며 풀어나가는 것이 좋을까요 혹은 어떤 점을 어떻게 개선했는지 포괄적으로 작성하는게 좋을까요? ex) 사용자 인증 정보를 RedisTemplate의 opsForValue 메소드를 통해 캐싱하여 DB 호출 횟수 4회 -> 1회로 최적화 vs Redis를 활용한 사용자 인증 정보 캐싱으로 DB 호출 횟수 4회 -> 1회로 최적화 (적절한 예시일지 모르겠지만 생각나는대로 적어봤습니다,,ㅎ) Q2. 직무와 연관되지 않았지만 활용될만한 기술스택은 작성하는 것이 좋을까요 아니면 제외해도 괜찮을까요? ex)Scrapy, Selenium등의 크롤링 툴, 프론트엔드 기술 Q3. 이력서 외에 자기소개서 내용에서 기술적인 얘기를 많이 담는 것이 좋을지 항목에 맞는 에피소드로 자신을 드러내는 것이 좋을지 궁금합니다! (자기소개서를 읽는 채용자는 기술에 대해 자세히 모를 수 있다는 얘기도 들어봐서 고민되는 부분입니다. 1번 질문의 의도와 비슷한 내용일 것 같네요.) 이외에도 혹시 개인적으로 피드백 해주실 수 있는 분이 계시다면, 이력서 공유 해드리도록 하겠습니다! 요즘 힘든 시간을 보내고 있는데 도움 주실 수 있으시다면 정말 감사할 것 같습니다. https://drive.google.com/file/d/1LFqNNNQ3skF26xInwbYzxjZOGIlzE0lQ/view?usp=drive_link 링크 첨부를 했는데 반영이 안돼서 다시 질문 드립니다..! 감사합니다!

신입 백엔드 개발자 이력서 관련 질문

백엔드 개발자로 근무하길 희망하는 취업준비생입니다! 이력서 작성에 왕도는 없겠지만, 선배님들이 어떻게 작성했는지 혹은 채용자 입장에서 괜찮은 이력서를 찾는 기준이 무엇인지를 많이 찾아보다보니까 오히려 머리가 복잡해지는 것 같아서 최대한 제 얘기를 담은 이력서를 작성하려고 노력중입니다. 다만, 제가 작성하는 방법이 채용자가 원하는 방법이 아닐 수 있기에 몇가지 질문과 가능하시다면 피드백 해주실 수 있는 선배님들이 계실까 해서 글 남겨봅니다. Q1. 이력서 내 프로젝트에서 기여 혹은 개선사항을 작성할 때 사용한 기술을 상세히 적으며 풀어나가는 것이 좋을까요 혹은 어떤 점을 어떻게 개선했는지 포괄적으로 작성하는게 좋을까요? ex) 사용자 인증 정보를 RedisTemplate의 opsForValue 메소드를 통해 캐싱하여 DB 호출 횟수 4회 -> 1회로 최적화 vs Redis를 활용한 사용자 인증 정보 캐싱으로 DB 호출 횟수 4회 -> 1회로 최적화 (적절한 예시일지 모르겠지만 생각나는대로 적어봤습니다,,ㅎ) Q2. 직무와 연관되지 않았지만 활용될만한 기술스택은 작성하는 것이 좋을까요 아니면 제외해도 괜찮을까요? ex)Scrapy, Selenium등의 크롤링 툴, 프론트엔드 기술 Q3. 이력서 외에 자기소개서 내용에서 기술적인 얘기를 많이 담는 것이 좋을지 항목에 맞는 에피소드로 자신을 드러내는 것이 좋을지 궁금합니다! (자기소개서를 읽는 채용자는 기술에 대해 자세히 모를 수 있다는 얘기도 들어봐서 고민되는 부분입니다. 1번 질문의 의도와 비슷한 내용일 것 같네요.) 이외에도 혹시 개인적으로 피드백 해주실 수 있는 분이 계시다면, 이력서 공유 해드리도록 하겠습니다! 요즘 힘든 시간을 보내고 있는데 도움 주실 수 있으시다면 정말 감사할 것 같습니다. 감사합니다!

next socket.io 연결, 제가 어떤 부분을 놓치고 있을까요?

https://github.com/hyubbb/socket-test-app 안녕하세요. 간단하게 채팅방을 만들어서 유저의 입장/퇴장, 채팅 기능을 구현해볼려고 하는데요. 통신이 됬다 안됬다 하더라구요? 그래서 계속 새로고침을 누르거나 해야하는 현상이 있습니다. 서버와의 연결은 계속 되어있다고 하는데 , socket.on 이나 socket.emit 이 동작을 안하는데 정말 이해가 안됩니다. 콘솔을 찍어봤을땐, next가 캐싱처리를 해서 실시간으로 응답하는게 문제가 발생한게 아닐까 생각했는데, 정확하게 갈피를 잡지 못하겠습니다. 3일을 헤매고 있는데요. 제가 어떤 부분을 놓치고 있는지 알려주시면 너무 감사하겠습니다. 코드가 길어서 github에 업로드 하였습니다. 클릭 라우트 처리 components/chat/chat-list socket.emit 발생장소 components/chat/chat-room 소켓 프로바이더 components/providers/socket-provider socket서버사이드 설정 pages/api/socket/io.ts

웹소켓을 http 스타일로 데이터 관리 및 캐싱 구현 방법

안녕하세요. 리액트를 주로 사용하는 개발자입니다. 웹소켓을 통해 데이터를 주고 받을 때, 이 데이터를 http 요청처럼 관리 해보신 분이 계실까요? 특히, 이를 위해 리액트 쿼리 등과 같은 데이터 캐싱등에 용이한 라이브러리에 접목시켜보신 분이 있다면 방법에 대한 조언을 구하고 싶습니다. 1. 웹소켓을 http요청 처럼 관리 2. 수신한 데이터 캐싱 3. 연결이 끊겼을 때 캐시된 데이터 사용 4. 웹소켓 데이터 업데이트시 컴포넌트 업데이트 경험이 있으신 분들의 피드백이나 고민해보신 분들이 있다면 어떤 점에서 주의가 필요할지, 구현과정에서 특별히 고려할 점이 있는 부분이 있는지 알려주시면 감사하겠습니다. 어떤 말씀이든 도움이 될 것 같아요. 감사합니다

React-query로 실시간 데이터 반영

리액트를 통해 버스 위치 데이터를 받아서 버스 위치를 실시간으로 보여주는 앱을 개발하고 있는데요, 리액트 쿼리를 활용해 10초마다 refetch하여 데이터를 업데이트하려고 하는데 계속 자동으로 캐싱되어 처음 가져온 데이터만 10초마다 가져오네요 ㅠ (개발자 도구에서 disable cache를 하면 잘 가져옴) 새로고침를 해도 마찬가지 입니다. const { data, isLoading, error, refetch } = useQuery(["busPos"], getData, { refetchIntervalInBackground: true, refetchInterval: 10000, cacheTime: 10000, }); 어떻게 하면 데이터를 잘 업데이트할 수 있을까요?? Open api 사용 중인데 요청 헤더에 캐시 컨트롤을 노 캐시로 하면 cors 에러가 뜹니다 ㅠ

API가 제공하는 데이터의 범위를 어떻게 잡을지 고민입니다.

안녕하세요. 개인 프로젝트로 풀스택 웹 서비스를 여러 번 만들어보다가 생긴 의문입니다. 보통 저는 백엔드는 nestjs와 프론트엔드는 nextjs로 개발을 합니다. 프론트 쪽에서 react query를 사용하여 백엔드의 데이터를 fetch하여 사용하는데, 한 화면에 여러 데이터가 필요한 경우가 있습니다. 원래 백엔드 api를 짤 때 resource를 기준으로 잡았었는데 이렇게 하다보면 재사용 측면에서는 좋으나 위에서 말한 경우와 같이 한 화면에 여러 resource에 대한 데이터마다의 api를 호출하기 때문에 한 화면에서 여러 api 통신이 이루어지게 되어 cost가 있지 않을까 생각이 들었습니다. 1. 그래서 아예 한 화면에 쓰이는 데이터를 전부 serving하는 api 라우트 하나를 두면 해당 api 하나만 호출했을 때 한 번의 통신만으로 데이터를 가져오기 때문에 이 방식이 괜찮다고 생각이 들었는데 실제로 어떤 것이 더 좋은지 궁금합니다. 뭔가 감으로는 리소스별로 독립된 api를 여러개 호출하는 방식이 장점이 많은 것 같은데(querykey로 캐싱을 따로 할 수 있는 등) api 갯수가 1개랑 3개라고 하면 사용자마다 3배 많은 통신이 이루어지게 되어 이 부분이 조금 걸립니다. 2. 그리고 유저에 대한 데이터를 응답한다고 했을 때 해당 테이블에 join으로 엮을 수 있는 다른 모든 테이블도 같이 포함시키는 것이 좋은지, 아님 분리시켜서 user 테이블의 속성만 제공하는 api(/users)와 다른 테이블의 정보도 같이 포함하는 api(/users/courses)를 따로 구분하는 것이 좋은지 그 범위를 아예 모든 정보를 다 가져오는 것과 딱 필요한 정보만 제공하는 것 중 어느 방식이 어떤 측면을 가지고 있는지 궁금합니다.

앱(Flutter)에서 JSON데이터를 검색하려고 합니다

안녕하세요 Flutter를 이용하여 식단 및 체성분 관리 앱을 개발 중인 대학생입니다! json형식의 식품영양성분 공공데이터 안에서 사용자가 입력한 식품명 검색어를 기준으로 데이터를 불러오려고 합니다. DB는 Google Firebase를 사용 중이며, 위와 같은 목적으로 데이터를 사용 할 때에 적합하지 않다면 다른 DB를 사용 할 의향도 있습니다. 사용자의 검색어로 시작하는 특정 데이터만이 아니라, 검색어를 "포함"하는 데이터도 불러오고 싶습니다. 현재 어느 정도 그려 본 방법입니다. 영양성분 JSON 다운로드 ↓ Python을 이용하여 필요한 데이터만 가공 ↓ Firebase Realtime Database / Storage에 저장 ↓ 저장된 JSON을 API 호출을 통해 String으로 불러옴 / 앱 내부에 .json 파일로 저장 ↓ Map으로 변환 후 캐싱 ↓ 사용자가 검색어 입력 ↓ 검색어를 포함하는 데이터만 별도 리스트에 추가 여기서 데이터를 불러오는 과정에서 필터링을 거치지 않는 이유는 Firebase Realtime Database에서는 검색어를 "포함"하는 것이 아닌, 사전 순으로 검색어 기준 뒤에 있는 데이터만 가능하다고 합니다.. 그래서 결국 JSON파일로 직접 사용하기로 했습니다 혹시나 저의 부족함이 보이시는 분들의 조언과 피드백을 듣고 싶습니다! 더 나은 방법이 있다면 무차별 폭격 및 질문 부탁드립니다! 미리 감사드립니다 (_ _)

프론트엔드 개발 관련 서버와 동기화 문제로 인해 질문 남깁니다!

안녕하세요! 초기 스타트업에서 현재 notion과 같은 블록 에디터 기반 기능을 가진 보고서 서비스를 만들고 있습니다. 먼저 문제가 발생하기 전까지의 과정을 말씀드리면 1. 작성되어 있는 글 사이에 새로운 글을 작성하기 위해 글 사이룰 개행하여 새로운 블록을 만든다. 2. 만들어진 블록에 글을 작성하고 Enter를 누른다. 3. 변화된 블록들의 객체를 서버에 전송한다. 4. 서버에서 현재 상태에 대해 DB를 최신화하고 프론트에 전송한다. 여기서 문제가 발생하는데 3~4번의 과정 중에 유저가 빠르게 새로운 블록을 재생산하거나 기존의 에디터 상태와 DB에서 최신화된 에디터 상태가 다른 경우 새로운 블록을 재생산한 화면에서 DB를 최신화한 블록 상태로 변경되는 이슈가 있습니다. 해결하기 위해 떠오르는 여러 가지 방법들 (ex. 캐싱과 webworker )을 적용하기 전에 이런 상황들을 경험했을 선배 개발자분들께 먼저 고견을 여쭙고 진행하는 것이 현명하다고 생각하여 질문을 먼저 올렸습니다! ( 사수가 없는 상황입니다..! ) 이런 비슷한 경험을 어떻게 해결했는지 경험이라도 공유해주시면 너무너무 감사하겠습니다! :) 좋은 하루 보내세요! ( 메일 : reblackraven@gmail.com )

Next.js RSC Network response관련해서 질문이 있습니다.

Next.js App router를 사용하고 있습니다. 간단한 검색기능을 구현하는 프로젝트를 진행 중인데 패칭 과정은 아래와 같습니다. 1. 자식 Client 컴포넌트에서 url의 searchParams(router.replace)를 변경하면, 2. 부모 Server Component는 변경된 Search Params를 바탕으로 라우트 핸들러에서 서버에 요청을 하고 필요한 데이터를 Server Component로 받아옵니다 . (부모 RSC는 캐싱을 하지 않게 구현되어있습니다.) 3. 받아온 데이터를 가공 후 자식 Client 컴포넌트에 내려주면, 4. props를 받은 자식 Client 컴포넌트에서 보여주는 방식으로 진행하고 있습니다. 위 과정에서 에러가 발생하는 것은 아니고 정상적으로 잘 동작하고 있습니다. 다만 브라우저 devtool의 Network 탭을 확인하는데 의문점이 있어서 질문을 드립니다. RSC에서 요청을 하면 _rsc 페이로드로 데이터를 받아오는 걸로 알고 있습니다. 분명 _rsc로 요청이 가고 정상적으로 네트워크탭의 preview에 RSC 페이로드가 찍히는가하면 정상적으로 요청이가고 페이지를 확인했을 땐 정상적으로 패칭과 렌더링까지 완료되었는데, 네트워크에서 preview에는 "no data found for resource with given identifier"로 나옵니다. 결론은 패칭과 렌더링은 정상적으로 동작하지만 네트워크탭의 preview와 response가 나올 때도 있고 안 나올 때도 있어서, 명확한 기준이 있는지 궁금해서 질문을 올립니다.

Next.js로 프로젝트 중인데, 팀원과 의견조율이 잘 안돼서 도움 부탁드립니다.

안녕하세요, 저는 백엔드 개발자로 일한지 이제 2년차가 된 개발자입니다. 사이드프로젝트에서는 프론트 개발을 하고 있고 현재 Next.js를 사용하고 있습니다. 백엔드팀도 따로 있어서 Next.js의 API routes는 BFF같은 느낌으로 사용하고 있습니다. [Next pages] <-> [Next API] <-> [백엔드 서버] 현재 상황은 유저의 로그인정보를 어떻게 관리하냐로 이야기를 하고 있습니다. 1. 마이페이지 -> 프로필 수정 페이지 2. 로그인 -> 메인페이지 이렇게 유저의 프로필 정보가 많이 쓰이다보니까 이걸 매번 GET해서 가져올까, 전역상태로 관리할까 이야기를 하는데 좀처럼 의견이 좁혀지지가 않는 상황이라 다른 분들의 의견을 여쭙고 싶습니다. (참고로 저희 둘 다 프론트 개발경험이 그리 많지 않습니다) A: 그냥 매번 GET하자.(넥스트 API 캐싱을 사용하자) - 전역상태관리보다 코드 복잡도가 줄어들 것 같다. - 넥스트의 API 최적화를 사용하는 게 더 Next스러운 방식같다. B: 전역 상태로 관리하자. - useEffect로 현재 모든 GET 요청을 하고 있기 때문에 윌업데이트에 변경이 일어나면 재렌더링이 일어남 - (하지만 컨텍스트 정보가 바뀌지 않으면 최초 렌더 이후 리렌더 되지 않음) - 캐싱한 데이터를 받아오더라도 결국 불필요한 api요청을 보내는 것이며 api요청을 보내는 것보다 전역 상태에서 가져다 쓰는 것이 더 바람직하지 않나 서로 비슷한 실력에 사람도 둘 밖에 없어서 결정을 내리기 힘들어서, 다른 분들의 의견을 좀 들어보고 싶습니다. 읽어주셔서 감사합니다.

스프링을 통해 캐싱 중 오류가 발생했습니다

안녕하세요 먼저 오류 종류에 대해서 말씀드리면 Null key returned for cache operation입니다 @Cacheable, @CachePut, @CacheEvict 모두 key값에다가 파라미터의 이름과 같이 key="#id"를 주었습니다. 그러자 위와 같은 에러가 발생하였습니다 id라는 변수명이 문제인가? 라는 생각을 가지고 다른 것으로 바꾸어 봤지만 똑같은 문제가 발생했습니다. 일단 해결방법은 defaultKey 값을 사용하거나 파라미터를 직접 key="#p0" 이렇게 하니 해결이 되었습니다. 구글링해도 아래와 같은 방법으로 해결하는 말만 있고 위에서와 같이 변수명을 사용할 때의 문제점이 안나와서 질문 올립니다!

MSA 환경에서 ABAC 기반의 권한시스템을 어떻게 구현하는게 좋을까요?

안녕하세요 현재 진행중인 프로젝트에 MSA를 적용하여 구현하고 있는 백엔드 꿈나무입니다. 빈번하게 일어나는 권한 검증을 효율적이고 높은 가용성을 확보할 수 있도록 하기 위해서 여러 방법을 모색하던 중, 다른 분들의 의견이 어떨지 하여 QnA를 올려보게 되었습니다. 우선 저희 프로젝트는 User, Device, Organization, Team, License 이렇게 5가지 개념이 있습니다. 사용자가 장비에 접근할 때에는 본인이 소속된 Org에 해당 장비가 존재하는지, 접근하는 동작에 대해서 해당 org가 License를 보유하고 있는지, 소속된 팀 또는 본인에게 해당 장비에 해당 동작을 승인받았는지 등 수많은 조건들에 의해 ABAC가 계산되게 됩니다. 하지만 MSA 환경으로 인해 테이블을 쉽게 join하지 못할 뿐더러, 가능하더라도 상당한 고부하 작업이 될 것이라고 생각합니다. 그래서 CQRS 패턴을 이용해서 license가 만료되거나 팀의 권한이 수정되는 등, 사용자와 장비간의 권한이 수정이 되는 command가 수신되면, 그것을 권한 담당 서비스에 비동기로 전달하여 특정 사용자가 특정 장비에 어떤 동작에 대한 제어가 가능한지를 저장(캐싱)하고 있다가 권한을 검사해야되면 간단하게 query하는 형태로 구현하는 것이 적합할 것이라고 판단했습니다. 이 패턴을 구현하기 위한 두가지 방법을 고안해보았습니다. [Permission Service] 별도의 permission 서비스를 만들고 캐시용도로 redis를 연결해두고, 권한 검사 요청이 들어왔을 때 Cache Miss가 된다면 Api Gateway 패턴과 유사하게 여러 서비스에 각각 정보를 요청하여 최종적인 권한 정보를 Aggregate 하여 전달하고, 캐시에 보관하는 방식입니다 [권한 관리 Infra Service] Google의 Zanzibar와 같이 권한을 관리하고 복잡한 쿼리를 처리해주는 서비스를 이용하는 방식입니다. 오픈소스로 구현된 SpiceDB를 고려하고 있습니다. Permission Service를 만드는 경우, 본인이 보유한 정보가 부족할 경우 능동적으로 정보를 Pull하여 권한 정보를 가져오는 반면, 양측에 별도 인터페이스를 구현해야되는 단점이 있고, 이미 있는 서비스를 사용하면 구현이 쉬워지는 반면, 해당 서비스에서 능동적인 Pull이 불가능하고, 권한 Query 정보가 최신인지 판단하고 업데이트하는 것을 각 서비스에서 각각 담당해야되기 때문에 별도 서비스를 분리하는 것에 비해 Responsibility Segregation이 부족하다고도 느꼈습니다. 무엇보다 관리해야될 인프라 요소가 늘어난 것은 덤이구요. 규모에 비해서 과한 고민을 하고 있는것이 아닌가 하는 생각도 들고, 그래도 더 나은 방법으로 서비스를 만들어가고 싶기도 합니다. ABAC를 적용하는 대부분의 서비스에서 이러한 고민을 적절히 잘 해결하여 서비스가 되고 있을텐데, 정답은 없겠지만 선배님들의 조언을 듣고 싶습니다!

리액트쿼리 고수분들 도와주세요

사이드프로젝트 리팩토링을 진행하는 중에 이해가 안되는 부분이 있어 글 써봅니다. const { data, isLoading, fetchNextPage } = useInfiniteQuery( ["getProducts", sortOption, sortOrder, filterValue, categoryName], async ({ pageParam = page - 1 }) => { const response = await api.post(`/cal/v1/product/${categoryName}`, { filter: filterValue, page: pageParam, query: "", size: size, => size: size - 8 /* 변경한 부분 */ sort: [{ field: sortOption, option: sortOrder }], }); setTotalProduct(response.data.body.product.totalCount); return response.data.body.product.items; }, { refetchOnWindowFocus: false, getNextPageParam: () => page, } ); 위 코드는 인피니티 스크롤을 구현한건데요, size는 한번에 받아 올 상품의 개수 입니다. 상품을 한번에 4개 받아올때는 500ms~, 8개 = 2500ms~, 12개 = 10000ms~ 정도로 요청시간이 비정상적으로 커집니다. 사용자경험과 api요청횟수를 고려했을 때, 12개를 받아오는것이 가장 적당하다고 생각되는데 렌더링 속도가 많이 느리다고 생각되서 개선하고자 합니다. **초기렌더링 에서만 문제가 발생되고, 캐싱되어 fresh한 상태일 때는 바로 불러옵니다** 코드의 다른요소들은, 필터링. 정렬들을 위한 요소들이라 렌더링 시간에 영향을 줄 것 같지는 않은데 왜 이런 문제가 발생하는지 궁금합니다. 이 외에도 잘못작성된 부분이 있거나, 개선해야할 사항이 보이신다면 알려주시면 감사하겠습니다!!

신입개발자 방향성 고민

취준기간이 오래된 탓에 지금 재직중인 회사 최종합격발표를 통보받고, 통보받은 당일에 서류합격 연락이 5~6곳이 오더군요 최종합격한 곳 보다 조건이 더 좋은곳들이 많았지만 스트레스를 그만받고 싶었습니다. 그래서 다른회사들 면접은 다 포기하고 무작정 갔습니다. 입사결정하게 된 가장 큰 이유는 제가 프론트엔드쪽으로 공부를 하다보니 백엔드에도 관심이 생겼었는데, 면접을 보면서 풀스택 개발자로 키워주겠다. 많이 배울수있을거다 라는 말들이 가장 결정적이었죠 현재 입사 2개월차. 그때 선택을 많이 후회하고 있습니다. 많이 배울수있는 환경이 아닙니다. 너무바빠 저를 신경쓰지 않는, 못하는 느낌입니다 취준할때 프론트엔드만 공부했던 터라 백엔드 영역은 아예 무지한 상태로 들어와서 처음 회사 프로젝트를 클론받고 와 이게 뭐지 싶더라구요 오래된 기술스택과, 한 파일에 천줄이 넘어가는 코드를 보고 많이 당황을 했죠.. jsp, jquery로 이루어진 코드와 공통적으로 사용되는 코드들을 모듈화해서 사용하는것이 아닌, 코드자체를 복붙해서 사용한다던지.. 서버에 어떻게 요청을 보내는지 또는 렌더링 속도가 느리든 빠르든 캐싱이나 최적화 쪽은 아예 신경을 쓰지않고 그냥 돌아가면 상관없다고 생각하고 개발을 하고있는것같아요.. 코드리뷰나 깃 브랜치관리도 하지 않습니다 수정하고 이상없다싶으면 바로 merge합니다.. 지금은 그래도 근무외시간에 틈틈히 공부하여 spring으로 이루어진 백엔드 영역을 어느정도 이해하고 로직, 패턴이 어떻게 돌아가는지도 파악하고 간단한 기능들은 백단 프론트단을 혼자 구현할 정도는 되었습니다. 그러나 현재 업무는 선임개발자분들이 짠 코드를 테스트만 하고있구요... (화면상에서 이벤트가 정상 작동하는지만 확인, 발생하는 오류나 문제에 대한 코드수정은 하지않음) 코드 작성은 거의 하지않습니다. 가끔 코드짜는 업무를 주시면 재미는 있는데 1~2시간이면 다 끝나버리고 그 후에는 퇴근시간까지 저 혼자 공부하거나 멍을 때리고 있는 시간이 많아 현타가 많이오네요 연차가 높아진다고 이 회사에서 제대로된 개발을 하느냐도 사실 잘 모르겠습니다. 10년이 넘어간 개발자 분들도 새로운 기능추가나, 마이그레이션 같은 기능추가를 자발적으로 하신다기 보단 고객사에서 요청하면 그제서야 합니다. 제가 노력을 안하느냐? 그것도 사실 잘 모르겠습니다. 처음 적응기간때는 집에와서 공부하는게 좀 힘들었지만 요즘은 하루에 2시간정도는 하려고 노력을 많이 하고있습니다. 회사에서도 계속 선임분들에게 저 할일없을까요 ! 물어보고 있구요. 이 회사를 계속 다니면서 제가 공부하던 react, react-query 등과 같은 스택은 사용도 못하고 잡일, 단순 노가다같은 일을 반복해가며 이 회사에 남아있는게 과연맞는건지.. 남아있는 다고 한들 제대로된 개발업무를 할 수 있을지 의문입니다. 제가 추구하던 방향성은 바쁘고 야근이 많더라도 제실력을 키우면서 같이 성장할 수 있는 환경을 원했었는데 지금와서야 선택지가 많았는데 왜 여길왔을까 싶은 후회가 많이 되네요. 사실 적을게 더많지만 너무 흉만 보는거같네요.. 좋은점은 퇴근은 빨리한다 정도 말고는 없는거같습니다. 퇴근 이후에 따로 공부를할 때, react쪽을 더 공부해서 다시 취업을 알아보는게 맞는건지 어떻게 성장을 해나가야 할지 사실 잘 모르겠습니다. 이와같은 상황에서 어떻게하는게 맞는지 조언을 좀 구하고싶습니다!

React-query 사용하면, waterfall 이 미친듯이 증가해요

안녕하세요 데이터 캐싱 때문에, React-query를 사용하려고 하는데요 react-query를 사용하기만 하면 Newtwork 눌러보면 bundle.js의 waterfall이 13초가 찍히면서 초기 랜더링이 13초가 걸리더라구요.. 이게 무엇인지랑 어떻게 해결해야하나요.. react query 사용하지 않으면 1초도 안걸리면서 랜더링합니다..

Alb, nginx, was에 관하여 질문이 있습니다.

사진과 같이 AWS alb 아래 spring boot 서버 2개를 배포할 예정인데 nginx를 꼭 포함시켜야 하나 고민되어 질문드립니다. 자세하게 알지는 못하지만 리버스 프록시 용도도 필요 없을것 같고 htts 처리도 로드 밸런서가 처리해주고... 캐싱 용도로 사용하기 위해 alb 아래 was 사이에 nginx 를 하나씩 둬야 할까요..? 로드밸런서가 있을때 nginx의 역할이 정말 필요한가 의문이 들어 질문 드립니다!!

프론트엔드 개발자가 트래픽 제어에 관여할 수 있는 부분은 무엇일까요?

안녕하세요. 항상 커리어리를 통해서 선배 개발자분들에게 멀리서나마 많은 지식과 경험을 쌓고 있는 이상원입니다 :) 금일은 다름이 아니라, 이전에 면접 시에 프론트엔드 개발자가 트래픽 제어에 관여할 수 있는 부분은 무엇인지에 대한 질문을 받았었는데, 당시에 기억났었던 것은 디바운싱이나 쓰로틀링을 구현하여 한 시간내에 유저의 Interaction을 잘게 초단위로 나누어 서버에 전송하면 해결할 수 있다고 했던 것 같은데, 이외에도 방법들이 여럿 있다고 들어서 그 방법에 대하여 조사를 진행하게 되었습니다. 그러던 와중에 쿠팡 엔지니어 분께서 적용하신 글을 찾게 되었는데, 해당 글이 서버 측에서 할 수 있는 캐시를 활용한 트래픽 처리라는 것을 알게 되었습니다. 그렇다면 프론트엔드에서 트래픽 제어에 기여할 수 있는 부분은 무엇이 있는지 궁금합니다 ! 서버개발진들처럼 캐싱을 활용하여 제어가 가능할 것 같긴한데 구체적인 사례들이 잘 보이지 않아서 인사이트를 얻고 싶습니다. 쿠팡 관련 medium은 아래와 같습니다. https://medium.com/coupang-engineering/%EC%BA%90%EC%8B%9C%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%9C-%EB%8C%80%EC%9A%A9%EB%9F%89-%ED%8A%B8%EB%9E%98%ED%94%BD-%EC%B2%98%EB%A6%AC-%EC%84%B1%EB%8A%A5-%ED%96%A5%EC%83%81-a274f4731d07

web was 분리 실습관련 질문입니다..

안녕하세요. 20살 대학생입니다. web 서버와 was 서버 분리 관련하여 질문드립니다. web과 was의 개념은 조사하였는데, 이를 실 적용하려니 궁금한 사항이 있습니다. web was 개념파악을 위해 아파치와 톰켓을 사용하여 2개의 서버에 나누어 구축하고 있는데 블로그 등을 조사하니 제가 알던 web은 정적처리, was는 동적인 처리 개념이 아닌 was에서 처리를 전부 하면서 web은 그저 리버스 프록시, 정적 파일(html,css,image 등) 적재 등으로만 사용하는 것 같습니다. (즉, web server는 그저 네트워크 장비같은 역할??) 여기서 궁금한 사항입니다. 1. 정적처리, 동적 처리라는 부분을 구현하고 싶다면 페이지 별로 나누어 구성해야 할까요? (원래는 모든 페이지는 web server에 존재하며 was에서는 동적 처리만 구현하도록 하고싶었으나, 단순하게 구현하자면 정적페이지(html)는 web에서 아파치로 바로, 동적 페이지(jsp)는 was에서 구동하는 식으로 진행할까 생각중 입니다. 이렇게 해도 무방한지 궁금합니다.) 2. 프로젝트마다 구성의 차이는 당연히 있겠지만, 요즘 추세로서는 web,was 분리를 어떤식으로 하는지 궁금합니다. (정적,동적 처리 분류 하거나 모두 was에서 담당하고 web은 프록시, 캐싱 역할만 하는지..) 3. 프레임워크(spring, django, flask 등) 을 was 처럼 사용한 경우가 있을까요? (조사해보니 여러 경우가 나오지만 실제로 많이 사용하는지 궁금합니다.) 긴 글 읽어주셔서 너무 감사합니다.

ReactQuery 사용 중에 url이 변경되는 경우, 자동으로 리페칭되나요?

회사에서 react query를 도입하는 중입니다. 기존 코드에서는 서로 다른 페이지에서 같은 api를 지속적으로 요청하여 데이터를 받아오고 있습니다. 받아오는 데이터가 변경이 거의 없는 데이터라서, react-query의 캐싱기능을 사용하여, 불필요한 api 요청을 방지하려고 했습니다. 그런데 개발자 도구 네트워크탭에서 확인해보니, 페이지 url 경로가 변경될 때마다, 데이터가 fresh 상태임에도 불구하고 계속하여 데이터를 요청하는 api를 보내고 있습니다. staleTime도 60분으로 설정했고, 데이터가 fresh 상태임도 확인해보았습니다. 혹시 옵션값과는 상관없이, url이 변경되었을 경우(ex localhost:3000/main -> /setting) 데이터 리페칭이 자동으로 일어나는 건가요? url이 변경되었을 때, 데이터가 fresh 상태라면 리페칭을 하지 않게 하고 싶습니다.

Next 13과 react 18 서버 컴포넌트 관련 질문 (질문이 좀 길어요)

안녕하세요, 요즘 next 13과 react 18 서버 컴포넌트에 대해서 본격적으로 파고 있는데 궁금한 점들이 여러가지 떠올라서 글 올립니다. 1. data fetching 방식의 변경 우선 기존에는 동적인 data fetching의 경우, getServersideProps를 통해서 페이지의 root에 전달해주고는 방식이 일반적이었는데 서버에서만 돌아가는 서버 컴포넌트가 나오면서 data fetching을 컴포넌트 단위로 할 수 있게되면, 기존에 사용하던 getServersideProps 같은 유틸 함수들은 사라지는건가요? 기존에는 정적 데이터면 getStaticProps, 동적 데이터면 getServersideProps, 유저 상호작용이 필요한 데이터면 client side useEffect를 많이 사용했는데 next 13부터는 이게 뭔가 뒤섞이는 것 같아서 혼란스럽네요. next 13을 위한 data fetching 패턴이나 방법론이 있나요? 2. 기존에 사용하던 상태 관리 프레임워크의 변화 위와 어느정도 연결되는 이야기입니다. 기존에 react-query를 많이 사용했는데 next 13부터 컴포넌트 레벨로 데이터를 요청할 수 있고 또 next 차원에서 요청 중복 제거를 지원하게되면 react-query 처럼 서버 상태관리와 캐싱을 강점으로 내세우는 프레임워크의 역할을 어떻게 되는건가요? 서버 상태를 컴포넌트 레벨에서 가져올 수 있다고 해도, 여전히 전역 상태 관리가 필요할 것 같은데 recoil, redux, zustand 같은 상태 관리 프레임워크도 계속 쓰게되는 것일까요? 계속 쓰게 된다고 하면 서버 컴포넌트와의 호환성은 어떻게 되는건가요? 만약 전역 상태 관리를 써야하는 컴포넌트라면 서버 컴포넌트가 될 수 없는 것인가요? 3. 서버 구성의 변경 다른 곳은 모르겠지만, 저는 next 백엔드를 단순히 요청을 전달하는 용도로만 쓰고 실제로 중요한 로직은 다른 백엔드 서버에서 처리하는 구조를 가지고 있었습니다. 하지만, next 13을 보니 서버 컴포넌트에서 DB 연결을 직접해서 데이터를 가져오는 예시들도 있더군요. 사이드 프로젝트라면 모르겠지만, 실 서비스에서도 서버 컴포넌트 - DB 직접 연결 이라는 구조가 성립할 수 있는건가요? 기존에 데이터를 취합하고 내려주던 백엔드 서버의 역할이 생략되는거라고 생각해도 되는건가요? 4. 왜 다시 20년 전으로 돌아가는거죠 제가 20년 동안 개발한 것은 아니지만, 예전에는 웹페이지를 서버에서 완전히 로드해서 내려주는 형태를 가지고 있었다고 배웠습니다. 그러다가 개개인의 기기가 스펙이 좋아지면서 서버 부하를 줄이고 클라이언트 쪽에서 역할을 분담하는 방식이 떴다고 들었어요. react도 처음에는 이런 프레임워크로 나왔다고 알고 있습니다. 그러다가 next, remix 같은 프레임워크들이 서버사이드 렌더링을 적극적으로 장려하면서 다시 회귀하고 있다고 들었습니다. 최근에는 react 마저 서버 컴포넌트를 발표했잖아요. 왜 이제와서 다시 서버 쪽에서 페이지를 로드하는 방식을 추진하고 있는건가요? 질문을 적고보니 좀 길어졌는데, 서핑을 좀 해봐도 마땅히 도움이되는 글이 별로 없어서 현직자들은 어떻게 생각하시는지 의견을 얻고자 질문 올립니다!

EDA에서 스냅샷을 찍는다는건 뭔가요?

요즘 EDA 공부를 하고 있는데, “스냅샷을 찍는다”라는 표현이 뭔지 헷갈려서 질문합니다. 제가 이해하기로는 이벤트 스토어에 저장된 모든 이벤트를 리플레이한 특정 상태를 캐싱해놓는다 입니다. 질문은 이 스냅샷이라는 것은 어떻게 만드는 것이며 이걸 어디다 어떻게 저장하는거죠? 그리고 이 캐싱된 상태를 저장해놓는거면 이전 이벤트 스토어의 데이터는 날려버려도 되는것 아닌가요?

useQuery로 가져온 데이터를 자식 컴포넌트에서 어떻게 사용하는게 좋은지 궁금합니다.

useQuery를 사용해 부모 컴포넌트에서 데이터를 가져온 후, 해당 데이터를 자식 컴포넌트에서 사용할 때 세 가지 방법 중 어떤 것이 좋은지 궁금합니다. 1. 부모 컴포넌트에서 내려 받는다. 2. 자식 컴포넌트에서 query 요청을 한 번 더 한다. 3. 쿼리 클라이언트에서 캐싱된 값을 사용한다. 다른 분들은 이런 상황에서 어떤 방식으로 데이터를 받아오는지 알고 싶습니다!!

사용자가 생성하는 컨텐츠에 대해서 Sitemap 을 동적으로 생성해주려고 하는데 Sitemap 을 위한 전용 테이블을 추가하는 방법이 효율적일까요 ?

이번에 Sitemap 을 추가해야 하는데 사용자가 생성하는 컨텐츠라서 dynamic url path 를 가집니다. ex) articles/[:id] 그래서 사이트맵을 직접 만들어 줘야 하는데 어떤 방법으로 해야할지 고민이에요. 현재 문제는 테이블의 updatedAt 값을 sitemap 의 lastmod 값에 어떻게 적용할지 인데요. 처음에 생각한 방법은 Article 테이블의 updatedAt 을 그대로 사용해서 sitemap 을 동적으로 만들어 주려고 했는데, 이렇게 하면 실시간으로 페이지를 생성하는데 한계가 있어서 캐싱이 무조건 필요 하겠더라고요. 그래서 차라리 테이블을 추가해서 (ArticleSitemap ?) 여기에 updatedAt 을 실시간으로 업데이트 시켜두고 Sitemap 생성에 활용하려고 하는데 문제 없을까요 ? 참고로 사용하는 스택은 next.js, nest.js, MySQL 입니다.

react infinite scroll 최적화 방법?

리액트 웹 앱에서 인피니트 스크롤을 적용하고 있는데요. 컨텐츠가 적을때는 크게 이슈가 없었는데 많으니까 버벅거리기 시작하더라구요. 코드를 첨부하기가 애매한 상황인데, 제가 적용한 방법을 공유하자면 우선 react-query로 각 페이지 데이터를 캐싱하고 있구요. 인피니트 스크롤 속 아이템들은 key를 id 값으로 지정하고 memo로 감싸놓은 상태입니다. 이렇게 했을때 버벅거림이 어느정도 해소가 되기는 하는데, 여기서 더 최적화 할 수 있는 방법이 있는지 궁금합니다. 혹시 좋은 방법이 있으시면 공유 부탁드립니다. 감사합니다.

react-query가 데이터를 캐싱하는거 맞나요?

이번에 react-query를 처음 사용해 보는데요. 데이터를 키에 캐싱해서 보여준다고 공식문서에 적혀있던데 사용해보면서 느낀건 캐싱되고 있는거 맞는지 의문점이 생깁니다. 가장 큰 이유는 데이터를 계속 불러오기 때문입니다. 캐싱된 데이터를 가지고 어느정도 API요청을 줄이고 효율적으로 사용할 수 있을 줄 알았는데 매번 hook을 실행할 때마다 혹은 데이터와 관련없는 버튼을 누를때도 렌더링 될때마다 API요청이 일어나더라고요. 물론 제가 처음이라 잘 사용하는 방법을 몰라서 그렇기도 한데 이렇게 사용하는 거라면 더 비효율적인것 같아요 ㅜㅜ