13P by disjukr 2022-06-15 | favorite | 댓글 1개

뤼이드에서는 모바일 앱을 주력으로 하는 다른 많은 스타트업들이 그렇듯이, 각 모바일 플랫폼에 공통적으로 제공되는 화면을 웹으로 개발해서 웹뷰 형태로 탑재하는 방식을 사용합니다.

별개로 빠른 웹뷰 개발 이터레이션을 위해서, 웹뷰 대신 iframe을 사용해서 모바일 네이티브를 흉내내는 방식으로 가상 모바일 웹페이지를 만들어서 웹 화면 개발에 사용하고 있기도 하고요.

웹페이지로 만들어진 화면은 네이티브 보다 라이프타임도 짧고 제한된 api 권한을 가지고 있기 때문에 필연적으로 웹뷰를 탑재한 껍데기(네이티브, parent window)와 통신하는 코드를 작성할 필요가 생깁니다.

그런데 각 껍데기 쪽에서 웹뷰와 통신하는 인터페이스가 불편한 제약(양방향 통신이 안된다던가 임의의 js 코드조각을 실행하는 방식만 지원한다던가)을 갖고있는데다가, 각 껍데기마다 인터페이스가 크게 다르기 때문에 통신 코드 작성이 피곤한 문제가 발생합니다.

저희는 원래 웹/모바일 클라이언트가 api 서버와 통신할 때 protobuf와 grpc 기술을 사용하고 있는데요, protobuf는 서비스 인터페이스를 기술하는데 사용하는 스키마 언어이고, grpc는 protobuf로 정의된 추상적인 요청을 실제 http 요청으로 만들어주는 프로토콜 레이어입니다.

이미 백엔드와의 통신에 protobuf를 사용하고 있어서 엔지니어들이 익숙하기 때문에, 워크플로를 통일하기 위해서 기존 웹뷰 통신 방식의 문제를 해결하는 데에 protobuf를 사용하기로 오래전에 결정했습니다.

이후 다년간 여러 모바일 앱을 개발하면서 이미 껍데기 <-> 웹뷰 통신에 protobuf 코드젠 개발방식을 사용해왔고, 최근에 새로운 앱을 만들면서 이 기술을 개선 및 오픈소스화 하기로 결정했습니다.
wrp는 이런 배경속에서 탄생한, grpc와 비슷한 역할을 하지만 웹뷰 전용인 프로토콜 레이어입니다.

wrp는 typescript & react / kotlin & compose / swift & tca 지원, 스트림, 양방향 통신, 웹페이지가 다시 로드되는 경우에 통신 맥락을 복원하는 기능 등을 지원하고, 사용자의 네이티브 앱 버전업이 느려서 웹뷰와 프로토콜 불일치가 일어나는 상황에 대한 대응이 어느정도 되어있습니다.

이제 막 wrp의 주요 기능들이 개발된 상태이기 때문에 안정적이지는 않지만 이 기술에 관심이 있으신 분들은 저희 디스코드 서버에 들어오셔서 같이 이야기 나눌 수 있으면 좋겠습니다.


Pbkit 디스코드 서버: https://discord.gg/PHmV3nhvQq

Web - TypeScript & React

iOS - Swift & TCA

Android - Kotlin & Compose


(트위터에 작성한 내용을 약간 고쳐서 옮겨적었습니다)
https://twitter.com/disjukr/status/1537034296959315968