ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 모듈 간의 데이터 통신은 어떻게 하는게 좋을까
    OFF THE RECORD/생각 2024. 4. 17. 21:08

     

    갑작스럽게 react-native-webview를 기반으로 Nextjs 웹앱을 띄우는 프로젝트에 참여하면서 느낀 것이 많아 글로 남겨봅니다.

    RN과 Nextjs가 서로 데이터를 주고 받음에 있어서 어떻게 하면 더 관리하기 용이할까 하는 측면에서 글을 써보겠습니다.


     

    글은 다음과 같이 구성되어 있습니다.

    1. 통신 채널의 형태

    2. 두 모듈 간의 관계

    3. 절대 놓치면 안된다고 느낀 부분

     

     

     

    1. 통신 채널의 형태

    1-1. 기존 설계

    React-native 개발자로 근무하면서 앱이 메인이고 부수적인 작업들만 webview를 사용해서 처리했기 때문에, 크게 설계적인 측면은 고려하지 않고 작업해왔던 것 같습니다.  그러던 중 이번 프로젝트에서 양방향 메세지 큐를 생각나게 하는 설계가 되어있어서 흥미롭게 살펴보았습니다.

     

     

     

    간단하게 설명하면 동작은 아래와 같습니다.

    1. 메세지를 보내는 측에서 액션을 전달한다. (이벤트 발생)
    2. 메세지를 받는 측의 리스너에서 이벤트를 받는다.
    3. 이벤트 핸들러에서 액션에 맞는 핸들러 함수를 실행한다.

     

     

    그리고 이벤트 핸들러는 이런 느낌으로 진행이 됩니다. 특별하게 처리해야하는 대상을 먼저 걸러서 처리하고 그렇지 않은 것은 else 문에서 한번에 처리하는 형태입니다.

    if (special action1) {
     ... handle action1
    } 
    
    else if (special action5) {
     ... handle action5
    }
    
    else {
      ... handle common actions
    }

     

     

    가장 처음 코드를 봤을 때, 한 눈에 파악을 하지 못해서 액션을 선언하고 전달하는 것에서 애를 먹었습니다. 하지만 눈에 조금 익고 나니 몇 가지 아쉬움이 있지만 사용하기에 편리한 부분들도 느껴졌습니다.

     

     

    1-2. 만약 내가 만들어야한다면?

    아주 충~분한 시간과 내 마음대로 할 수 있는 권한이 주어진다면 어떻게 만들수 있을까를 고민해보았습니다.

    코드를 파악할 때, 이벤트를 처리하는 로직과 생성하는 로직이 섞여서 조금 고생했던 것을 감안한다면 양방향이 아닌 단방향 큐를 2개 두는 방법을 사용할 것 같습니다.

     

     

    기존 설계에서 이벤트 핸들러에서 이벤트를 받으면서 이벤트도 발생시키는 부분이 좀 헷갈린다고 느꼈기 때문에 위 처럼 받는 곳에서는 받기만하고 보내는 곳에서는 보내기만 하는 형태로 만들어주는게 더 작업이 수월할 것이라고 생각이 듭니다. 또 잘 만든다면 1개의 큐를 만들어서 방향만 바꿔서 사용할 수 있지 않을까 합니다.

     

    이런 식으로 잘 만들어보면 두 모듈은 서로의 존재와 메세징 시스템의 존재를 신경쓰지 않고 코드가 잘 돌 수 있지않을까 합니다.

    하지만 여전히 두 모듈이 서로의 액션을 알고 있어야하는 단점이 존재하는 것 같습니다.

     

     

     

     

    2. 두 모듈의 관계

    문제 해결을 위해 프로젝트 코드를 돌아다니던 중에 이 둘의 관계 설정은 이대로 괜찮은가 라는 생각이 들었습니다.

    위에서 봐오던 그림을 살펴보면 NextJs 와 RN은 동일 레벨에서 표현되고 있습니다. 둘의 관계는 이게 맞을까요

     

    작업을 이어나갈 수록 동등한 레벨이 아닌 응용프로그램과 OS의 관계처럼 생각하는 것은 어떤가라는 생각이 들었습니다.

    RN 을 프레임워크로 정도로 생각한다면 Nextjs에게 라이프 사이클과 같이 적절한 시점을 제공할 수 있을 것 같고, 운영체제와 같이 생각한다면 시스템 콜과 같이 적절한 기능들을 인터페이스로 제공하는 것도 생각해 볼 수 있겠습니다.

     

     

    이런 방향으로 생각이 흘러간 계기는 RN이 시작되고 Nextjs가 동작하기 이전에 해야되는 작업을 할 타이밍이 마련되어 있지 않았기 때문인데, 왼쪽과 같은 형태에 가깝게 설계가 되어있어서 그런 것이 아니었을까 하는 추측을 해봅니다.

     

     

     

    3. 절대 놓치면 안된다고 느낀 부분

    이번 프로젝트를 통해서 확실히 느낀 부분 입니다. 

    두 대상이 통신을 할 때는 통신이 맺어진 시점을 명확하게 알 수 있어야한다.

     

     

    두 프로젝트가 초기화를 하는 흐름을 도식화해보았습니다.

    RN의 초기화가 먼저 시작되고 이어서 Next와 RN이 같이 초기화를 진행합니다.

     

    이번에 작업하면서 가장 애를 먹었던 부분 중 하나는 두 대상의 초기화가 끝나는 시점이 명확하지 않았다는 점이었습니다.

    중간에 들어가서 정확한 히스토리도 모르고, 사용되지 않는 코드들도 남아있는 상태라 쉽지 않았습니다.

     

     

    TCP 연결시에 3 hand shake를 통해서 연결됬다! 하는 것 처럼 두 대상을 함께 사용해야한다면 이벤트 혹은 조건을 사용해서 빨간선으로 표시된 지점을 확실하게 확보해야된다고 생각합니다.

     

     

     

     

    감사합니다.

     

     

    'OFF THE RECORD > 생각' 카테고리의 다른 글

    명령형 프로그래밍과 선언형 프로그래밍  (1) 2023.12.26
Designed by Tistory.