개발/Server
웹뷰로 시작되는 nestJS로 똑똑하게 서류 스크래핑하기
senyalog
2024. 10. 16. 22:20
AS IS
Service Webview < -- > Scraping Webview
메시지를 통해 요청을 통해 주고 받는 구조
문제점 : 어떤 메시지를 주고 받을지 사전에 커뮤니케이션이 필요(커뮤니케이션 비용 증가) + 메시지가 화면에 종속되어 있어 테스트가 어려움 + 디버깅과 테스트가 어려움
요구사항 : 병렬처리 가능 + 이슈 발생 시 디버깅 용이 + 서비스의 시작과 끝이 명확해지도록 + 모두의 생산성이 올라가는 방향
Message vs API
- 메시지 스펙 정의를 위한 사전 협의 필요 vs 표준화된 스펙으로 통신 때문에 협의 불필요
- 서비스 개발에 필요한 비용이 큼 vs 서비스 개발에 필요한 비용이 적음
- 유지 보수가 난해하고 어려움 vs 서비스 유지 보수가 상대적으로 쉬움
**나의 생각 : 결국 메시지를 도입하는 것은 비동기적 처리와 요청의 누락이 발생하지 않기 위함이라 생각. 또한 API도 spec에 대한 협의가 전혀 필요 없는 것은 아님.
왜 nestJS를 사용하는가?
- 미들웨어, 가드, 인터셉터 등 다양한 기능을 제공
- 복잡도 해결하기 위한 의존성 주입 기능 제공
- 컴포넌트 개념 개발 지향(모듈, 프로바이더, 컨트롤러, 서비스)
Http library
- node.js에서 http 통신을 하기위한 no level library -> 직접 핸들링하기 까다로움
Express, Koa, Fastify (Http framework)
- 웹 프레임워크
- 요청 처리를 위한 훅, 미들웨어, 설정을 담당하여 위의 까다로움 해결
NestJS?
- 의존성 주입, 인터셉터, ...를 통해 고수준의 서버를 구성할 수 있게함
결과적으로 어떻게 webview간 통신을 구현하였는가?
- Adaptor를 바꾸는 방법으로 webview간 통신을 구현
- Http adaptor를 새로 만들면, 직접 라우팅 핸들링 + 에러/예외 처리가 필요. 때문에 express/fastify의 역할을 다시 만들어야함.(에러 발생률 올라감)
- 때문에 fastify를 최대한 사용하는 방향으로 개발함 (소켓 통신 -> 웹뷰간의 통신으로 바꿈)
- webview에서는 webview 바깥 또는 앱의 함수를 직접 호출하는 것이 불가능. 이를 해결하기 위하여 App Bridge가 필요.
- App bridge와 script를 통해 앱 <--> 웹뷰 로 데이터 전송/받음
약식 Http?! (자체 인터페이스)
- webview간 통신에는 http처럼 보이는 통신을 하게됨.
- Http의 메소드/헤더/바디를 최소한으로 정의함
- 기관과의 통신은 https로 진행되지만 front와 webview의 통신은 약식 Http로 통신함
동시성 제어?
- 보통은 redis를 사용하여 동시성 제어를 함
- nestJs를 webview에 띄우게되면?
- in-memory storage 사용하여 동시성 제어
- 순차처리: 다른 작업은 대기
- 병렬처리: 새로운 작업은 병렬로 진행
- @Sequential()와 같은 데코레이터로 해결 가능
#새로운 개념
- 번들링, 폴리필
- 브라우저와 node.js 런타임은 상당히 다름(async context 미지원, 소켓 통신,...) 때문에 브라우저에서도 동일하게 동작하게 최대한 polyfill을 끼워넣는 방식으로 개발 진행
참고문헌