⚛️ React

<img src="https://image.until.blog/morethanmin/article/1716912103640" alt="until-344"><blockquote><p>next.js 의 pages router 기준으로 작성되었어요.</p></blockquote><p>next.js서버사이드에서 데이터를 prefetch하기 위해서 리액트쿼리에서 제안하는 방식은 크게 두가지가 존재한다.</p><ol><li><p>데이터 패칭을 한 뒤에 <code spellcheck="false">serverSideProps</code>의 props로 넘겨주는 방식</p></li><li><p>서버사이드에서 <code spellcheck="false">queryClient</code>에 데이터를 저장하고, <code spellcheck="false">queryClient</code>자체를 <code spellcheck="false">dehydrate</code>하여 넘겨주는 <code spellcheck="false">Hydration</code> 방식</p></li></ol><p>첫번째 방식은 비교적 간단하지만 props drilling이나 여러곳에서 사용할 경우 initialData를 넣어주는 것이 까다롭다는 단점이 있다.</p><p>때문에 프리패칭하는 데이터가 여러곳에 존재하고, 복잡할 경우 두번째 방식을 사용하는 것이 좋을것이다.</p><p><code spellcheck="false">Hydration</code>방식을 사용하기 위해서는 <code spellcheck="false">fetchQuery</code>와 <code spellcheck="false">prefetchQuery</code>의 차이점을 알아보자.</p><h1>prefetchQuery</h1><p>prefetchQuery는 결과값을 리턴하지 않으며, 데이터 패칭에 실패할 경우 에러를 던지지 않는다는 특징을 가지고 있다.</p><p>따라서 데이터를 불러오지 못하더라도, UI를 그려줄 수 있는 경우에는 prefetchQuery를 사용하면 된다.</p><pre spellcheck="false"><code class="language-typescript">// ...
await queryClient.prefetchQuery({
  queryKey: queryKeys.articles()
  queryFn: getArticles()
});
// ...</code></pre><h1>fetchQuery</h1><p>fetchQuery와 같은 경우에는 결과값을 리턴하고, 데이터 패칭에 실패하는 경우에는 에러를 던진다.</p><p>따라서 error handling이 가능하다는 얘기이다.</p><p>언틸에서의 블로그 프로필 페이지를 예로 들어보자.</p><pre spellcheck="false"><code class="language-typescript">export const getServerSideProps: GetServerSideProps = async (context) =&gt; {
  try {
    setCookie(context)
    const username = getUsername(context)await queryClient.fetchQuery({
      queryKey: queryKeys.blog.username.body(username),
      queryFn: createGetBlog(username),
    })
    return {
      props: {
      dehydratedState: dehydrate(queryClient),
    },
  }} catch (error) {
    return {
      notFound: true,
    }
  }
}</code></pre><p>블로그를 조회하는 api는 잘못된 username으로 요청하는 경우 404 페이지를 보여줘야 하기에 <code spellcheck="false">fetchQuery</code>를 통해 구현해주었다.</p><p>또한 return value를 사용하는 경우에도 fetchQuery를 사용해 구현해줄 수 있다.</p><p></p><p></p>

next.js 의 pages router 기준으로 작성되었어요.next.js서버사이드에서 데이터를 prefetch하기 위해서 리액트쿼리에서 제안하는 방식은 크게 두가지가 존재한다.데이터 패칭을 한 뒤에 serverSideProps의 props로 넘겨주는 방식서버사이드에서 queryClient에 데이터를 저장하고, queryClient자체를 dehydrate

react-query의 fetchQuery과 prefetchQuery

🪟 Window

