GAミント至上主義

Web Monomaniacal Developer.

Google App Engine Node.js Standard EnvironmentでPuppeteerを使ったPDF変換サーバーを動かす

yagish履歴書でも裏で使っているHTML→PDFの変換サーバー。
GitHubでも公開してます。
github.com

これがGoogle App Engineでも動きそうなので試してみた。
さすがにChromeはインストールできないのでPuppeteer付属のChroniumを使う点と、日本語フォントでちょっとはまったけど問題なく動いた。
でも現時点ではβなのでいろいろ注意。

Puppeteerを動かすのは下記に公式ドキュメントあり。PDF、スクリーンショットの他、テストもはかどりそう。

Using Headless Chrome with Puppeteer  |  App Engine standard environment for Node.js docs  |  Google Cloud

基本的なことは公式を読んでおく。
Google App Engine Node.js Standard Environment Documentation  |  App Engine standard environment for Node.js docs  |  Google Cloud


アプリケーションのコードはGitHubとほぼ同じなので省略。
ファイル構成はこんな感じ。
fontsディレクトリに必要な日本語ファイルを置いておく。無駄に置くとアップロードに時間がかかるのとお金もかかるので最低限にした方がよさげ。

% tree
.
└── app
    ├── app.js
    ├── app.yaml
    ├── fonts
    │   ├── fonts.conf
    │   ├── google
    │   │   ├── NotoSansJP-Medium.otf
    │   │   └── NotoSansJP-Regular.otf
    ├── package-lock.json
    └── package.json

app.yaml

runtime: nodejs8
instance_class: F4_1G
env_variables:
  FONTCONFIG_PATH: "/srv/fonts/"

デプロイ設定はこんな感じ。
FONTCONFIG_PATHで上記フォントのディレクトリを指定する。
/srvはアプリケーションでカレントディレクトリをログに出して見て調べた。
何かで変わってしまうかもしれない。

フォントの設定ファイル
fonts.conf

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <dir>/srv/fonts</dir>
</fontconfig>

フォントの設定は下記記事を参考にさせていただきました。
LambdaよりGAEの方が楽そう。

LambdaでPuppeteer/Headless Chrome | scratchpad

これで無事動いたのだけれど、既存のプロジェクトはリージョンがusになってしまっていて変えられない。そのため結構遅い。
新しくプロジェクトを作り直して日本においてみて、速度を試してみる。
もし問題がなかったら現在GKEで動いているものをGAEにしようと思う。

コードとファイルも整理してGAE用としてGitHubに上げる。

GAEもSecondで最新版の言語ランタイムや自由にパッケージが使えるようになってくるので、GKE、GAE、Cloud Functionsを使い分けるのがはかどりそう。

今度はPython3のDjangoかな
uyamazak.hatenablog.com

Google App Engine standardのNode8 & Python3.7対応で移転祭りはっじまっるよ~!

わぁい!

GCPコスパ最強のアプリ環境App Engineで長年待ち望んだPython3が公開されました。まだβ。

従来のGAEと大きく変わるためSecond generationと呼ばれてます。
App Engine standard environment runtimes  |  App Engine Documentation  |  Google Cloud

これまであった言語のバージョンが古いとかライブラリが限られるとか、大きな欠点がなくなり、GKE+HTTPSロードバランサーを使わざるをえなかった状況がかなり減りそうな予感。

GKEと比較したGAEのメリットはパッと思いつくだけで

Python3.7ということで、DjangoなんかはGAE一択になりそうな予感。

Nodeも8だから、Cloud Functionsの方で肥大化してしまったサービスはGAEに移した方が管理しやすいかも。

Nuxt.jsを使ったSSRのVue.jsアプリなんかもGAEでいけそう。

さすがにヘッドレスChromeは無理かな。。。と思ってググったら公式にあるからいけそう!
Using Headless Chrome with Puppeteer  |  App Engine standard environment for Node.js docs  |  Google Cloud

とはいえ、まだ触ってないので、これからガンガン試してみる。

でもコスト面では一概にGKEよりGAEがいいとか安いとかはいえず、一定のアクセスがくるようなサービスはGKE、波が大きいのはGAEみたいな使い分けが必要なってくるかも。

