웹뷰로 시작되는 nestJS로 똑똑하게 서류 스크래핑하기

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을 끼워넣는 방식으로 개발 진행

 

참고문헌 

https://www.youtube.com/watch?v=JDeZNxIk5Ko