<img src="https://image.until.blog/morethanmin/article/1716045513650" alt="until-71"><p>항상 맥북만 사용하다가 이번에 데스크탑을 맞추게 되면서 개발환경을 윈도우에서 세팅하게 되었다.</p><h2>fnm이란?</h2><p>노드 버전을 관리할 수 있게 해주는 매니저로 nvm과 유사하지만 윈도우에서는 nvm이 지원되지 않기 때문에 fnm를 사용해보려고한다.</p><h2>winget으로 fnm 설치하기</h2><p>파워쉘에서 아래와 같이 입력하여 설치할 수 있다.</p><pre spellcheck="false"><code>winget install Schniz.fnm</code></pre><h3>0x8a15000f 오류가 발생하는 경우</h3><p>마이크로소프트 스토어에서 앱 설치 관리자를 업데이트 해주면 된다.</p><img src="https://image.until.blog/morethanmin/article/1716045690970" alt="until-72"><h2>fnm으로 node 설치하기</h2><h3>프로필 설정</h3><p>우선 <code spellcheck="false">PowerShell</code>프로필에 환경변수를 등록해야한다.</p><p><code spellcheck="false">~\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1</code> 경로에 아래와같이 입력 해주면 된다.</p><pre spellcheck="false"><code>fnm env --use-on-cd | Out-String | Invoke-Expression</code></pre><h3>PowerShell 실행시 PSSecurityException 오류가 발생하는 경우</h3><p>기본적으로 스크립트 삽입하는 것이 막혀있기 때문에 설정을 바꿔줘야한다.</p><p>관리자 권한으로 <code spellcheck="false">PowerShell</code> 을 실행해서 아래와 같이 입력한다.</p><pre spellcheck="false"><code>Set-ExecutionPolicy RemoteSigned</code></pre><h3>node 설치</h3><p>이제 <code spellcheck="false">PowerShell</code> 을 재부팅하고 아래와 같이 입력해 노드를 설치하면된다.</p><pre spellcheck="false"><code>fnm use --install-if-missing 20</code></pre><hr><p>그럼 이제 node를 사용할 수 있다! 근데 PowerShell도 그렇고 여러 이슈들도 그렇고 좀 귀찮은 것 같다. 좀 더 사용해보다가 정 안되면 wsl을 사용해야겠다.</p><p></p><p></p><p></p><p></p>

항상 맥북만 사용하다가 이번에 데스크탑을 맞추게 되면서 개발환경을 윈도우에서 세팅하게 되었다.fnm이란?노드 버전을 관리할 수 있게 해주는 매니저로 nvm과 유사하지만 윈도우에서는 nvm이 지원되지 않기 때문에 fnm를 사용해보려고한다.winget으로 fnm 설치하기파워쉘에서 아래와 같이 입력하여 설치할 수 있다.winget install Schniz.fn

윈도우에서 winget으로 fnm 설치하기 (Fast Node Manager)

🖥 백엔드

