Electron은 데스크트탑용 웹앱을 만드는데 사용된 일종의 런타임입니다. Chromium엔진 기반으로 되어 있고. node.js API를 제공해서 쉽게   HTML, JS, CSS로 데스크탑앱을 만들 수 있습니다. 문제는  Hello World 앱을 만들어도 무거운  Chromium엔진을 실행해야 하는데, 다른  Electron앱 런타임 공유도 안됩니다. 기대가 두개의 서로 다른  V8엔진을 실행해야했습니다.

결국,  Microsft가 칼을 들었군요. Edge WevView2를 만들어서  Electron을 대치하기 시작했습니다. 첫번째로 Microsoft Teams가  Edge WebView2를 사용하기로 결정했고, 이미 새 버전은 WebView2로 릴리스가 되었을 겁니다. 흥미로운 것은  ReactJS와  Apollo GraphQL를 사용한 부분이네요. 이를 통해 100%성능을 높였고, 저정 공간도 많이 아꼈다고 합니다.

With this change, we are taking a major step in #MicrosoftTeams Teams architecture. We are moving away from Electron to Edge Webview2. Teams will continue to remain a hybrid app but now it will be powered by #MicrosoftEdge. Also Angular is gone. We are now 100% on reactjs

— Rish Tandon (@TandonRish) June 24, 2021

https://twitter.com/TandonRish/status/1408085784016539653

단, 아직은 Edge WebView2는 공식적으로 리눅스와 맥은 지원하지 않습니다. 하지만 내부적으로는 사용하고 있는 것 같습니다. 그래서 아직 Electron을 버릴 때는 아닌 것 같고, 좀 더 두고보면 Electron이 완전히  deprecated 되지 않을까 예상해봅니다.

참고
* https://dev.to/noseratio/some-thoughts-on-the-new-microsoft-teams-2-0-architecture-webview2-reactjs-1gf1

* https://techcommunity.microsoft.com/t5/microsoft-teams-blog/microsoft-teams-advantages-of-the-new-architecture/ba-p/3775704

WebView는 웹 브라우저 기능을 앱 내에서 재사용할 수 있도록 컴포넌트화한 것으로, 대부분의 운영체제에서 지원되어 앱에 웹페이지 렌더링 기능을 쉽게 추가할 수 있습니다. 마이크로소프트는 IE와 Edge 엔진을 포기하고 크로미엄 엔진으로 전환했으며, 이에 따라 기존의 IE 컨트롤이 Edge WebView2로 교체되었습니다.

https://github.com/MicrosoftEdge/WebView2Browser

이를 통해 누구나 쉽게 웹 브라우저를 개발할 수 있으며, 관련 코드는 공개되어 있지 않지만 GitHub의 MicrosoftEdge/WebView2Browser 저장소에서 샘플 웹 브라우저 코드를 제공하고 있습니다. 현재는 Windows와 Xbox 플랫폼만 지원되지만, 향후 Android와 macOS에서도 지원될 것으로 기대합니다.

더 많은 정보는 마이크로소프트의 공식 웹사이트에서 확인할 수 있습니다.

https://learn.microsoft.com/en-us/microsoft-edge/webview2/

Puppeteer나 Playwright같은 headless 브라우징으로 웹페이지 scaping하는 경우가 많은데, 많은 웹사이트들이 headless브라우저를 감지하고 접근을 차단하고 있다. 이를 어떻게 회피하는지 알아보자.

우선 아래 페이지를 headless 브라우저로 접근하면 일반적인 웹브라우저와 headless브라우저가 어떻게 다른 결과가 나오는지 알 수 있다.

https://infosimples.github.io/detect-headless/

사실 이것말고도 더 많은 방법이 있지만, 이 정도가 알려져있다. 이런 것들을 쉽게 구현해주는 Puppeteer plug-in이 이미 만들어져있다.

https://www.npmjs.com/package/puppeteer-extra-plugin-stealth

reCAPCHA도 대응가능하다.

상용 Proxy 서버 사용

당연히 IP도 체크하므로 상용 Proxy 서버를 사용하는 것이 좋다. 상용 서비스는 Proxy 서버를 rotation해서 여러 IP를 사용하도록 해준다.

사실, 창과 방패의 싸움이라 clludflare같은 회사에서는 headless 브라우저를 잘 감지한다. 가장 확실한 방법은 상용  Proxy server와 함께 사용하는 것이다. 비용은 들지만, 가장 확실한 방법이기도 하다.

• https://piprogramming.org/articles/6-Ways-to-detect-a-headless-Browser-with-JavaScript--How-to-detect-a-Headless-Browser-0000000030.html
• https://bot.incolumitas.com/
• https://datadome.co/threat-research/detecting-selenium-chrome/

https://simonhearne.com/2021/layout-shifts-webfonts/

