Node Summit 2016 年 4 月、ニューヨークを拠点とするデジタル制作スタジオ Postlight の共同設立者であるポール・フォード氏は、Twitter で同社の Web アプリはひどいと語った。
「自分がゴミだということを決して忘れないように、モバイル版SafariのTwitterウェブクライアントを使っている」と彼はツイートした。
2015年に開始されたTwitterモバイルウェブアプリの書き換え作業に取り組んでいたTwitterのエンジニアたちは、他のユーザーも同様の懸念を抱いていることを認識していました。Twitterのシニアソフトウェアエンジニア、ジェームズ・ベレンジャー氏が水曜日にサンフランシスコで開催されたNode Summitで語ったように、この混乱を収拾する任務を負ったチームは、自分たちに向けられた意地悪なツイートからステッカーを作成し、改修作業へのモチベーションを高めました。
Twitterは4月に、モバイルウェブアプリをプログレッシブウェブアプリとして完全に書き換えたTwitter Liteをリリースしました。2年間の開発期間を経て完成したこのサービスは、ソーシャルプロパガンダ企業である同社にとって、Node.jsで構築された初の大規模ユーザー向けサービスとなりました。
モバイル Web 向けの Twitter の以前のバージョンでは、バックエンドでは Java 仮想マシン (JVM) で実行され、フロントエンドでは JavaScript で実行されるプログラミング言語である Scala を使用していました。
「このスタックは、JVM が効率的にデータを取得できるため、多くの点で非常に優れています」と Bellenger 氏は語ります。
しかし、ベレンジャー氏は続けて、サーバーがすべてのデータ取得とビューのレンダリングを処理するといった欠点もあると述べた。バックエンドへの依存関係が多く、コンパイルが遅く、メンテナンスが難しく、継続的なエンジニアリングの対応が必要になると説明した。
「採用面では、フロントエンドとバックエンド両方の開発スキルを持つ人材を見つけるのは本当に大変でした」とベレンジャー氏は語る。「しかも、Scalaを知らない人も多いんです。」
Twitterは、高速で効率的、そしてオフラインでも動作するウェブアプリを求めていました。「新しいスタックで社内のエンジニアの能力を最大限に引き出したいと考えていました」とベレンジャー氏は語ります。
すべてはここから始まったステッカー…クリックして拡大
Node.jsは、ほとんどのユーザーインタラクションにおけるクリティカルパスからサーバーを排除し、重心をサーバーからブラウザへと移行させる手段を提供しました。しかし、技術的な変革を実現するには、Twitterのエンジニアはまず組織的な変革を行う必要がありました。なぜなら、Twitterの全員がWebテクノロジーに信頼を置いていたわけではないからです。
ベレンジャー氏は、人々を啓蒙するキャンペーンは最も重要で、最も困難であり、そして成功する確実性が最も低いと述べた。
Twitterのソフトウェアセキュリティへの取り組み方に違いがありました。ScalaベースのWebサービスでは、変更やパッチ適用に対応するために約100個の外部ライブラリが必要で、それぞれがセキュリティチームによってレビューされ、担当者がいました。Node.jsベースのTwitter Liteには、約2,000個の依存関係があります。
「それは私たちが監査したり理解したりできる範囲を超えています」とベレンジャー氏は語った。
そこでTwitterはNode.jsのコードを信頼しないことを決定しました。アプリのサービスレイヤーはTwitterの公開REST APIを使用し、サンドボックス内で動作します。また、統合テストにも重点を置きました。オープンソースのエラー報告システムSentry.ioは「信頼を築く上で非常に貴重な存在でした」とベレンジャー氏は述べています。
Twitter Lite チームは、開発者に Node の知識を習得してもらうために、毎週グループでランチをしながら Node 関連のテクノロジーに関するチュートリアルを見る「Watch Wednesdays」を始めました。
チームは、アプリに大量のデータを大量に送信していたAPIも見直す必要がありました。Node.jsは多数の小さなトランザクションを処理する方がパフォーマンスが向上するため、Twitter Lite開発者はアプリの400KBの解析ペイロードを削減することに注力し、データを40KBまで削減することに成功しました。
ベレンジャー氏によると、この変更によりCPU使用率は半減し、同じハードウェアで処理できるリクエスト数は倍増しました。また、Node.jsがコンピューティングリソース（CPUとメモリ）に与える影響はさらに顕著で、Twitter Liteでは、JVMスタック上で実行されていたバージョンと比較して、10億レンダリングあたりのコンピューティングコストがわずか3.5%しか削減されませんでした。®