<p>스프링을 싫어하는 사람들이 많이 하는 말이 있다. 스프링은 어노테이션이 덕지덕지 붙어서 극혐이라고..</p><p>하지만 어노테이션도 잘 쓰면 로직을 간단히 추상화해줄 수 있어서 좋은 점이 많다.</p><p></p><p>어노테이션을 이용해서 로그인한 유저만 api를 호출할 수 있도록 하고, 미로그인 유저는 400 에러를 발생하도록 필터링하는 기능을 구현해보려고 한다.</p><p></p><pre spellcheck="false"><code>@NeedLogin
@Operation(summary = "아티클 작성하기")
@PostMapping("/{username}/articles")
fun writeArticle(
    @PathVariable("username") username: String,
    @RequestBody request: BlogArticleWriteRequestDTO,
) {
    TODO("로직은 알아서 잘 딱 깔끔하게")
}</code></pre><p>설명하기 앞서, 원하는 결과물은 이렇다.</p><p>api의 위에 <code spellcheck="false">@NeedLogin</code> 어노테이션을 붙이는 것 만으로 API가 로그인을 필요로 한다는 것을 명시적으로 나타내줄 수 있다.</p><p></p><p>언어는 코틀린으로 짜여있지만, Java로도 코드가 크게 다르진 않을 것이니 따라가봅시다</p><p>레츠고~</p><hr><pre spellcheck="false"><code class="language-kotlin">@Retention(AnnotationRetention.RUNTIME)
@Target(AnnotationTarget.FUNCTION)
annotation class NeedLogin</code></pre><p>간단하게 어노테이션을 만들어주자. API가 실행될 때 로그인 상태를 검증하는 것이니 RUNTIME이고, 함수에 붙여줄 생각이니 타겟은 FUNCTION으로 한다.</p><p></p><pre spellcheck="false"><code class="language-kotlin">@Component
class NeedLoginInterceptor(
    private val tokenProvider: TokenProvider,
) : HandlerInterceptor {
    override fun preHandle(
        request: HttpServletRequest,
        response: HttpServletResponse,
        handler: Any,
    ): Boolean {
        // NeedLogin 어노테이션이 붙어있지 않은 함수면 패스
        if (!hasNeedLoginAnnotation(handler)) {
            return true
        }

        // 로그인된 상태인지 체크
        if (!hasValidAccessToken(request)) {
            throw UserNotAuthorizedException()
        }

        return true
    }

    private fun hasValidAccessToken(request: HttpServletRequest): Boolean {
        return getAccessCookie(request)
            ?.let { tokenProvider.validateToken(it) }
            ?: false
    }

    private fun hasNeedLoginAnnotation(handler: Any): Boolean {
        return handler is HandlerMethod &amp;&amp;
            handler.method.isAnnotationPresent(NeedLogin::class.java)
    }
}</code></pre><p>api가 호출될 때 마다 검증해야 하기 때문에 Interceptor를 사용해준다. <code spellcheck="false">HandlerInterceptor</code>를 상속받아서 <code spellcheck="false">NeedLoginInterceptor</code>라는 클래스를 만들었다.</p><p>'api가 실행되기 전에' 로그인 상태를 검증해야 하므로 <code spellcheck="false">preHandle</code>에 로직을 적어넣었다.</p><p></p><p>NeedLogin 어노테이션이 붙어있는지 체크해서 없을 경우 패스하기 위해 리턴 시켜준다.</p><p>그 후 각자의 방법으로 로그인 여부를 체크해준 후 미로그인 상태일 경우 Exception을 터트려주면 된다. 나는 AccessToken을 이용하는 방법을 사용했기 때문에 해당 방법으로 구현해주었다.</p><p></p><pre spellcheck="false"><code class="language-kotlin">@Configuration
class WebConfig(
    private val needLoginInterceptor: NeedLoginInterceptor
) : WebMvcConfigurer {
    override fun addInterceptors(registry: InterceptorRegistry) {
        registry.addInterceptor(needLoginInterceptor)
            .addPathPatterns("/**")
    }
}</code></pre><p>마지막으로는 인터셉터를 적용해주기 위해 WebMvcConfigurer에다가 내가 만든 인터셉터를 적용해주었다.</p><p>그러면 끝!</p><p></p><pre spellcheck="false"><code class="language-kotlin">@NeedLogin
@Operation(summary = "아티클 작성하기")
@PostMapping("/{username}/articles")
fun writeArticle(
    @PathVariable("username") username: String,
    @RequestBody request: BlogArticleWriteRequestDTO,
) {
    TODO("로직은 알아서 잘 딱 깔끔하게")
}</code></pre><p>나머지는 이렇게 api 위에다가 NeedLogin 어노테이션만 붙여주면 된다.</p><p></p><pre spellcheck="false"><code class="language-kotlin">@RestControllerAdvice
class GlobalExceptionHandler {
    @ExceptionHandler(UserNotAuthorizedException::class)
    fun handleUserNotAuthorizedException(exception: UserNotAuthorizedException): ResponseEntity&lt;ErrorResponse&gt; {
        return ResponseEntity.status(HttpStatus.UNAUTHORIZED)
            .body(ErrorResponse(exception.message))
    }
}</code></pre><p>마지막으로 예외가 발생했을 때 400 에러와 exception 메시지를 출력해주기 위해 ExceptionHandler로 받아다가 원하는 에러 코드와 메시지를 전달해주면 된다.</p><p></p><pre spellcheck="false"><code>{
  "error": "로그인이 필요합니다."
}</code></pre><p>그러면 이렇게 API를 실행했을 때 401 에러와 함께 메시지가 떨어져나오는 모습을 볼 수 있다~</p><p></p><p>앞으로도 인터셉터와 어노테이션 기능을 잘 활용하여 로직을 잘 추상화하고 반복을 제거해보자</p>

어노테이션으로 로그인 체크 쉽게 하기!

어노테이션으로 로그인한 유저만 api를 호출할 수 있도록 간단히 필터링하기