많은 웹사이트가 웹폰트를 쓰고 있다. 시스템 폰트 보다 본래 웹페이지 디자인에 맞는 폰트로 웹페이지를 출력하고 싶은 사람들이 많기 때문에 웹폰트 사용이 증가하고 있다. 그런데, 웹폰트는 다운로드 받아야하므로 크기가 큰 경우 웹페이지가 먼저 렌더링되는 경우가 있다. 이럴 때, 레이아웃이 출렁거리는 것을 느낄 수 있다. 웹폰트를 다 받으면 시스템 폰트로 그린 페이지를 다시 그리기 때문이다. 

위 사이트에서는 그러한 문제를 잘 설명했고, 어떻게 해결할 수 있는지 소개하고 있다..

In summary we need to prevent the layout shift by letting the browser render in a fallback system font if it doesn't get the web font in time, then optimise our fonts to try to get them to the browser before it needs them:

• use font-display: optional to prevent layout shifts
• subset fonts and serve as woff2
• use variable fonts or a limited set of weight variations
• preload critical fonts
• host your own fonts on your main domain

프로젝트가 반복되면 재사용되는 코드가 많아질 수 밖에 없다. 여러가지 툴을 타입스크립트를 작성하다 보니 그 동안 공통적으로 사용하고 있는 기능을 묶어서 프로젝트로 만들어서 github에 공개해봤다.

https://github.com/joone/typescript-template

물론,  MS가 만든 비슷한 프로젝트도 있는데, 너무 기능이 많고, 내가 원하는 수준에서 만들었는데, 아마도 필요한 분이 있을것 같다.

일단,  프로젝트는 clone하면 기본적으로 아래 package를  사용할 수 있고, 간단한 웹서비스가 구현되어 있다.

• express.js
• eslint
• mocha
• chai
• prettier
• typeorm
• mongodb
• Docker

MongoDB를 사용하는 방법이 두가지 있는데, typeorm와 mongoose를 사용한 것 코드를 별도 branch로 분리해두었다. typeorem이 쓰기 편해도 MongDB에는 mongoose가 코드는 복잡해도 더 쉬운 것 같다.

Start your web application:

$ npm start

Run test cases:

$ npm test
$ npm run-script lint

Docker image를 만들어 실행하는 부분도 추가했고, prettier도 지원한다.

Run prettier to fix styles:

$ npm run style

Build a Docker image and run the container:

$ sudo ./build_docker.sh
$ sudo docker ps
$ curl -v http://localhost:3001

향후 계획은 게시판 정도 실행되도록 하는 것이 목표다.

웹엔진으로 앱을 만드는 것은 쉬운 일이지만, 브라우저 엔진을 실행하는 만큼 그 용도가 정확하게 맞아야 큰 효과가 있다. 몇가지 솔루션이 있는데, 한번 짚고 넘어가보자.

Electron 

Electron은 Chromium기반의 애플리케이션 런타임이다. 웹기술로 여러 플랫폼을 지원하는 앱을 쉽게 만들 수 있다. 이런 개념은 오래전 부터 존재해왔지만,  Electron이 많은 인기를 끌게된 원인은 바로 Node.JS의 지원이다. 그냥 Node.JS 패키지로 npm으로 설치할 수 있고 JavaScript로 Chromium WebView를 생성하고 Application의 Life cycle을 관리할 수 있다.  또한 다양한 Node.JS 패키지로 강력한 앱을 빠르고 쉽게 만들 수 있는 장점이 있다. 물론 원조는 NW.JS라는 것이 있다.  Electron을 만든 사람도 NW.JS개발자였고 비슷한 부분이 많다. 

https://www.electronjs.org/docs/tutorial/quick-start

위 튜토리얼 보면 쉽게 샘플앱를 만들고 바로 패키징도 할 수 있다.

 NW.js

비교한 글을 보면 NW.js는  Electron과 달리 브라우저 엔진과 같은 context에서 Single Thread로 동작한다고 한다. NW.js의 경우 소스코드를 노출하지 않을 수 있다고 하는데, 이 경우 서버로 기능을 숨길 수 있기 때문에 커다란 장점은 아니라고 한다.

CEF(Chromium Embedded Framework)

CEF의 경우 말 그대로 라이브러리 형태로 하나의 컴포넌트로 WebView를 앱에서 실행하는 것이다. 예전에 IE Component를 사용하는 방식과 같다고 할 수 있다. 기본적으로 C++로 앱을 만들때 사용할 수 있으며 다양한 바인딩이 존재한다.

Chromium 자체가 WebKit처럼  embedding을 목적으로 만들어져 있지 않아서 기존 앱에 WebView를 붙이는 것이 쉽지 않다. 분명 소스코드가 많이 수정되었고 최신 코드를 업데이트하기도 쉽지 않을 것 같다.

https://bitbucket.org/chromiumembedded/cef/wiki/Tutorial

Qt WebEngine

https://doc.qt.io/qt-5/qtwebengine-features.html

Qt도 Chromium WebView를 구현했는데,  Qt로 앱을 만들 때 사용할 수 있다.  Tesla 자동차에서 사용하는 것으로 알고 있다.

 참고

• https://integu.net/electron-vs-nw-js-node-webkit-vs-cef-chromium-embedded-framework/