また小さいサービスをたくさん組み合わせるようなシステムの場合は、GKEでローカルIPで接続した方が、グローバルに出てドメインでアクセスする必要のあるGAEに比べて圧倒的に早いし、GKEの方が効率よくマシンを使えそう。

Nuxt.jsいらない説

Vue使うなら最初からNuxt.js使えよ、という条件反射みたいな風潮にちょっと反論してみる。

※2020/7/6 追記

NuxtJSが必要な状況になって使ったときの感想などはこちら
uyamazak.hatenablog.com

※2018/9/4 追記

1にviewsフォルダ等について追記

またこの記事はNuxtにしようかなと思っていたところでVue CLI3を使って感動し、今も使っていないのでその持論でもあります。

Vue-CLI3に関するVue開発者Evan Youの記事の和訳がきました
jp.vuejs.org

※2019/2/19 追記

SSRのところにOGPについて追記

※追記ここまで

概論

まずVue CLI 3で始めた方がいい。

最初から大人数で大きなアプリを作るつもりだったり、SSRが必要だったらNuxtでいいかも。


私がNuxtを使わない理由3つ

1. Vue CLI3でよく使う公式ライブラリはインストールできるようになった

最近アップデートされたVue CLI3では、プロジェクト作成時にVue Router、Vuex、テスト、lint関連、TypeScriptサポートなどが選べ、選んだ機能に最低限必要な設定ファイルや初期テンプレートが生成されるようになりました。
viewsというディレクトリもができ、routerで使用するページ用vueファイルはそこ、そのほかはcomponentsに入れるというゆるいルールが感じられます。初期状態ではviewsにHome.vue、componentsにHelloWorld.vueが入っている。
でもviewsに入れたからといってNuxtのように自動でルーティングされるわけではなくrouter.jsでの設定が必要。

ホットリロードの開発サーバーも付いているのでほとんどの場合これで十分ではないだろうか。

SSRはついてないので自分でやるかNuxtを使った方がよさそう。
Vue.js Server-Side Rendering Guide | Vue SSR Guide

2. 「The Progressive JavaScript Framework」に反している

jp.vuejs.org

融通が効く
ライブラリと完全な機能を備えたフレームワークの間で拡張できる徐々に採用可能なエコシステム

だからこそNuxtが生まれた理由でもあると思うけど。
Vueは必要に応じてパーツを追加、拡張していこう、みたいな考えを貫いており、コア機能をシンプルに保っています。
その哲学は機能追加の議論などでも貫かれており、かっけーとよく思ってます。

例として最近みたVueにconst的なデータを持たせたいみたいな議論
Constant component data · Issue #6004 · vuejs/vue · GitHub

Vueを始めるときも、最初はCDNからの読み込みで触って、大きくなってきたらシングルファイルコンポーネントで書きたくなってvue-cli使って、みたいに大きくなっていったので、非常にいい思想だと思っています。

その過程でああ、だからVuexがいるんだ、router使うとこんな便利なんだ、みたいな途中の学習や納得が積み重なりVueへの理解が深まります。

一方Nuxt.jsはRailsみたいにいきなりどかっとサーバー環境まるごと全部入り環境な感じなので、Nuxtで一通り用意されてる構造や規約を理解して、それに従って作っていく感じになります。

3. Vue公式ではない

NuxtはVueを使ってるけど別プロジェクトです。
それだけのことですが、NuxtはVueの変更に対し後追いになってしまったり継続が大変そうだなぁと思う。

直接関係ないけど面白いのがGitHubでコントリビューター一覧上位を見ると、全然空気が違う。

Vueは中国系とアニメアイコンが目立つのに対し
Contributors to vuejs/vue · GitHub

Nuxtはヨーロッパ系な感じ。
Contributors to nuxt/nuxt.js · GitHub

それでもNuxtを採用する理由

  • VueでSSRを手っ取り早くやりたい(特にページごとのOGP出しわけは現在のところSSRが必須)
  • Vueのコンセプトどうでもいいから一通り全部用意してもらいたい
  • みんな使ってるから使う

で、現時点の私はコードに関わる開発はデザイナーと私で2人で、企画、設計、ユーザーテスト等その他運営もろもろを2人やっている小さな新規サービス(yagish履歴書)であり、Serach Consoleも問題なくてSSRの必要性もないため、Vue-CLI3で十分、Nuxt.jsいらないとなっています。