gravatarが提供するプロフィール画像サイズは80px × 80px
- サービスによっては、小さすぎる
  - 画像サイズを拡大することができるが、画質がよくない
gravatarが提供するプロフィール項目が固定
- 画像だけではなく、プロフィール項目も一括登録したかった
  - サービスによっては、プロフィール項目がマッチしない

そこで、Contentful というAPIベースのCMSを使うことにしました。

www.contentful.com

Contentfulでは、自由に項目を決めることができます。独自に作った項目 (画像や紹介文)を、API経由で取得できるため、とても便利です。

どうやって作ったの？

愚直なやり方です。 Puppeteerと呼ばれる Chromeブラウザを自動操作できるライブラリを使いました。 Chromeブラウザから、"各サービスへログインし、写真をアップロードする"処理を自動化しただけです。

github.com

プロフィール画像を更新するAPIは、なかったの？

サービスによってはあります。例えば、Twitterには、次のようなプロフィール画像を更新するAPIがあります。

developer.twitter.com

ただ、全てのサービスには、そのようなAPIはありません。 APIを使って更新するのが正しい姿ですが、全サービスの実装方法の足並みを揃えるために、 Puppeteer で自動操作することにしました。

パスワードって大丈夫？

Puppeteerを動かすnodeアプリケーションと、Chromeブラウザを同一マシン内で動作するようにしました。そのため、nodeアプリケーション実行中に、パスワードを傍受されることはありません。また、パスワードの設定は環境変数から注入するようにしています。 Dockerコンテナで動作できるようにしているので、ローカルでも、コンテナサービスでも動かすことができます。

今後、パスワードの管理は、KeepassやLastpassのようなサービスと連携したいと思っています。

github.com

どのサービスが対応している？

対応サービスは次のとおりです。

Hatena
Qiita
Medium
Note
devTo
witter
Github
Google
Facebook
LinkedIn

詳しくは、 https://github.com/Silver-birder/puppeteer-account-manager/blob/master/src/index.ts をご確認下さい。

どんな学びがあった？

結構色々とハマりました。

極力セレクタ指定したコードを書かない

Webサービスが返すHTMLは、いつもずっと変わらないことはありません。あるidやclassのhtmlタグがずっと残り続けるとは限りません。

そこで、できる限り、セレクタを指定せずにブラウザ操作をするようにしました。例えば、

ボタンやリンクをクリックしてページ遷移するのではなく、目的のページへ最短で直接遷移する
- https://medium.com/me とか。
submitボタンをクリックするのではなく、エンターキーを入力する

です。こうすることで、安定した自動化ができました。

XPathが意外と使える

GoogleやMediumでは、idやclassがランダム値になっています。そのため、単純なidやclassを指定して進めることができません。

そこで、『○○』のテキストが含まれているセレクタの指定することが、XPathでできます。これは、助かりました。

ログインが難しいものは、無理せず諦める

Amazonのログインは、2段階認証が発生します。テキストメッセージや、音声電話によるログインが求められ、Puppeteer単体ではどうしようもありません。

この2段階認証の機能を解除することもできますが、セキュリティ上よろしくないので、ここは無理せず諦めることにしました。

並列処理をガンガン実行する

処理速度向上のため、全サービスを Promise.allで並列処理しました。それぞれが、シークレットウィンドウで開くことで、独立して処理するようにもしました。しかし、たまにPuppeteerが落ちてしまうことがあります。原因は、実行しているマシンのスペック(Core数)にも影響しますが、サービス側からの影響も受けたりします。そのため、落ちても大丈夫のようにエラーハンドリングし、リトライするようにしました。

また、失敗したらどういった画面なのか知りたいので、スクリーンショットを撮るようにもしました。

Docker で実行可能に

Puppeteerに必要なモジュールをDockerに詰め込み、ログイン情報等を環境変数から外注することで、環境非依存の実行環境ができました。そのため、Pub/SubとContainer Engine等を組み合わせれば、 ContentfulのWebfook経由で、アカウント情報を更新することができます。

終わりに

私の性格がもっと大雑把であれば、このツールを作らなかったのですが、どうしても気になって仕方がなく... (笑) 最後まで読んでいただき、ありがとうございました。

2020-05-04

Micro Frontends を学んだすべて

MicroFrontends Thinking

Micro FrontendsというWebフロントエンドアーキテクチャがあります。このアーキテクチャを知るために、書籍を読み、簡単なサンプルWebアプリを開発しました。そこから学んだことをすべて議事録として残したいと思います。

