GitHubエンジニアのGregor Martynus氏が、もともと合計6ファイルで約16,000行のGitHub公式REST JavaScript SDKをリファクタリングして、よりメンテナンスしやすくモジュール化したプロジェクトにするまでの道のりについて説明した。
Martynus氏は次のように説明する。
ライブラリのコア部分は、8,000行近くある巨大なroutes.jsonファイルで、これは全てのGitHubのREST APIエンドポイント全てを定義するものでした。
routes.jsonファイルは手動で管理されており、足りないエンドポイントを追加したり、既存の定義を修正したりする作業は特に大変だった。Martynus氏が最初に行ったのは、GitHubのREST APIドキュメントをスクレイピングして、APIのJSON表現を生成するスクリプトを書くことだった。生成されたルートが変更されると、スクリプトは変更のプルリクエストを送信し、完全なTypeScript定義を含む新しいリリースが自動的にリリースされる。このアプローチは、多大な労力をかけることなく、GitHub RESTエンドポイントがJavaScript SDKにおいて常に最新で完全な状態であることを保証する。
次に、Martynus氏はモジュール化に取り組み始めた。実際に必要な機能だけをロード可能にすることで、ブラウザベースやその他軽量のクライアントにメリットをもたらすものだ。
全てのREST APIエンドポイント、認証方式、推奨されるベストプラクティス（ページネーションなど）を実装した単一のモノリシックなライブラリではなく、よりローレベルなライブラリを使う選択肢をユーザーに与えることが重要です。そうすれば、ユーザーはバンドルサイズと機能とのトレードオフについて、自分で選択することができます。
この取り組みで、よりAPIサーフェースに近くて少ないレイヤーを持つ次のアーキテクチャが導かれた。
Martynus氏はこのリアーキテクチャを、非推奨のコードを取り除くチャンスだと捉えて、他の全てのOctoKitモジュールの基盤を提供する新しいcoreパッケージを使ってやり直した。hookは重要な役割を果たしており、認証方式やページネーションなど独立した機能を個別のプラグインに分割するのを可能にする。さらに、TypeScriptを使用することで、コンパイル時にチェックが行われるため、ほとんどの検証コードを取り除くことができた。
Martynus氏の記事のタイトルからは、50,000行近くのコードを10行に減らせたように思うかもしれないが、実際はそうではない。実際には、JavaScript SDKにもともとあったコードのほとんどは消えておらず、別のモジュールに移された。とはいえ、SDKをよりメンテナンスしやすくモジュール化するという目標を達成できなかったわけではない。実際には、その逆だ。詳細に興味があれば、彼のオリジナルの投稿を読んでほしい。