NGRX Store - An Architecture Guide (1)

안녕하세요. 꼬동입니다.

 

요새 PS5에 빠져서 게임만 하고 삽니다.

 

진짜 초초초초초초초초초초초초초초촟초초초촟초초초갓겜

 

그러다 PS5 놔두고 고향에 내려와서 디지털 노마드를 하고 있는데,

 

퇴근하면 할 게 없고, 글이나 번역해서 쓸까해서 좋은 글을 챙겨와봤습니다.

 

https://blog.angular-university.io/angular-ngrx-store-and-effects-crash-course/

Ngrx Store - An Architecture Guide

 

2022년에 쓴 따끈따근한 좋은 글이더군요.

 

사실 Store Architecture를 NGRX 사용하니까, 자연스레 사용했지. 어떤 이점이 있고, 어떤 문제를 해결할 수 있고, 정말 자세히 알지는 못하죠. (자세히 안다는건, 남에게 설명할 수 있느냐의 정도 ?)

 

그러니 그 기원과 속까지 뒤져보는 좋은 글이 될 수 있을거 같습니다.

 

angular uni의 글은 무조건이제 ~

---

이 글을 읽기 전에

Angular University에서 Angular Architecture 시리즈로 글을 꾸준히 써왔더랬죠. (몰랐넹...)

 

디자인 문제들과 그 해결법을 찾아보는 글들을 작성했었는데, 이번 글은 Angular Store Architecture 입니다.

 

Angular 혹은 그 외 일반적인 프레임워크에서 Centralized Store Solution을 사용한 애플리케이션의 장점이 무엇일까요 ?

 

해당 개념을 익히면서 여러분들은 아마 Actions, Reducers 및 Store Architecture와 관련된 용어를 접할 것입니다. (무조건)

 

이러한 것은 결국 목적을 위한 수단(개념 : concepts)입니다.

 

결국, Centralized Store Architecture는 애플리케이션 디자인으로서, 해당 디자인 의도를 인지하고, 어떤 문제를 어떻게 해결할 수 있는지를 아는 것이 중요합니다.

 

이 글을 읽기 전 위의 볼드처리된 한 문장을 3번 복창하고 갑시다.

 

(결국, Centralized Store Architecture는 애플리케이션 디자인으로서, 해당 디자인 의도를 인지하고, 어떤 문제를 어떻게 해결할 수 있는지를 아는 것이 중요합니다. 결국, Centralized Store Architecture는 애플리케이션 디자인으로서, 해당 디자인 의도를 인지하고, 어떤 문제를 어떻게 해결할 수 있는지를 아는 것이 중요합니다. 결국, Centralized Store Architecture는 애플리케이션 디자인으로서, 해당 디자인 의도를 인지하고, 어떤 문제를 어떻게 해결할 수 있는지를 아는 것이 중요합니다.)

---

Store Solution을 알아가는 가장 좋은 방법은 ?

Store Solution을 알아가기 전, Store Arhitectures의 기원을 돌아가보도록 합시다.

 

대표적인 한 사례인 Facebook의 Counter 문제를 알아보고, 무슨 문제인지와 어떻게 해결했는지를 알아봅시다.

---

Flux 구조로 시작된 Facebook Chat Bug

이제는 메타죠

Flux Architecture와 Store Solution을 알아가기 위해 한 예시를 들어봅시다.

 

---

https://ggodong.tistory.com/263

Flux 패턴

 

위의 제가 쓴 글을 읽으셔도 됩니다.

---

 

옛날 제가 대학교 1학년 때, 많은 사람들이 Facebook을 썼죠. (제가 군인일 때도.. 지금 쓰는 사람 있나 ?)

 

그 때 당시 Facebook에 큰 버그 하나가 있었습니다. 게다가 해당 버그는 유저들이 굉장히 쉽게 발견할 수 있는 버그였죠.

 

얘들은 QA 없나 모르겠군요.

 

어찌됐든, 이 버그는 버그라고 부르기 보단, Flux Architecture 도입 이전의 Architecture의 한계를 보여주는 사례입니다.

 

무슨 버그였나요 ?

문제는 읽지 않은 메시지 카운터가 제대로 동작하지 않아 문제가 됐습니다.

 