<h1><strong>들어가기 전에</strong></h1><p>Nest.js는 Node.js 진영에서 널리 쓰이고 있는 서버 프레임워크이다.</p><p>그리고 이런 서버를 클라우드 환경에 배포하기 위해서는 AWS EC2, Oracle Cloud 등의 컴퓨팅 인스턴스 위에 올리는 방법이 정석이겠다.</p><p>&nbsp;</p><p>하지만 Nest.js는 서버리스를 지원하고, Vercel은 서버리스를 지원한다.<br>이를 이용해서 무료로 간단히 Vercel에 서버를 배포할 수 있다.</p><p></p><h1>방법</h1><p>방법 자체는 간단하다. 프로젝트 최상단에&nbsp;<code spellcheck="false">vercel.json</code>을 만들고 다음과 같이 작성한다.</p><pre spellcheck="false"><code class="language-json">{
  "version": 2,
  "builds": [
    {
      "src": "src/main.ts",
      "use": "@vercel/node"
    }
  ],
  "routes": [
    {
      "src": "/(.*)",
      "dest": "src/main.ts",
      "methods": [
        "GET",
        "POST",
        "PUT",
        "DELETE"
      ]
    }
  ]
}</code></pre><p><span>그 후 </span><code spellcheck="false">npm install -g vercel</code><span> 을 실행한 후, 프로젝트 최상단 경로에서 </span><code spellcheck="false">vercel .</code><span>를 실행하면 완성된다.</span></p><p></p><h1>트러블 슈팅</h1><h2>Cannot find module</h2><img src="https://image.until.blog/octoping/article/1730787106060.png" data-width="75%" data-align="center" alt="1972"><p><span>배포를 했지만 다음과 같은 오류가 떠서 처음에 큰 고생을 했다.</span></p><p><span>Vercel에서 로그를 확인해보니 아래와 같은 에러 로그가 있었다.</span></p><pre spellcheck="false"><code class="language-log">2023-08-18T17:52:14.322Z	undefined	ERROR	Cannot find module 'src/infra/prisma/PrismaService'
Require stack:
- /var/task/src/feed/feed.module.js
- /var/task/src/app.module.js
- /var/task/src/main.js
2023-08-18T17:52:14.323Z	undefined	ERROR	Did you forget to add it to "dependencies" in `package.json`?
RequestId: 059dec36-4319-4851-9c23-3ecf01978f18 Error: Runtime exited with error: exit status 1
Runtime.ExitError</code></pre><img src="https://image.until.blog/octoping/article/1730787132600.png" data-width="100%" data-align="center" alt="1974"><p>분명 잘 존재하는 모듈을 발견하지 못하고 있다고 에러가 떴다.</p><p>왜;;인지 도저히 알기가 어려워 많이 헤맸는데, 문제는 내 import 문에 있었다.</p><pre spellcheck="false"><code class="language-typescript">import { PrismaService } from '@/infra/prisma/PrismaService';</code></pre><p>다음과 같이 path alias를 사용해서 절대 경로로 import 하는 경우 Vercel이 경로를 인식을 못하는 이슈였다.</p><p></p><p><code spellcheck="false">src/infra/prisma/PrismaService</code>&nbsp;처럼 @를 안 쓰고 절대경로로 쓰더라도 마찬가지였다. 상대경로로 작성해야 한다!</p><p></p><h2>Swagger 페이지 404 에러 (검증 못 해봄)</h2><p><span>다른 페이지는 잘 나오지만 Swagger 페이지만 아무것도 안 나오는 이슈 (404 에러)가 발생한다.</span></p><pre spellcheck="false"><code>Uncaught ReferenceError: SwaggerUIBundle is not defined
    at window.onload</code></pre><p>개발자 도구를 켜보면 이런 로그가 나온다.</p><p>C# 쪽 스웨거에서도 한번 제보된 문제이긴 하다. swagger ui 파일이 서버리스에 올라가기에는 너무 크다는 이슈다.</p><a data-type="bookmark" href="https://stackoverflow.com/questions/63363123/swagger-ui-bundle-js-too-large-for-aws-lambda-and-alb" target="_blank"><div class="content"><div><div class="title">swagger-ui-bundle.js too large for AWS Lambda and ALB</div><div class="description">Updated to .NET Core 3.1 and the latest version of Swashbuckle but found the swagger UI wasn't working correctly.  The swagger-ui-bundle.js was failing to load with a 502.  Tracked this down to a A...</div></div><div class="href">https://stackoverflow.com/questions/63363123/swagger-ui-bundle-js-too-large-for-aws-lambda-and-alb</div></div><img src="https://cdn.sstatic.net/Sites/stackoverflow/Img/apple-touch-icon@2.png?v=73d79a89bded"></a><p>따로 CDN에 swagger js나 css를 올려놓고, 서버리스에 올리는 대신 받아오는 방식으로 사용해볼 수 있겠다는 생각인데.</p><p></p><pre spellcheck="false"><code class="language-typescript">const CSS_URL = "cdnjs.cloudflare.com/ajax/libs/swagger-ui/4.1.0/swagger-ui.min.css";
