proxy 이슈 해결하기(Netlify)

Netlify에서 Proxy 이슈 해결하기

Netlify에서 프론트엔드 애플리케이션을 배포할 때, 서버 사이드의 API 호출이나 다른 외부 요청에 대한 proxy 설정이 필요할 때가 있습니다. 이러한 proxy 이슈를 피하기 위한 방법으로 _redirects 파일과 netlify.toml 파일을 사용하는 방법이 주로 알려져 있습니다.

1. `_redirects` 파일 사용하기

Netlify는 _redirects 파일을 통해 경로 리다이렉션 및 proxy 설정을 할 수 있습니다. 이 파일은 프로젝트의 루트 디렉토리에 위치시키며, 간단한 설정으로 proxy 이슈를 해결할 수 있습니다.

예시:

# /api/* 경로의 요청을 <http://localhost:5000/api/*> 로 proxy
/api/* <http://localhost:5000/api/:splat> 200

이 설정은 /api/로 시작하는 모든 요청을 로컬 서버의 /api/로 proxy 하도록 합니다. :splat은 와일드카드 매칭을 나타내며, 모든 하위 경로를 매칭해줍니다.

2. `netlify.toml` 파일 사용하기

netlify.toml 파일은 Netlify 설정을 관리하는 파일로, proxy 설정을 포함한 다양한 배포 옵션을 설정할 수 있습니다.

예시:

[[redirects]]
  from = "/api/*"
  to = "<http://localhost:5000/api/:splat>"
  status = 200
  force = true

이 설정은 _redirects 파일과 동일한 역할을 하며, Netlify의 고급 설정이 필요한 경우 netlify.toml 파일을 사용하는 것이 좋습니다.

Next.js에서 Proxy와 Middleware 설정

프록시 설정을 관리할 때 Next.js에서 제공하는 설정 옵션을 활용할 수도 있습니다. 아래는 Next.js의 next.config.js와 Middleware를 통해 proxy와 404 에러 처리를 구현한 예시입니다.

`next.config.js` 설정

next.config.js 파일에서 proxy 설정을 위해 rewrites 옵션을 사용할 수 있습니다. 이 옵션은 특정 경로에 대한 요청을 다른 URL로 리다이렉트합니다.

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  swcMinify: true,
  compiler: {
    styledComponents: true,
  },
  webpack(config) {
    config.module.rules.push({
      test: /\\.svg$/,
      use: ['@svgr/webpack'],
    })
    return config
  },
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'triptune.s3.ap-northeast-2.amazonaws.com',
        port: '',
        pathname: '/**',
      },
    ],
  },
  async rewrites() {
    return [
      {
        source: '/api/:path*',
        destination: '<http://13.209.177.247:8080/api/:path*>',
      },
      {
        source: '/api/:path*',
        destination: '/404',
        has: [
          {
            type: 'query',
            key: 'path',
            value: '^(?!.*\\\\/api\\\\/).*$',
          },
        ],
      },
    ]
  },
}

module.exports = nextConfig

이 설정에서는 /api/:path*로 시작하는 요청을 http://13.209.177.247:8080/api/:path*로 프록시합니다. 추가로, 특정 쿼리 파라미터 조건에 따라 404 페이지로 리다이렉트할 수도 있습니다.

Middleware를 통한 404 에러 처리

Next.js에서는 Middleware를 사용하여 API 요청을 처리하고, 특정 조건에 따라 404 에러를 반환할 수 있습니다.

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(req: NextRequest) {
  const { pathname } = req.nextUrl;

  // /api 경로로 시작하지만 /api/ 포맷이 아닌 경우 404로 리다이렉트
  if (pathname.startsWith('/api') && !/\\/api\\//.test(pathname)) {
    return NextResponse.rewrite('/404');
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/api/:path*'],
};

이 미들웨어는 /api로 시작하는 경로를 체크하고, 올바른 포맷이 아닌 경우 404 페이지로 리다이렉트합니다. matcher를 통해 /api/:path* 경로에만 이 미들웨어가 적용되도록 설정합니다.

Next.js에서 `rewrites` 설정이 필요한 이유는 무엇인가요?

Next.js에서 rewrites 설정은 클라이언트 측에서 보낸 요청을 서버의 다른 엔드포인트로 리다이렉트하거나 proxy할 때 필요합니다. 이 설정은 주로 다음과 같은 경우에 사용됩니다:

API Proxy 설정: 클라이언트에서 서버로 직접 API 호출을 하지 않고, Next.js 서버를 통해 요청을 중계하여 CORS 이슈를 해결하거나, API 엔드포인트를 숨기고 싶을 때 유용합니다.
URL 구조 변경: 사용자에게 보여지는 URL과 실제 리소스 경로가 다를 때, URL을 사용자 친화적으로 유지하면서 실제로는 다른 경로를 사용하도록 할 수 있습니다.
리다이렉션 관리: 특정 경로를 다른 URL로 자동으로 리다이렉트 시켜야 하는 경우에 사용됩니다.

이런 설정을 통해 애플리케이션의 구조를 유지하면서도 유연하게 라우팅을 관리할 수 있습니다.

Next.js 미들웨어를 사용하여 API 요청을 제어할 때 주의할 점은 무엇인가요?

Next.js에서 미들웨어를 사용하여 API 요청을 제어할 때 주의할 점은 다음과 같습니다:

미들웨어의 순서와 적용 범위: 미들웨어가 적용될 경로와 순서를 명확히 설정해야 합니다. matcher 옵션을 통해 특정 경로에만 미들웨어를 적용할 수 있도록 설정하는 것이 중요합니다.
성능 고려: 미들웨어는 각 요청에 대해 실행되기 때문에, 복잡한 로직이나 긴 처리 시간을 요구하는 작업은 성능에 영향을 줄 수 있습니다. 최대한 간단하고 빠르게 처리되도록 코드를 작성해야 합니다.
보안 처리: 미들웨어에서 요청을 처리할 때 보안 관련 처리를 신중하게 해야 합니다. 민감한 데이터가 노출되지 않도록 하고, 인증이나 권한 체크 로직을 적절하게 추가해야 합니다.
에러 핸들링: 미들웨어에서 예상치 못한 에러가 발생할 수 있으므로, 에러 핸들링을 적절하게 구현하여 애플리케이션의 안정성을 유지해야 합니다.

이러한 점을 주의하여 미들웨어를 사용하면 보다 효과적으로 요청을 관리하고, 애플리케이션의 유연성을 높일 수 있습니다.

Netlify와 다른 배포 플랫폼에서의 proxy 설정 차이점은 무엇인가요?

Netlify와 다른 배포 플랫폼에서의 proxy 설정 차이점은 다음과 같습니다:

설정 방식: Netlify는 _redirects 파일이나 netlify.toml 파일을 사용하여 proxy 설정을 관리합니다. 반면, Vercel은 vercel.json 파일에서 rewrites와 redirects 설정을 통해 비슷한 기능을 제공합니다. Heroku는 서버에서 직접 Nginx 설정이나 Node.js 코드에서 proxy 설정을 처리해야 합니다.
유연성: Netlify는 간단한 설정 파일로 proxy를 쉽게 설정할 수 있지만, Vercel은 더 세분화된 조건과 고급 기능을 제공합니다. Heroku의 경우, 완전한 서버 접근이 가능하여 커스텀 설정이 자유롭지만, 설정이 복잡해질 수 있습니다.
CORS 및 보안: 각 플랫폼은 CORS 처리 방식이 다를 수 있습니다. Netlify와 Vercel은 기본적으로 정적 사이트 호스팅을 지향하기 때문에, 프록시 설정이 CORS를 우회할 때 유용합니다. Heroku는 서버 측에서 직접 처리하기 때문에 더 복잡한 보안 설정이 가능합니다.
배포 관리: 각 플랫폼은 배포 관리 방식이 다릅니다. Netlify와 Vercel은 git 기반의 자동 배포 파이프라인을 지원하여 설정 변경이 자동으로 반영됩니다. Heroku는 배포 파이프라인을 커스터마이징할 수 있는 자유도가 높지만, 설정이 자동화되지 않아 관리에 더 많은 신경을 써야 할 수 있습니다.