내가 보낸 메시지라 안 읽는거니 ..?

 

예를들어 사용자가 읽지 않은 메시지 하나를 읽으면, 모든 메시지가 이미 읽혀져있는 문제입니다.

 

이 버그는 간단한 버그였을까요 ?

 

그 때 당시 Facebook 개발자 분들은 모두 간단한 문제라고 생각했습니다.

 

근데 요게 하나 고치면, 다른게 고장나고, 저걸 고치면 그게 고장나고 ..

 

생각보다 간단한 문제가 아니었고, 점점 그들의 근무 시간은 늘어나게 되었습니다.

 

어떻게 해결했나요 ?

이 문제를 해결하기 위해서 Facebook 팀은 Application Architecture를 크게 변경해야 했습니다.

 

닭 잡는데 소 잡는 칼이 필요했던거죠.

 

화웅은 나가있어

 

그리고 새로운 디자인 강연에서 발표가 되었습니다.

 

https://youtu.be/nYkdrAPrdcw

 

10분 19초 Flux Architecture 소개가 시작되는데, Store Architecture를 찾아보고 있다면, 보면 굉장히 도움이 많이 될 겁니다.

 

결국 Facebook은 해당 Counter 문제를 해결하기 위해서 하나의 solution이 필요했습니다. 그 solution은 아래와 같습니다.

 

더 많은 Real Data를 Client-side로 가져오고, 파생 데이터를 줄이자. (파생 데이터 : 기존 데이터를 조합하여 만든 새로운 데이터)

 

사실 Facebook counter 문제는 SPA가 많이 겪은 문제입니다.

 

왜냐하면, User Interface를 지닌 대부분의 애플리케이션들은 근본적으로 아래와 같은 데이터 형식을 가지고 있기 때문입니다.

• Model, Domain Model
• View Model

예를 들어서, 아래와 같은 Chat 애플리케이션이 있다고 가정해봅시다.

 

두 명의 유저가 서로 다른 기기를 사용합니다

 

위를 보시면, 해당 애플리케이션에서 3가지 타입의 데이터가 있음을 알 수 있습니다.

• 메시지
• 스레드
• 참여자

TypeScript로 해당 프로그램을 짰다고 한다면, 아래와 같은 interface가 정의되겠죠.

 

export interface Thread {
	id: number;
    messageIds: number[];
    participants: {[key:number]: number};
}

export interface Message {
	id: number;
    threadId: number;
    participantId: number;
    text: string;
    timestamp: number;
}

export interface Participant {
	id: number;
    name: string;
}

Mssage와 Particpant는 종속되지 않은 Object(POJO : Plain Old Java Object)이며, Thread는 participant id를 key로 가지고, 읽지 않은 메시지의 수를 value로 가지고 있는, 다소 종속되어 있는 데이터 구조입니다.

 

물론, TS가 아닌 JS로 유형을 정의하지 않고 프로그램을 만든다고 해도, 이러한 유형의 추상적(개념적)으로 여전히 존재할 거라고 예상이 됩니다.

 

개념적으로 존재한다는 건, 개발자들 끼리 해당 프로그램에 대해서 기술적으로 대화하거나 / 프로젝트 문서를 작성할 때 개념이 언급된다는 뜻이죠. (개념적으로 얘기하는게 어렵기 때문에, TS를 쓰는게 상당히 좋겠죠 ^_^)

 

진짜 삼성에서 얘 없이 어떻게 개발했지 ?

위의 데이터 유형은 저희 애플리케이션 DB 데이터 정의에 밀접한 연관성을 가집니다.

 

만약, SQL DB를 사용한다면, 위의 내용이 그대로 DB TABLE로 정의 될 것입니다. NoSQL을 썼다더라도, 위 도메인 개념이 그대로 존재하겠죠.

 

개발하긴 편하겠죠. 도메인 개념과 저희 애플리케이션 개발 개념이 일치하니까요.

 

근데 문제는 위의 유형이 화면에 보이는 것과 직접적으로 일치하지 않아서 문제가 되는겁니다.

---

오늘은 여기까지 쓰겠습니다.

 

슬 잠오거든용

 

이상 NGRX Store - An Architecture Guide (1) 였습니다. ^_^