swaggerUI.setup(specs, { customCssUrl: CSS_URL })</code></pre><p>이런 방식으로 사용해볼 수 있다는 듯 하다.</p><a data-type="bookmark" href="https://github.com/swagger-api/swagger-ui/issues/8461#issuecomment-1497927943" target="_blank"><div class="content"><div><div class="title">When deploying swagger on vercel on nodejs it does not show UI · Issue #8461 · swagger-api/swagger-ui</div><div class="description">This is How it does look like this and I do not know how to fix this issue. Q&amp;A (please complete the following information) OS: M1 Pro Browser" Chrome, Safari Version: 22 Method of installation: np...</div></div><div class="href">https://github.com/swagger-api/swagger-ui/issues/8461#issuecomment-1497927943</div></div><img src="https://opengraph.githubassets.com/3d796af99bd52776acde541aa8b0f43379af9c671dc58fe420ea1314dd1a51a4/swagger-api/swagger-ui/issues/8461"></a><p></p><h1>TMI</h1><p>실제로 until을 처음 개발할 당시에 서버비를 줄이기 위해 다음 방법으로 한동안 개발했었다..</p><p>지금은 AWS + Kotlin Spring으로 넘어갔지만, 그래도 당시에 고려했던 점들을 몇 가지 적어본다.</p><p></p><ol><li><p>NestJS의 경우 서버 실행 초기에 bootstrap하는 과정을 거치는데, 이걸 api가 들어올 때마다 해야한다면 꽤 무거운 작업일 수밖에?</p><p></p></li><li><p>서버리스로 구성할 경우 api가 들어올 때마다 함수가 실행되는 꼴이므로, 트래픽이 몰리는 경우 DB의 커넥션 풀을 굉장히 잡아먹을 가능성이 높다. 이는 서버리스의 고질적 문제이긴 하다.</p><ul><li><p>프로젝트의 persistence 라이브러리로 채택한 Prisma의 경우 이런 문제를 해결해준다고 공식 사이트에 적혀는 있다. 하지만 좀 걱정된다</p><img src="https://image.until.blog/octoping/article/1730788287259.png" data-width="100%" data-align="center" alt="1976"></li></ul></li></ol><p><br></p><p></p>

NestJS를 서버리스로 배포해서 무료로 사용해봅시다

NestJS 서버를 서버리스로 Vercel에 배포하기

<h1>쿼리에서 로직 빼기</h1><p></p><div data-youtube-video=""><iframe width="640" height="480" allowfullscreen="true" autoplay="false" disablekbcontrols="false" enableiframeapi="false" endtime="0" ivloadpolicy="0" loop="false" modestbranding="false" origin="" playlist="" src="https://www.youtube.com/embed/fnH_SR3n9Ew" start="0"></iframe></div><p>내가 좋아하는 최범균님의 영상 중에서, 처음 보고 제일 충격을 받았던 영상이다.</p><p>영상을 다 보면 물론 좋겠지만, 시간 단축을 위해 핵심만 짚어본다.</p><p>ㅤ</p><h2>쿼리에 로직이 들어간 코드</h2><pre spellcheck="false"><code class="language-java">// update member m set m.status = 20 where m.id = ? and status = 10
int cnt = dao.회원탈퇴(id);

if (cnt == 0) {
    // 해당 id에 해당하는 회원이 없음.
    // 변경 건이 없으므로 변경 실패 처리
} else {
    // 변경 성공했으므로 로직
}</code></pre><p>다음은 mybatis로 짜여진 전형적인 코드다.</p><p>Mybatis로 UPDATE나 DELETE 쿼리를 실행하면, 그 결과로 변경된 행의 개수를 int로 반환해준다.</p><p>그걸 이용해서, cnt가 0이면 해당 멤버가 없었다는 것 (혹은 이미 탈퇴 상태라 탈퇴시킬 회원이 없었던 것)이므로 로직 실패 코드를 짜둔 것이다.</p><p>ㅤ</p><p>이렇게 코드를 짜면 SELECT로 멤버를 얻어오고 UPDATE로 값을 변경시키는 2번의 쿼리를 한번으로 줄일 수 있으므로 얼핏 보면 그냥 좋은 코드인 것처럼 보인다.</p><p>하지만 이렇게 로직이 쿼리에 들어가면 (현재 코드는 회원탈퇴를 이미한 유저는 탈퇴할 수 없다는 로직이 쿼리에 있다) 다음과 같은 문제가 생긴다.</p><ul><li><p>주요 로직이 흩어짐</p><ul><li><p>어플리케이션 코드, 쿼리로 분산 -&gt; 코드 분석 어려워짐</p></li></ul></li><li><p>유사한 쿼리를 중복해서 만들게 됨</p><ul><li><p>미세하게 다른 조건으로 다른 변경 처리</p></li></ul></li><li><p>주요 로직을 단위 테스트하기 어려움</p><ul><li><p>쿼리를 실행해야 로직 검증 가능</p></li></ul></li></ul><p>ㅤ</p><h2>이렇게 고치자</h2><pre spellcheck="false"><code class="language-java">Member member = dao.findById(id);