モノリシックな Webアプリケーション
Micro Frontends とは
Micro Frontends の良さ
Micro Frontends の難しさ
Micro Frontends の作る上で考えること
Micro Frontends サンプルWebアプリ
サンプルWebアプリで分かったこと
最後に
参考リンク

モノリシックな Webアプリケーション

マイクロサービスという考え方の多くは、バックエンドへ適用されることが一般的です。一方で、フロントエンドは依然モノリシックなままの状態です。

ECサイトのようなWebアプリケーションでは、様々な専門知識(商品、注文、検索など)を必要とし、フロントエンド開発者の守備範囲がとても広くなってしまいます。開発者には限界があり、いつしかトラブルシューティングに追われる日々になってしまいます。

そこで、Micro Frontendsというアーキテクチャの出番です。

Micro Frontends とは

それはマイクロサービスの考え方をフロントエンドに拡張したものです。 ※ https://micro-frontends-japanese.org

要は、バックエンドだけでなく、バックエンドからフロントエンドまでをマイクロサービス化することです。

さらに詳しく知りたい方は、次のページをご参考下さい。とてもわかりやすいです。 micro-frontends-japanese.org

また、次の書籍を読むと、 www.manning.com

Amazon does not talk a lot about its internal development structure. However, there are reports that the teams who run its e-commerce site have been working like this for a long time. ...

Micro frontends are indeed quite popular in the e-commerce sector. In 2012 the Otto Group, a Germany based mail order company and one of the world’s largest e-commerce players started to split up its monolith. ...

The Swedish furniture company IKEA and Zalando, one of Europes biggest fashion retailers, moved to this model. ...

But micro frontends are also used in other industries. Spotify organizes itself in autonomous end-to-end teams they call Squads. ...

Excerpt From: Michael Geers. “Micro Frontends in Action MEAP V03.” iBooks.

という内容があります。

IKEAやZalando といったECサイトがMicro Frontendsを採用するケースが多く、公には言っていませんが、AmazonもMicro Frontendsで取り組んでいるようです。 ECサイトだけでなく、Spotifyのようなサービスにも適用されるケースがあります。

Micro Frontends の良さ

私が思う Micro Frontends から得られる最大の恩恵は、"局所化" だと思います。

フロントエンドをサービス毎(商品、注文、検索など)に分割することで

サービスの専門性向上
- ex. 対象サービスのフロントエンドだけに集中できる
サービスの開発速度向上
- ex. 対象サービスのソースコードだけ読めば良い
- ex. 対象サービスだけにライブラリアップデートすれば良い
- ex. フレームワークの切り替えは対象サービスだけすれば良い

少し薄っぺらいかも知れませんが、↑のように実感しています。

※ Micro Frontendsは Webベースのアーキテクチャになります。

Micro Frontends の難しさ

ここは、まだちゃんと掘り下げれていませんが、次のようなものがあります。

特定チームが改善しても、チーム全体が改善しない
- ex. あるチームがwebpackのビルド時間短縮に成功しても、他のチームは影響を受けない
- ex. 全てのチームが採用しているライブラリのセキュリティパッチは、それぞれのチームが更新しなければならない
チーム全体へ共有する仕組みを考える必要がある
- ex. デザインシステム、パフォーマンス、ナレッジ
エッジな技術スタック採用は、チームメンバー移動を困難にする
- ex. パラダイムシフトが発生してしまう技術スタック

Micro Frontends の作る上で考えること

フロントエンドをマイクロサービス化するということは、各サービスで HTML/CSS/JSを作ることになります。それらのサービスを統合するサービスが重要になってきます。

大きく分けて2つの統合パターンがあります。

種類	解決手段	メリット	デメリット
サーバーサイド統合	SSI, ESI, Tailor, Podium	・SEO対策上良い・ユーザーのネットワークレイテンシーが少ない・初回ロードパフォーマンスが優れている	・インタラクションアプローチが不得意
クライアントサイド統合	~~Ajax, Iframe,~~ Web Components	・Web標準・シャドウDOMによる堅牢な作り	・サポートブラウザに依存する・クライアント側のJavaScriptが有効であること

また、これら2つの選択基準は次のようになります。

種類	選択基準
サーバーサイド統合	良好な読み込みパフォーマンスと検索エンジンのランキングがプロジェクトの優先事項であること
クライアントサイド統合	さまざまなチームのユーザーインターフェイスを1つの画面に統合する必要があるインタラクティブなアプリケーションを構築すること

