Nextjs에서 미들웨어가 없다면 백엔드 게이트웨이를 써서(이가 없으면 잇몸으로..!), 그리고 Nextjs미들웨어와 무관한 초경량 프록시를 두는 방법에 대해.
Nextjs 15.3.3 에서는 turbopack을 사용했을 시 공식적으로 middleware 사용 불가인 점이 명시되어 있습니다.
한편, turbopack을 포기하고 webpack을 사용했을 시에는 middleware를 사용할 수 있다고는 하는데요,
거기에도 여러 상황에서 미들웨어가 그대로 패싱되어버리는 불편함이 있어서, 그런 모든 상황을 컨트롤할 수 없는 nextjs 비숙련자 입장에서는 미들웨어가 너무도 불확실한 솔루션으로 보이게 되는 것 같습니다.
게이트웨이가 더 강력한 방법이고, 지금 서브도메인 별로 별도 웹사이트를 하기로 분리했기 때문에, 지금 각 미들웨어에 집중하느니 하나의 게이트웨이에 집중하는게 나을 수 있겠다.
프론트에 미들웨어의 역할은 필수이고, 만약 없다면 게이트웨이에 미들웨어가 했어야 했을 역할도 넘겨주어야 함. 그건 주로 봇 차단과 보안 관리.
미들웨어가 있었다면, biblecardai.blessflow.com → Next.js 앱 → middleware.ts → 로그인 여부 검사 → /dashboard or /login
미들웨어가 없다면 먼저 게이트웨이를 통해서 프론트앱으로 전달된다. biblecardai.blessflow.com → API Gateway → 로그인 체크 후 → Next.js 앱에 프록시 전달
여기서 봇이 직접 프론트에 접근해서 폭풍 GET 요청을 보냈던 경험은 방금 하고 왔기에 위 문제에 크게 공감한다.
https://blog.naver.com/devramyun/223902203888
[20250617] 봇한테 스캔당함..ㄷㄷ nextjs 프론트를 만들다가 npm run dev를 했을 뿐인데 알 수 없는 로그가 계속 띄워졌다. 다음과 같이 수정… nextjs 프론트를 만들다가 npm run dev를 했을 뿐인데 알 수 없는 로그가 계속 띄워졌다. 다음과 같이 수정…
그걸 막는 미들웨어 역할이 중요하고, 미들웨어가 시원찮다면 확실하게 백엔드 게이트웨이에 그 역할을 넘겨주는게 맞는다고 본다.
ㅎㅎ
역시 각 요소의 제 역할이 있는 법.
nextjs의 미들웨어 지원이 못미더워서 빼려고 했으나, 가벼운 프록시로 게이트웨이의 책임을 분산하는게 좋으므로 비슷한 역할의 프록시 서버를 맨 앞단에 넣기로 한다.
참고)
#python_fastapi_MSA서버_성경말씀이미지카드_자동생성_서비스