if (member == null) // 실패처리
if (!member.isActive()) // 실패처리

member.탈퇴();
dao.update(member);

/////
class Member {
    public boolean isActive() {
        return this.status == 10;
    }

    public void 탈퇴() {
        this.status = 20;
    }
}</code></pre><p>이렇게 하면 회원 탈퇴에 대한 로직이 어플리케이션 단으로 옮겨지므로 아까의 단점이 해소된다.</p><p><strong>코드의 가독성도 올라가고, 상태 변경 기능과 관련된 쿼리가 단순해진다.</strong></p><p>그러니 쿼리에서 로직을 빼라는 것이다.</p><p>ㅤ</p><h1>그래서, 이걸로 모든 것이 해결됐나요?</h1><img src="https://image.until.blog/octoping/article/1731326346775.png" data-width="50%" data-align="center" alt="2075"><p>명령(Command)에 대한 로직은 쿼리에서 빼내서 어플리케이션 단으로 옮기라는 것. 완벽히 이해했어!</p><p>그렇다면 조회(Query)는 어떨까?</p><p>ㅤ</p><h2>조회에는 로직이 없는가?</h2><p>조회에도 당연히 로직이 있다. 언틸의 예제를 가져와보자.</p><p>언틸에는 그룹 블로그가 있다. 토스, 배민 같은 팀 블로그를 모든 유저가 손쉽고 자유롭게 만들 수 있고, 같이 블로그를 꾸미고 싶은 유저를 초대할 수도 있다. (많이 써주세요)</p><p>아무튼.. 그리고 언틸에는 비공개 글을 작성할 수 있는 로직이 있는데.</p><p>ㅤ</p><h3>언틸 글 공개 로직을 공개합니다</h3><p>그룹 블로그에서 글을 조회하는 로직이 어떻게 될까?</p><ol><li><p>삭제된 그룹의 글은 조회할 수 없다</p></li><li><p>삭제된 글은 아무도 볼 수 없다.</p></li><li><p>그룹의 공개 글은 누구나 볼 수 있다.</p></li><li><p>그룹의 멤버는 비공개 글을 볼 수 있다.</p></li><li><p>그룹에 속해있지 않은 유저는 비공개 글을 볼 수 없다.</p></li><li><p>미로그인 유저도 비공개 글을 볼 수 없다.</p></li><li><p>해당 비공개 글을 작성한 작성자는 탈퇴했더라도 글을 볼 수 있다.</p></li></ol><p>ㅤ</p><p>이러한 로직이 있는데.</p><p>그렇다면 그룹 블로그에 접속했을 경우 글 목록이 보여야하는데, 이것은 코드로 어떻게 짤 수 있을까?</p><p>ㅤ</p><h1>조회 쿼리에서 로직 빼기..?</h1><h2>findAll() 후 필터링하기</h2><p>물론 조회 쿼리에서 로직을 빼는 가장 간단한 방법이 있다.</p><p><code spellcheck="false">findAll()</code>로 모든 데이터를 불러온 후, 어플리케이션 단에서 필터링하는 것이다.</p><pre spellcheck="false"><code class="language-java">public List&lt;Article&gt; getGroupBlogArticles(Long requestUserId, Long groupId) {
    List&lt;Article&gt; articles = articleRepository.findAll();
    Group group = groupRepository.findById(groupId);

    return articles.stream()
        .filter(it -&gt; group.isActive())
        .filter(it -&gt; it.isWrittenIn(group)) 
        .filter(it -&gt; it.isNotDeleted())
        .filter(it -&gt; {
            if (it.isAuthor(requestUserId)) return true;
            if (isMember(group, requestUserId)) return true;

            return false;
        })
        .toList()
        .pagination(start, size); // 이런 메소드는 없지만 있다고 하자
}</code></pre><p>하지만.. 이런 짓을 하기에는 우리의 서버의 컴퓨팅 용량은 충분치 않다.</p><p>전체 게시글이 몇 개인데 이런 짓을 했다간 말아먹기 딱이다.</p><p>ㅤ</p><h2>페이지네이션도 해야해</h2><pre spellcheck="false"><code class="language-java">public List&lt;Article&gt; getGroupBlogArticles(Long requestUserId, Long groupId) {
    List&lt;Article&gt; articles = articleRepository.findAllWithPage(start, size);
    Group group = groupRepository.findById(groupId);

    return articles.stream()
        .filter(it -&gt; group.isActive())
        .filter(it -&gt; it.isWrittenIn(group))
        .filter(it -&gt; it.isNotDeleted())
        .filter(it -&gt; {
            if (it.isAuthor(requestUserId)) return true;
            if (isMember(group, requestUserId)) return true;

            return false;
        })
        .toList();
}</code></pre><p>전체 데이터를 다 불러와서 어플리케이션 코드로 데이터를 조작하는 건 글렀다.</p><p>어차피 페이지네이션해야하는데, 해당 페이지의 데이터만 먼저 불러오고 어플리케이션에서 필터링할 수는 없을까?</p><p>ㅤ</p><p>당연히 안되죠? 1페이지의 글 30개를 불러왔는데 그 후 로직으로 필터링을 해서 전부 필터링 되어버린다면..</p><p>페이지를 조회했는데 아무 것도 안 나오는 기현상을 마주할 수 있을 것이다.</p><p>ㅤ</p><h1>절충할 수 밖에 없다</h1><p>결국 조회 메소드에선 애초에 DB에서 얻어오는 결과가, 로직이 전부 처리된 데이터여야 한다.</p><p>그렇다고 모든 것을 놓고 쌩 쿼리로 돌아가자는 말은 아니다. 절충할 줄 알아야 한다. 그렇다고 로직을 처리해서 DB에서 값을 얻어올 수 있는, 프로시저를 쓰자는 것도 아니다.</p><p>어떻게 어플리케이션 코드로 최대한 로직을 나타낼 수 있을까?</p><p>ㅤ</p><h2>쿼리에서 로직 조금 빼기</h2><p>일단 아까의 로직을 그냥 쌩 SQL로 나타내보자.</p><pre spellcheck="false"><code class="language-sql">SELECT a.*
 FROM article a
 JOIN profile group ON a.blog_id = group.id