今回、私はサーバーサイド統合(Podium)を選択しました。ただ、インタラクティブなアプローチも必要だったため、Hydrationを使いました。

Hydration refers to the client-side process during which Vue takes over the static HTML sent by the server and turns it into dynamic DOM that can react to client-side data changes.

※ https://ssr.vuejs.org/guide/hydration.html

Hydrationは、サーバーサイドでレンダリングした静的HTMLに、クライアントサイドの動的レンダリングができるようにするようなものです。

ちなみにWeb Componentsは、次の入門書(500円)を執筆したため、ご興味がある人は見てみて下さい。 silverbirder.booth.pm

※ クライアントサイド統合(Web Components)でも良かったのですが、私都合により却下となりました。

Micro Frontends サンプルWebアプリ

apple, banana, orangeという商品を検索するだけのサンプルWebアプリを作りました。

概要図はこちらです。 ※ ~~http://team-page.fly.dev/~~ 停止しました。

サンプルコードは、ここに置いています。 github.com

サービス

サービス	役割	JSフレームワーク
team-search	商品を検索するサービス	Vue.js
team-product	商品を表示するサービス	React.js
team-page	サービスを統合するサービス	フレームワーク未使用 (Node.js)

仕組み

Podium というライブラリを採用しました。

github.com

これは、フロントエンドのサービスを簡単に統合できるようなライブラリになっています。 Podium には大きく分けて3つの機能があります。

@podium/podlet
- ページフラグメントサーバーを構築する
- ex. team-search, team-product
@podium/layout
- Podletを集めて、ページ全体のレイアウトを構築する
- ex. team-page
@podium/browser
- ブラウザベースの機能を提供する
- MessageBus による Podlet同士のコミュニケーション
- ex. team-search, team-product で publish/subscribe

@podium/podlet

Podletには、manifest.json と呼ばれる値を返却することが必須になっています。 menifest.jsonには、サービスのエンドポイントや、Asset(JSやCSS)のパスが明記されています。

team-search では

$ curl https://team-search.fly.dev/manifest.json | jq .
  {
    "name": "search",
    "version": "1.0.0",
    "content": "/",
    "fallback": "",
    "assets": {
      "js": "/search/static/fragment.js",
      "css": ""
    },
    "css": [],
    "js": [
      {
        "value": "/search/static/fragment.js",
        "async": true,
        "defer": true,
        "type": "default"
      }
    ],
    "proxy": {}
  }

というレスポンス結果になります。

@podium/layout

Layoutでは、Podletのmanifest.jsonの定義に従って fetchすることになります。

team-page では

// server.js (express)
app.get(`/`, async (req, res) => {
    const incoming = res.locals.podium;

    const [searchBox] = await Promise.all([
        podletSearch.fetch(incoming, {pathname: '/search/box', query: req.query}),
    ]);
    const [items] = await  Promise.all([
       podletProduct.fetch(incoming, {pathname: '/product/items', query: {id: searchBox.headers['x-product-items']}})
    ]);

    res.podiumSend(`
        <html>
            <head>
                <title>Shop</title>
                ${searchBox.js.map(js => js.toHTML())}
                ${items.js.map(js => js.toHTML())}
            </head>
            <body>
                <div id="app-shell">
                    ${searchBox.content}
                    ${items.content}
                </div>
            </body>
        </html>
    `);
});

のようにPodletを使って、ページ全体を構築します。このようにサーバーサイドで統合しています(SSR)。しかし、インタラクティブなアクションも必要なため、PodletからHydrateするためのjsを読み込んでいます。

また、team-searchの検索結果(x-product-items)をteam-productへ渡しているため、商品の検索結果を含めてSSRが実現できます。

@podium/browser

サーバーサイドは、podium/podlet, podium/layoutで連携できます。クライアントサイドは、この @podium/browserのMessageBusで連携できます。

今回のサンプルWebアプリでは、次のようなユースケースに使用しています。

ユーザーが検索ボックスにキーワードを入力する
team-searchがキーワードから商品を検索する
team-searchが2の結果をpublishする
team-productが3をsubscribeし、商品を更新する

// team-search.js
messageBus.publish('search', 'search.word', {items: hitItems});

// team-product.js
messageBus.subscribe('search', 'search.word', event => {
    hydrate(<Items {...{items: event.payload.items}} />, document.querySelector('#team-product-items'));
});