WHERE a.blog_id = :groupId
  AND a.status = 'PUBLISHED'
  AND group.is_deleted = false
  AND (
    # 그룹의 공개 글은 누구나 볼 수 있다.
    a.is_public or

    # 미로그인 유저는 비공개 글을 볼 수 없다
    :userId IS NOT NULL or

    # 해당 글을 작성한 작성자는 탈퇴했더라도 글을 볼 수 있다.
    a.author_id = :userId or 

    # 그룹의 멤버는 비공개 글을 볼 수 있다.
    :userId IN (
      SELECT member_id
        FROM group_member
       WHERE group_id = :groupId
    )
  )</code></pre><p>뭐 서브쿼리도 들어가고 복잡하다.. ㅋㅋ</p><p>회사의 비즈니스 로직급의 요구사항이 될 경우 더더욱 쿼리는 번잡해질 것이다.</p><p>조회에 필요한 몇 몇 부분은 쿼리를 구성하는 데에 필수적이겠지만, 그 중 필수적이지 않은 것들은 최대한 어플리케이션으로 일임하고 쿼리를 단순화하자.</p><p>ㅤ</p><h3>삭제된 그룹의 글은 조회할 수 없다</h3><p>삭제된 그룹의 글을 조회할 수는 없다는 것은 이 쿼리를 구성하는 데에 필수적이지 않은 것 같다.</p><p>미리 그룹을 조회하고, 삭제된 그룹이라면 에러를 미리 던지자.</p><p>그러면 WHERE문도 하나 빠지고, 그룹의 정보를 얻기 위해 JOIN할 필요도 없을 것 같다.</p><pre spellcheck="false"><code class="language-java">public List&lt;Article&gt; getGroupBlogArticles(Long requestUserId, Long groupId) {
    Group group = groupRepository.findById(groupId);

    if (!group.isActive()) {
        throw new IllegalStateException("존재하지 않는 그룹입니다.");
    }

    return articleRepository.findFromGroupBlog(group, requestUserId);
}</code></pre><pre spellcheck="false"><code class="language-sql">SELECT a.*
 FROM article a
WHERE a.blog_id = :groupId
  AND a.status = 'PUBLISHED'
  AND (
    # 그룹의 공개 글은 누구나 볼 수 있다.
    a.is_public or

    # 미로그인 유저는 비공개 글을 볼 수 없다
    :userId IS NOT NULL or

    # 해당 글을 작성한 작성자는 탈퇴했더라도 글을 볼 수 있다.
    a.author_id = :userId or 

    # 그룹의 멤버는 비공개 글을 볼 수 있다.
    :userId IN (
      SELECT member_id
        FROM group_member
       WHERE group_id = :groupId
    )
  )</code></pre><p>ㅤ</p><h3>그룹의 멤버는 비공개 글을 볼 수 있다.</h3><p>그룹의 멤버는 비공개 글을 볼 수 있다는 것은 쿼리에서 빠지기 힘들어보인다.</p><p>그래도 해당 유저가 미로그인인지, 그룹의 멤버인지 체크하는 것은 어플리케이션에서 할 수 있을 것 같다.</p><pre spellcheck="false"><code class="language-java">public List&lt;Article&gt; getGroupBlogArticles(Long requestUserId, Long groupId) {
    Group group = groupRepository.findById(groupId);

    if (!group.isActive()) {
        throw new IllegalStateException("존재하지 않는 그룹입니다.");
    }

    boolean isMember = isMember(group, requestUserId);

    return articleRepository.findFromGroupBlog(group, isMember);
}

private boolean isMember(Group group, Long userId) {
    if (userId == null) {
        return false;
    }

    return groupMemberRepository.existsByGroupAndUserId(group, userId);
}</code></pre><pre spellcheck="false"><code class="language-sql">SELECT a.*
 FROM article a
WHERE a.blog_id = :groupId
  AND a.status = 'PUBLISHED'
  AND (
    # 그룹의 공개 글은 누구나 볼 수 있다.
    a.is_public or

    # 해당 글을 작성한 작성자는 탈퇴했더라도 글을 볼 수 있다.
    a.author_id = :userId or

    # 그룹의 멤버는 비공개 글을 볼 수 있다.
    :isMember
  )</code></pre><p>ㅤ</p><h3>최종 결과</h3><pre spellcheck="false"><code class="language-sql"># Before
SELECT a.*
 FROM article a
 JOIN profile group ON a.blog_id = group.id
WHERE a.blog_id = :groupId
  AND a.status = 'PUBLISHED'
  AND group.is_deleted = false
  AND (
    a.is_public or

    :userId IS NOT NULL or

    a.author_id = :userId or

    :userId IN (
      SELECT member_id
        FROM group_member
       WHERE group_id = :groupId
    )
  )



# After
SELECT a.*
 FROM article a
WHERE a.blog_id = :groupId
  AND a.status = 'PUBLISHED'
  AND (
    a.is_public or
    a.author_id = :userId or
    :isMember
  )</code></pre><p>ㅤ</p><h2>정리</h2><p>물론 쿼리에 로직을 전부 빼진 못했다.</p><p>하지만 좀 더 코드에 가독성이 생겼고, 비즈니스 로직을 수정할 때에도 훨씬 쉬워졌다.</p><p>ㅤ</p><p>조회에 로직을 모두 어플리케이션으로 뺄 수 없다는 단점을 보완하기 위해 QueryDSL과 같은 쿼리 빌더가 존재한다.</p><p>하지만 이것 또한 결국 도메인 레이어가 아니라 영속성 레이어에 비즈니스 로직이 들어간 것이라고 생각한다.</p><p>ㅤ</p><p>따라서 최대한 쿼리 쪽으로 들어가는 로직을 줄이고 이를 파라미터화 해서 외부에서 주입해줄 수 있는 쪽을 선택해보자.</p>

풍부한 비즈니스 레이어를 향하여

연락처