「Express」の記事 - Crieit

PassportでTwitterに遷移する前に処理を行う

2019-03-09T01:04:54+09:00

PassportでのTwitterログインは簡単にできるようになっているが、公式のマニュアルだと説明が簡単すぎて、Twitterに遷移する前に処理を入れたい場合にどうすればいいか分かりづらい。

例えばログイン時にいたページに戻るためにパラメータにURLを渡して、ログイン後はそこに戻りたい場合。URLをセッションに保存しておきたいので処理を入れたい。

結局authenticateはMiddlewareを返すだけなので処理をしたあとそれを呼べばよいだけ。

  app.get('/auth/twitter', (req, res, next) => {
    if (req.query.back) {
      req.session.loginBack = req.query.back
    }
    passport.authenticate('twitter')(req, res, next)
  })

Express+TypeORMの環境にてWerckerでCI

2019-03-08T00:17:46+09:00

ExpressとTypeORMを使ったアプリケーションのWerckerでのCIがとりあえず完成したのでメモ。

box: node

services:
  - id: mysql
    tag: 5.7
    env:
      MYSQL_ALLOW_EMPTY_PASSWORD: true
      MYSQL_DATABASE: dbname

build:
  steps:
    - script:
        name: yarn
        code: yarn

    - script:
        name: Fill mysql env
        code: |-
          cp .env.example .env
          sudo sed -i -e "s/TYPEORM_HOST=localhost/TYPEORM_HOST=$MYSQL_PORT_3306_TCP_ADDR/g" .env
          sudo sed -i -e "s/TYPEORM_PORT=3306/TYPEORM_PORT=$MYSQL_PORT_3306_TCP_PORT/g" .env
          cp .env test/.env

    - script:
        name: migration
        code: yarn run migrate:run

    - script:
        name: yarn test
        code: yarn test

migrationとtestのコマンドは適宜自分で設定。

test/.envはテスト用に読むこむやつを設定しているというだけなので別のやり方をしている場合は不要。

TypeORMは特にテスト用のDB管理方法があるわけではないようなので、事前にマイグレーションしている。（ローカル環境も考慮すると全部自分で準備しなければならないのが非常に面倒）

ちなみにテストは下記でつくったもの。

Mocha+SuperTestでasync/awaitを使ってテスト

ExpressとJimpで画像を出力する

2019-02-28T23:27:00+09:00

Node.jsでOGPを作ろうと思ったのですが、いちいちImageMagickとかインストールしたりするのが面倒だったのでnpmのパッケージをインストールするだけで使えるっぽいJimpというライブラリでの出力を試してみました。（Jimp v0.53）

なんか公式通りにimportだと上手くいかなかったので適当にrequireしています。

const Jimp = require('jimp')

router.get('/:id/ogp.png', async (req, res) => {
  const font = await Jimp.loadFont(Jimp.FONT_SANS_32_BLACK)
  const image = await Jimp.read(600, 315, 0x0000ffff)

  res.type('png')
  image.print(font, 10, 10, 'Hello World!')
  image.getBuffer(Jimp.MIME_PNG, (err, data) => {
    res.end(data)
  })
})

動作的には良さそうなんですが、まともなマニュアルがほしいですね。あとテキストはビットマップフォントのようです…。

node-canvasの方が簡単で良さげでした。

TypeORMの接続をセッションとして利用する

2019-02-15T23:47:25+09:00

Expressにてセッションを使うとなると最近はRedisとかがスタンダードになっていってると思いますが、MySQLをTypeORM経由で使いたい時の備忘録です。具体的にはexpress-mysql-sessionというライブラリを使います。

chill117/express-mysql-session: A MySQL session store for the express framework in node

マニュアルにも書かれている通り、ホストやポートなどを指定して接続できるのですが、アプリケーション側の接続と重複してしまうので、ORMのライブラリによる接続を共有する方法も可能となっています。

今回TypeORM 0.2を使っているのでそちらで接続できるようにしました。まずインポート。

const session = require('express-session')
const MySQLStore = require('express-mysql-session')(session)

そしてセッションの設定です。

  const mysqlDriver: any = connection.driver
  app.use(
    session({
      secret: process.env.APP_KEY,
      store: new MySQLStore({}, mysqlDriver.pool),
      resave: false,
      saveUninitialized: false,
      cookie: { secure: process.env.NODE_ENV == 'production' }
    })
  )

TypeORMのConnectionがinterfaceを参照しているのか、細かいプロパティが取れないので仕方なくanyに変換してMySQLのStoreに渡すためのpoolを取得しています。（MySQLのconnectionだけじゃなくてpoolも使えます）

あと、resaveをtrueにしているとセッション情報を上書きしまくっておかしくなるようなのでfalseにしておきました。

まだ動かしてあまり時間が経っていないのでおかしなところなどがあればご指摘ください。また、まだTypeORMのバージョンが0.2なので変わってしまう可能性もあります。

passport-twitterでFailed to find request token in sessionエラー

2019-02-13T21:59:32+09:00

久しぶりにpassport-twitterを使ってみたところ、Failed to find request token in sessionというエラーが出てログインができませんでした。

このエラーを調べてみると、だいたいよく見つかる情報として、localhostだったのに127.0.0.1に戻って来てるから、とか、とりあえず127.0.0.1に統一しておけばいい、のような情報が見つかります。

しかし今回はどうも統一してもうまくいかずエラーが改善しなかったため、他に原因がありそうでした。

詳しくはわかりませんが、セッションの設定を下記のようにすることで改善しました。

app.use(
  require('express-session')({
    secret: process.env.APP_KEY,
    resave: true,
    saveUninitialized: false,
    cookie: { secure: process.env.NODE_ENV == 'production' }
  })
)

resave, saveUninitialized, cookieを上記のように指定しています。元々resaveとsaveUninitializedはデフォルトがあるだろうしそのままでいいだろう、と思って省略していたのですが、よくよく見るとビルド時に下記のようなログが出ていました。

express-session deprecated undefined resave option; provide resave option server/index.ts:46:35
express-session deprecated undefined saveUninitialized option; provide saveUninitialized option server/index.ts:46:35

READMEに

The default value is true

とあったのでデフォルトがあると思っていたのですが、よくよく続きを読むと

The default value is true, but using the default has been deprecated

ということで無指定はdeprecatedでした。よくよく調べ直して設定してみたところうまく動くようになりました。とりあえずsaveUninitializedがデフォルトと違うようなのでこちらが問題だったのかもしれません（正直このオプションによる挙動の違いはマニュアルを見ても全くわからないのですが…）。何にしろ同様のパターンでうまくいかない方はこのあたりを調整してみると良いかもしれません。

ちなみに、express-mysql-sessionを使用した時はresaveはtrueにしないと保存したセッション情報を何度も別のもので上書きしてしまうようでした。使用しているstoreによっても変わってくるようなので適宜確認して見る必要がありそうです。

Nuxt.js+Express+TypeORMでの環境構築でつまづいた所等の備忘録

2019-02-13T20:54:02+09:00

久しぶりにフルNode.jsの環境を構築したら色々ハマったので備忘録を書いておきます。とりあえずローカル環境での実行と、ローカル環境でのproductionビルドと起動が成功するまでを動くところまでの話になります。知識不足により正しい解決方法ではないものや、対応方法によっては今後また別の問題が出る可能性がある箇所などもあるかもしれませんので、あくまでも細かい部分の問題解決方法のヒントになるかも、くらいの認識で見ていただいた方が良いと思います。

下記のような構成です。

Nuxt.js 2.4
Express 4
TypeORM 0.2
開発はts-node
productionビルドでサーバー側はdistフォルダにビルド

以前書いたこのあたりの記事で作ったプロジェクトの作り方と大体同じです。（この時は同様のエラーは出なかったのですが…）

Nuxt.js+ExpressのプロジェクトをTypeScript化する

commonjs設定にしたらエラーが出た

TypeORMの解説の通りtsconfig.jsonのmodule設定をcommonjsにしたら、vueコンポーネントのexport defaultしているところで下記のようなエラーが出てビルドできなくなりました。

export 'default' … was not found

よく分からなかったのでとりあえずmoduleはes2015に戻し、nodemon.jsonでts-nodeを実行している箇所で下記のようにmoduleを上書きするようにしました。

  "exec": "ts-node -O '{\"module\": \"commonjs\"}' ./server/index.ts"

あとはproductionビルド用にpackage.jsonのbuildスクリプトも下記のようにしました。

    "build": "tsc --module commonjs && node copy_statics.js && cross-env NODE_ENV=production nuxt build",

これで動くならtsconfig.jsonを変えるだけで動いてくれよという感じですが…。僕の何かがおかしいだけかもしれませんのでまた時間が経ったら試してみる予定です。

productionビルド後の実行でエラー

TypeORMが上手く動かずエラーになってしまいました。エラーログを見るとなぜかビルドしたjsのentityファイルでなく、ビルド前のtsファイルの方をimportしていたようです。

outDirを指定している場合だけかもしれませんが、とにかくormconfigを修正して対処しました。ormconfigはjsonファイルでなくormconfig.jsファイルとして書いています。

let path = 'src';
if (process.env.NODE_ENV == 'production') {
  path = 'dist/' + path
}
module.exports = {
  entities: [
    `${path}/entity/**/*{.ts,.js}`
  ],
  migrations: [
    `${path}/migration/**/*{.ts,.js}`
  ],
  subscribers: [
    `${path}/subscriber/**/*{.ts,.js}`
  ],

ただまあここは環境変数が使えるのでそちらにした方が楽そうな気がします。

CLI

今度はCLIでもエラーが出るようになるので、こちらも-Oオプションが必要です。面倒ですね…。良い対処方法があれば教えてください。

まとめ

とりあえず開発が進められるところまでエラーをざっと取りました。他に正しい対応方法などある可能性もありそうなのでまたそのうち確認します。

というかTypeORMいいなと思って使ってみましたがまだバージョン0.2なんですね。今後バージョンアップも必要そうですし、まだまだ色々何かしら問題が出てくるかもしれません。

NodeでChromeを操作してTwitterシェア用画像を生成するサーバー作った

2019-02-12T07:22:09+09:00

Node.jsにはPuppeteerという画面を表示せずにChromeを扱えるライブラリがあります。それを利用し、URLをパラメータとして与えるだけでスクリーンショットを画像としてブラウザで表示させることができるサーバーアプリケーションを作成しました。

実際にこのような画像が作成できます。例として下記はボード内投稿にコードを入れた場合に表示される画像です。

下記は記事の画像です。

HTML, CSSから生成しているためドロップシャドウとかもこんな感じで簡単に効かせる事ができています。

GitHubで公開していますので、とりあえず使って見たいという方は記事を読み飛ばして最後の方にあるリンクをご利用ください(こらえきれぬ涙で頬を濡らしながら)

何が便利なのか

WebサービスのURLをTwitter等でシェアするだけで、URLだけでなくツイートに画像も表示されるのをよく見ると思います。

これは画像をアップしているわけではなく、そのページ内のHTMLに書かれているメタタグで指定されている画像を勝手にSNS側で表示してくれるという便利な、いわゆるOGPというものです。

Webサービスでの困りごと

普通のサイトであれば画像を指定するだけですが、Webサービスの場合は投稿された内容をもとにしたOGPを動的に作りたいという場合があります。

この場合画像を動的に作成しなければならないのですが、これがなかなか面倒です。

サーバーサイドでやると、負荷がかかったりそもそも描画がプログラムによる命令で構築されることが多く、メンテナンスが非常に面倒です。フロントでやることもできますが、ブラウザの閲覧環境によって表示に違いが出てしまったりします。

解決策

そのため、専用のPuppeteerを用いたOGP生成サーバーを用意することで前述の全ての問題を解決することができます。

OGPはURLを指定するだけのため、サーバーを別にすることもできますので、分けておけばアプリケーションサーバー側に負荷は一切ありません。また、OGPサーバーのブラウザで表示を行いスクリーンショットをとるため、ユーザーの環境にも依存しません。

具体的な仕組み

今回作成したものは、URLを指定するとそのURLのスクリーンショットを撮って画像として表示してくれる、というだけの非常にシンプルなものです。

例えば最初の記事の画像であれば、実際のなぜCrieitを作ろうと思ったかのページにアクセスし、ソースを見るとわかりますが、下記のようなメタタグがあります。

このog:imageとtwitter:imageに指定されている画像が今回紹介する仕組みで作成されている画像です。

具体的には、crieit.netの全く同じパスのスクリーンショットを撮る仕組みになっています。つまり、上記であれば下記のURLのスクリーンショットを撮っています。実際に見ていただくことも可能です。（拡張子はつけれるようにしています。理由は後述します）

https://crieit.net/posts/Crieit-5b91bd1569dbd/ogp

アクセスしていただくとわかりますが、OGP画像をそのまま単なるHTMLとCSSで作っているだけになります。単にそのページのスクリーンショットを撮っているだけです。この例ですとフォントが違うと思いますが、それはOGPサーバー内にインストールしているのでOGPサーバー内のChromeでは正しいフォントで表示されます。

ちなみにブラウザでのレンダリングのため、JavaScriptも動きます。今回のコード表示の例もhighlight.jsを動かしています。

URLに拡張子

前述の例のように、OGPサーバー側のURLには拡張子をつけることができます。これにより、CloudflareのようなCDNを介する場合、ちゃんとキャッシュしてくれるようになります。

つまり、そのURLに一度誰かがアクセスしていればその後はCDNで配信されるようになるため、OGPサーバー側にはアクセスが来なくなります。

実際に前述の画像を開いてリロードするとめちゃくちゃ速いのがわかると思います。たいした処理ではないにしろ、本来はブラウザでページを開くだけの時間がかかりますので全然変わってきます。

とはいえそもそもOGPはだいたいSNS側でキャッシュされるためあまりメリットは大きくないのですが、改造すれば他の用途にも使用することができますので、この仕組みを覚えておけば色々と便利ではあると思います。

構成要素

Puppeteerを使うのでNode.jsのサーバーとなります。

サーバーはExpressで、expressコマンドで作成したソースのほとんどそのままです。複雑なことはしていないので数十行書いたくらいで完成しました。(そのため不要な処理もたくさん残っていて作り自体は雑です…)

functions系の利用は断念

現在色々なPaasやfunctionsサービスがありますが、色々調べたり試した結果利用は断念し、最終的にシンプルにExpressによるNode.jsのサーバーで作ることにしました。

断念した理由は下記等です。

リクエスト毎にブラウザを起動しなければならないため、画像生成にかなり時間がかかりそう。Expressであれば最初に一度起動しておくだけでよい
サービスによってはそもそも使えない
サービス上では特殊な実装にしなければならない場合があるので、ローカルで試しづらく開発に時間がかかって面倒な場合がある
サービスによってはプロセスの実行時間制限があったりする

…等です。もしうまく簡単に動かせるサービスがあったらぜひ教えてください。

サーバー

実際のサーバーの作り方を解説していきます。

Chromeをインストール

一番重要な仕事をしてくれるものです。

ChromeDriverを試していた時の名残で一部不要なものが混じってるかもしれません。これはDockerfileの中身そのままです。

apt-get update
apt-get install -y libappindicator1 fonts-liberation unzip
curl -O https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
dpkg -i google-chrome*.deb || apt update && apt-get install -f -y

フォントをインストール

Webフォントだけでページを作れば不要ですが、そうでない場合や不足のフォントがありそうな場合にはインストールしておきます。

apt-get install fonts-ipafont-gothic fonts-ipafont-mincho

Node.jsをインストール

とりあえずnpmとyarnを入れておきます。公式サイトに書かれている手順で入れておけば問題ないと思います。

npmのモジュールーインストール

Chromeはすでにインストールしているため、それをスキップする形でインストールします。違うパターンでインストールしたい場合は適宜変更してください。

PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true yarn

Nginxをインストール

これは必須ではないのですが、ポート3000で動いているNode.jsサーバーを80にプロキシしたかったのと、SSLに対応したかったため同じくLet's Encryptのcertbotが使用するURLもプロキシして放置で証明書が更新されるようにしたかったためNginxで動かすようにしています。（ここもわりと適当なため適宜変更してください）

        listen 443 ssl default_server;
        ssl_certificate /etc/letsencrypt/live/ogp.example.net/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/ogp.example.net/privkey.pem;

        server_name ogp.example.net;

        proxy_redirect off;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;

        location ^~ /.well-known/ {
                root /var/www/html;
        }

        location / {
                proxy_pass http://localhost:3000/;
        }

Systemdでサービス化

下記のように設定しました。

[Unit]
Description=ogp server
After=syslog.target network.target

[Service]
Type=simple
ExecStart=/usr/bin/npm start
WorkingDirectory=/path/to/puppeteer-ogp
KillMode=mixed
Restart=always
User=yourname
Group=yourgroup

[Install]
WantedBy=multi-user.target

だと、理由はまだよく分かりませんがうまくアプリケーションやChromeのプロセスが終了してくれないため、KillMode=mixedにして丸々強制終了するようにしています。

サービスの有効化は下記です。

sudo systemctl enable ogp

あとは下記で起動すれば完全放置できます。

sudo service ogp start

ちなみに僕は無料枠で動かせるGCE（Google Compute Engine）のf1-microを使っています。

公開しました

かなり何もやってないレベルの製作物だったので、作成したものをGitHubで公開しています。是非適当に試してみたり、改造して遊んでみたりしてみてください。

dala00/puppeteer-ogp

下記に重要な注意点を書きます。そのあとローカルでの開発方法もざっと書いておきます

注意点

まだ動かしてからさほど経っていないため、どれくらい安定稼働してくれるかは謎です。というのも、アプリケーションとは別にChromeが動いているので、そのあたりで安定性がどうなのかという部分が全く想像できません。一応最後に調整をしてからは問題ないようなのですが、稼働初期はクラッシュしまくっていました。

ですので利用される場合は自己責任でよろしくお願いします。一応どういう対策を入れたかと、どういう問題がありそうかをメモしておきます。

エラー処理を入れる

ブラウザがクラッシュする前提で、ページを開くときとかにエラーをcatchするようにし、問題があれば再起動するようにします。ただ、確認が不十分のため現在のエラー処理自体が正しくない可能性があります。実際にクラッシュするとプロセスがどんどん増えていく問題を確認済みです。

おそらくですが、デーモン化して確実に再起動される状態であれば、問題が出たらそのままアプリケーションを落としてしまう方が安心では、という気がしています。（そうなると安定性と高頻度アクセスを保証すべきようなアプリケーションでは難しいかもしれませんが）

URLのフィルタを入れる

これが今のところ一番の改善になりました。というのも、サーバーを公開していると.gitフォルダやphpMyAdminを無差別に探してデータを盗もうとする不審なアクセスがあります。これが一瞬のあいだに高頻度で行われるのでChromeへの負荷が高まりクラッシュしていました。

そのため下記のような感じで環境変数にて必要なURLだけをフィルタできるようにし、それ以外のURLの場合はChromeを使わないようにしました。これだけでクラッシュが発生しなくなりました。

URL_FILTER=/articles,/posts

とにかく、いかにChromeを使用しないか、というところが重要になってくる気がします。アクセスが多い場合、待機させるようにして同時にたくさんのページを開かないような形にすると安定性が上る可能性もありそうです。（ただしレスポンスが悪くなるとSNSがOGPを認識してくれない可能性も出てきそうですが）

キューで処理する（追記）

来たリクエストをすぐ処理せず、キューで処理する形式にしてサーバー全体で一度に１ページしか開かないようにしたところ安定している気がします。GitHubのプログラムもそのように更新済みです。

多分結構スペックが高いサーバーの方が良さそう

Chrome自体が低スペック環境でガンガン快適に動くようなものではないので、サーバーもスペックが高いほうが良さそうな気がします。実際に現在使っているGoogle Compute Engineのf1-microインスタンスでは、マシンタイプをグレードアップしたほうが良い、というアラートがずっと出っぱなしになっています。

また、おそらくスペックが高いほうがクラッシュする可能性も低くなるのでは…と想像しています。

参考にした情報

たしか下記あたりを参考にしました。

ローカルでの開発方法

基本的にはGitHubにあげているREADMEそのままですが、Dockerとdocker-composeさえ入っていれば誰でもすぐ試せるようになっています。Getting StartedとDevelopmentのところをそのまま行うだけで動きます。

まとめ

ちょっと改造すればひとつのサーバーで複数のサービスのURLに対応することも可能ですし、特に個人開発している人はひとり一OGPサーバーを持っておくとなにかと便利な気がします。

コードのOGPはよろしければ下記で色々投稿して試してみてください！

コードのOGPを試してみるボード

もし問題やプルリクエストがある場合はお気軽にGitHubに立ててください。（余裕のあるときしか見れないかもしれませんが…）

Nuxt.js+ExpressのプロジェクトをTypeScript化する

2018-08-27T21:01:24+09:00

create-nuxt-appでNuxt.js+Expressのプロジェクトは簡単に作ることができますが、それで作成したプロジェクトをTypeScript化してみました。

TypeScript化の対応は、Nuxt.js側、Express側で別々となります。Express側はちょっと面倒なので、とりあえずNuxt.jsだけ先にやっておく、とかでも良いと思います。

Nuxt.js+Expressプロジェクトの作成は下記で紹介しているexpress-templateを利用おり、今回の記事はそちらの前提の説明となります。

Nuxt+Expressのプロジェクト作成で良さそうなのは？

※ 2018/8現在の情報です。ところどころNuxt.js1の情報が混じっていますので、下記も合わせて確認が必要な箇所があります。

Nuxt.jsのプロジェクトをNuxt.js2にバージョンアップしてみた

Nuxt.js側をTypeScript化する

基本的には、create-nuxt-appのtypescript-templateで実装されているものを参考にしています。

nuxt-community/typescript-template: Typescript starter with Nuxt.js

TypeScript関連をインストール

とりあえずTypeScriptをインストールします。

yarn add --dev typescript [email protected]

ts-loaderは3.5.0のバージョンを指定します（Nuxt.js2の場合は4）。無指定だとこのプロジェクトに合わないバージョンが入ってエラーになってしまいます。

あとはNuxt.jsとVueをTypeScriptと連携させるライブラリも入れておきます。

yarn add nuxt-property-decorator

設定ファイルを準備

先程の typescript-template のリポジトリから、下記のファイルをそのままコピーしてきます。

index.d.ts
tsconfig.json
modules/typescript.js

そして、nuxt.config.jsのmodulesに"~/modules/typescript.js"を追加しておきます。

基本的にはこれで完了です。あとは実際に各コンポーネントをTypeScriptにしていくだけです。

VueコンポーネントをTypeScript化する

とりあえず簡単なコンポーネントのサンプルです。JavaScriptのままでも動きますので、必要なコンポーネントから順次TypeScriptに変更していくことも可能です。

scriptタグ

scriptタグはlang="ts"を追記します。

Vueクラスを使う

JavaScriptの場合はオブジェクトをexportしていましたが、TypeScriptの場合はclassを使うため、Vueクラスを継承したクラスを作成してそれをexportします。

export default class extends Vue {

Componentデコレータを使う

TypeScriptの場合は、クラス内にコンポーネントの設定を行うのではなく、@Componentデコレータを追加してそちらに設定を追加します。

@Component({
  components: {
    SubComponent
  }
})

ステートはプロパティとして定義

コンポーネントが保持するステートはdataメソッドを使う必要がなく、直接クラスのプロパティとして定義します。もちろん型も指定できます。配列やオブジェクトの場合は型を指定しておかないとメソッド内で使う場合にエラーになったりします。

cnt = 0;
item: Item;

プロパティはPropを使う

呼び出し元から渡されるVueコンポーネントのプロパティは@Propを使ってクラスのプロパティとして定義します。@Propは@Prop(Number)のようにもできますし、色々と指定方法があります。

メソッドはクラスのメソッド

その他はだいたい一緒です。メソッドはクラスのメソッドになるため、カンマ等で区切る必要はありません。

Express側をTypeScript化する

Express側はちょっと面倒なので、気分が乗ったらやる、くらいの感じでも良いかも知れません。シンプルなルーティングの処理がメインだと恩恵も少ないかもしれません。

そもそも開発時とリリースビルド時でも処理が異なるため、両方で動かせるように気をつけながら対応していく必要があります。また、色々な方法がありそうだったため、拘る人は自分で色々と調べて実装してみたほうが良いかも知れません。今回はとりあえずやってみて動いた方法を紹介します。

ちなみに本番環境の手順については、一応ローカルでは動いていますが実際の本番環境では未構築のためまだ何か問題が出る可能性もありますのでご注意ください。何か見つかり次第等記事に追記していきます。

開発時の設定

前述のテンプレートだと、開発時はnodemonを利用してサーバーを起動＆ホットリロードを実現しています。開発時はある程度適当でも問題ないと思いますので、nodemonでts-nodeを使えるようにします。ts-nodeというのはNodeのスクリプトを実行する時に、直接TypeScriptを実行できるようにするコマンドです。

ts-nodeを設定

ts-nodeの設定は下記を参考にしました。

nodejs + TypeScriptでサーバーサイドを開発している時に、コードを編集したら自動リロードさせる。

まずはts-nodeをインストールします。

yarn add --dev ts-node

nodemonでtsファイルを使えるように設定ファイルを追加します。

nodemon.json

{
    "watch": ["server", "routes"],
    "ext": "ts",
    "exec": "ts-node ./server/index.ts"
}

package.jsonのdevスクリプトで、nodemon server/index.jsとしている部分をnodemon server/index.tsのように拡張子を変更します。

あとはserver/index.jsの拡張子をtsに変更すればOKです。

基本的にはこれでdevスクリプトは動くと思うのですが、他の各ファイルのグローバルな場所で同じ変数（router等）が定義されているとエラーになってしまうようなので、クラス化したり変数名を変えるか、下記のようにファイル全体を中括弧で囲んでおくかします。

{
  const { Router } = require("express");
  const router = Router();

  router.get("/logout", function(req, res) {
    req.logout();
    res.redirect("/");
  });

  app.use("/auth", router);
}

他のファイルもTypeScript化する

その他のルーティング用ファイルなども、基本的には拡張子をtsに変更すれば動きます。server/index.tsからそれらの読み込む場合などに、拡張子の指定が必要になります。

あとは定義されていない変数などを使用するとエラーとして検出してくれたりしますので、使っていない処理などがあってエラーになってしまう場合は適当に修正しておいてください。

また、オブジェクトも適当なプロパティを途中で追加したりするとエラーになりますので、変数を定義する場合にany等をつけておいてください。

const where: any = {
  deleted_at: null
};
where.keyword = req.params.keyword;

本番ビルド用の設定

そのままビルドするとtsファイルの横に大量にjsファイルが作られてしまうため、適当にフォルダを作ってそちらにビルドされるようにします。

tsconfig.json

    "outDir": "./dist"

あとは設定ファイルやpackage.jsonも上記フォルダに無いとエラーになってしまうため、スクリプトを作ってコピーするようにしておきます。

copy_statics.js

const fs = require("fs-extra");
const targets = ["config", "package.json"];
targets.forEach(path => {
  fs.copySync(path, `dist/${path}`);
});

あとはtsファイルのトランスパイル、コピースクリプトの実行を実行し、トランスパイルされたjsファイルを実行するようにビルド＆起動スクリプトを変更します。（startはbuildを実行してからになります）

package.json

    "build": "tsc && node copy_statics.js && nuxt build",
    "start": "cross-env NODE_ENV=production node dist/server/index.js",

あと、本番ビルドのフォルダの関係でrequireやimportで.tsのように拡張子をつけている場合はエラーになるため、拡張子は削除しておきましょう。Sequelizeの models/index.ts の中身も変更しておきます。

before

    return (
      file.indexOf(".") !== 0 && file !== basename && file.slice(-3) === ".ts"
    );

after

    const ext = file.slice(-3);
    const validExt = ext === ".ts" || ext === ".js";
    return file.indexOf(".") !== 0 && file !== basename && validExt;

これで開発環境、本番環境共通のファイルでTypeScriptが動かせるようになっていると思います。

importがエラーになる場合

開発サーバー実行時にサーバー側のみに限りimportを行うとエラーになると思いますので、その場合はnodemon.jsonのスクリプトを下記の様に変更するとimportできるようになります。

    "exec": "ts-node -O '{\"module\": \"commonjs\"}' ./server/index.ts"

本番もざっと検証してみましたが、やはりtsconfigの方もcommonjsでないと動きませんでした。あと、postcss関連のエラーが出るようなのでNuxt1の場合はNuxt2にアップグレードが必要です。

参考
Nuxt.jsのプロジェクトをNuxt.js2にバージョンアップしてみた

まとめ

まだ開発中のプロジェクトで試した方法を投稿しただけになりますので、場合によってはうまく動かないパターンなどが出るかもしれません。何か見つかり次第また追記していきます。

とりあえず未定義の変数を使う場合はエラーになったりしますので、typoを減らしたりという効果はすぐ出そうです。

Expressのセッションにファイルを使う

2018-08-21T22:09:13+09:00

Expressでアプリケーションを作る場合、express-sessionを使うことで簡単にセッションを利用できます。ただ、これはインメモリのセッションのため、サーバーを再起動するとセッションが消えてしまいます。そのため、ファイルのセッションを試してみました。

※　引き続き検証中ですが状況によってうまくセッションが読み込めなかったりしています。

環境

Express 4.15
express-session 1.15

session-file-store

下記のライブラリを使いました。

valery-barysok/session-file-store: Session file store is a provision for storing session data in the session file

インストール

yarn add session-file-store

設定

元々あったセッションの設定を下記のようにsession-file-storeを使う形に変更します。

const session = require("express-session");
const FileStore = require("session-file-store")(session);

app.use(
  session({
    secret: "your secret",
    store: new FileStore({
      ttl: 30 * 86400
    }),
    expires: new Date(253402300000000),
    resave: true,
    saveUninitialized: false
  })
);

僕が試した時は、resaveを設定しないと（最初だけ？）セッションが保存されませんでした。（とはいえresaveはデフォルトtrueとマニュアルにも書かれていますが…謎です）

もしかすると有効期限など、他の設定と影響したりしても挙動が変わってくるかもしれません。

まとめ

Expressのプロジェクトでファイルに保存するセッションを試してみました。

実際はデータベースに保存したりする方が良いとは思います。でも一応mweibel/connect-session-sequelizeというパッケージはあったのですが、最新のSequelizeでは動作しないようでした。あまりそのあたりのパッケージは充実していないのでしょうか。

あとは速さを求めるならそのままインメモリのままでも良いのかもしれません。何かでデーモンが再起動してしまった時のことなどが気にはなりますが。

そういう面でもファイルは割とお手軽で良いと思います（まだがっつり動作確認はできていませんが）。不安な場合等はとりあえず開発環境だけセッションをファイルで保存するようにしておくと良いかもしれませんね。サーバーが再起動する度にログイン状態が消えたりするのは結構面倒ですし。

Nuxt.js+Expressで簡単にTwitter認証

2018-08-16T12:02:02+09:00

Nuxt.jsとExpressでアプリケーションを作成する場合のTwitter認証でのログインを試してみました。Node.jsでのTwitter認証はPassportというライブラリを使用すると非常に簡単でした。細かく検証はしていませんがSSR（サーバーサイドレンダリング）の場合でも問題ないと思われます。

このあたりで作ったプロジェクトをベースにして試しています。

Nuxt.js+Expressでとにかく簡単にORM

Nuxt.js v1.4.2
Passport-twitter v1.0.4

インストール

何はともあれまずはインストールします。Passport本体とTwitter用の拡張です。

基本的なところは公式のマニュアル通りですので、よくわからなくなった場合やバージョンが違う場合はそちらを参考にしてください。

Documentation: Twitter

yarn add passport passport-twitter

初期設定

Passportの設定

まずはplugins/passport.jsとして初期化スクリプトを作成します。TWITTER_CONSUMER_KEY等は環境変数として指定しておいてください。（dotenv等を使うと便利です）

下記はSequelizeでユーザーデータとして保存する場合のサンプルも入れています。

var passport = require("passport"),
  TwitterStrategy = require("passport-twitter").Strategy;

module.exports = function(app) {
  const models = app.get("models");
  const User = models.User;

  passport.use(
    new TwitterStrategy(
      {
        consumerKey: process.env.TWITTER_CONSUMER_KEY,
        consumerSecret: process.env.TWITTER_CONSUMER_SECRET,
        callbackURL: `${process.env.APP_URL}/auth/twitter/callback`,
        includeEmail: true // メールアドレスが必要な場合
      },
      async function(token, tokenSecret, profile, done) {
        let user = await User.findOne({
          where: { twitter_id: profile.id }
        });

        if (!user) {
          user = User.build({
            unique_id: profile.username,
            name: profile.displayName,
            email: profile.emails[0].value,
            location: profile._json.location,
            bio: profile._json.description,
            url: profile._json.url,
            image: profile.photos[0].value,
            twitter_id: profile.id,
            twitter_token: token,
            twitter_secret: tokenSecret
          });
          await user.save();
        }

        done(null, user.get({ plain: true }));
      }
    )
  );

  passport.serializeUser(function(user, done) {
    done(null, user);
  });

  passport.deserializeUser(function(user, done) {
    done(null, user);
  });

  return passport;
};

認証用ルーティング

認証用のルーティングを作成します。今回はroutes/auth.jsとしてファイルを分けました。アクションにそのままPassportの処理を指定するようなので下記のようにしてルーティング設定全体を関数化して読み込む形にしました。

const { Router } = require("express");

module.exports = function(app, passport) {
  const router = Router();

  router.get("/twitter", passport.authenticate("twitter"));

  router.get(
    "/twitter/callback",
    passport.authenticate("twitter", {
      successRedirect: "/",
      failureRedirect: "/"
    })
  );

  app.use("/auth", router);
};

アプリケーションに組み込み

これらをserver/index.jsで読み込んでアプリケーションに組み込みます。

const passport = require("../plugins/passport")(app);

app.use(
  session({
    secret: "your secret"
  })
);
app.use(passport.initialize());
app.use(passport.session());

require("../routes/auth")(app, passport);

基本的な部分はこれで完了です。あとは実際に動かしていくための処理を入れていきます。

Nuxt.jsと連携させる

PassportでのログインはExpress側のセッションに保存しているだけのため、これをNuxt.js側にも渡します。アプリケーション全体に絡むことのため、Storeを使ってNuxt.js上のどこからでもアクセスできるようにします。Nuxt.jsの場合は下記のように適当にファイルを一つ追加するだけで簡単にStoreが利用できます。

store/index.js

export const state = () => ({
  authUser: null
});

export const mutations = {
  setUser(state, authUser) {
    state.authUser = authUser;
  }
};

export const actions = {
  nuxtServerInit({ commit }, { req }) {
    if (req.session.passport && req.session.passport.user) {
      commit("setUser", req.session.passport.user);
    }
  }
};

Storeの場合setUserでなくSET_USERが使われることが多い気がします。

あとはもう下記のようにゆるふわな感じで適当にログインしているか判断できます。

スクリプト側でもthis.$store.state.authUserみたいな感じで利用できます。

まとめ

荒い感じの書き方も一部あるかもしれませんが、とりあえず非常に簡単にTwitterログインを行ってNuxt.jsと連携させることができました。また動きのおかしいところなどあれば随時追記していきます。

他にもGoogleアカウントのログインなども公式のドキュメントに書かれています。

Nuxt.js+Expressでとにかく簡単にORM

2018-08-10T23:09:11+09:00

Nuxt.jsとExpressを使ってアプリケーションを作るとなると、やはりMySQL等を使うためにORMのライブラリが欲しくなります。Node.jsにはSequelizeというORMのライブラリがあり、それを使って簡単にデータベースを使うことが可能です。

趣旨

Sequelizeの使い方の説明は他のサイトの記事などがもっと参考になります。ただ、とりあえずすぐ簡単に使う、という趣旨の記事があまりなさそうだったのでそのあたりに重点を置いて書いてみます。

ちなみに下記で作ったプロジェクトの続きとして作っています。
Nuxt+Expressのプロジェクト作成で良さそうなのは？

インストール

インストールはマニュアル通りです。npmを使う場合はマニュアルを見てください。

Installation | Sequelize | The node.js ORM for PostgreSQL, MySQL, SQLite and MSSQL

// Using Yarn
$ yarn add sequelize

# And one of the following:
$ yarn add pg pg-hstore
$ yarn add mysql2
$ yarn add sqlite3
$ yarn add tedious // MSSQL

初期化

引き続き上記のマニュアルを見て初期化…ではなく、そこは飛ばして下記の通りにやっていきます。

Tutorial | Sequelize | The node.js ORM for PostgreSQL, MySQL, SQLite and MSSQL

どういうことかというと、最初のリンクの説明どおりに設定していかなくても、Sequelizeにはsequelize-cliというものもあり、それを使えばなんでもかんでもシェルでコマンド実行するだけで簡単にできてしまいます。

インストール

とりあえずはsequelize-cliをインストールします。（npmの場合はマニュアルどおりです）

グローバルにインストールしておけば実行時にパスの指定が必要なくなります。

yarn add sequelize-cli

初期化

下記コマンドで初期化します。

node_modules/.bin/sequelize init

これでなんか必要なファイルを全部作ってくれます。

config/config.jsonというファイルにデータベースへの接続情報設定がありますのでそちらに適宜入力していきます。とりあえず最初に試す時は直接入力してしまってOKです。

時間のある時にでも生成されたmodels/index.jsを見ればわかりますが、config.jsonにuse_env_variableの設定を入れたりすると環境変数から読み込んだりもできるので、コミットしたり本番環境を作ったりする場合はそのあたりが使えると思います。

モデルとマイグレーションファイルを作成する

ORMのため、マイグレーションファイルを作ってデータベースにテーブルを登録できるようにし、モデルを作ってアプリケーション上でデータを操作できるようにします。

これもコマンドで簡単に作成できます。下記は本家に書かれている例です。

node_modules/.bin/sequelize model:generate --name User --attributes firstName:string,lastName:string,email:string

これでマイグレーションファイルとモデルのファイルが作成されます。createdAt, updatedAtというタイムスタンプのカラムも自動的に追加されます。このあたりは--underscoredオプションを付けるとcreated_at, updated_atのようにスネークケースで作成できます。他のフレームワーク等との互換性を考えるのであれば指定しましょう。

マイグレーションを実行

node_modules/.bin/sequelize db:migrate

これで接続情報などが間違っていなければテーブルが作成されているはずです。

ちなみに僕はDBまわりだけdocker-composeを使って用意しています。（もちろんローカル等でデータベースが動いている場合には不要です）

version: '2'
volumes:
  mysql_data:
    driver: local
services:
  mysql:
    image: mysql:8.0
    volumes:
      - mysql_data:/var/lib/mysql
    ports:
      - 3308:3306
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: "true"
  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    environment:
      - PMA_ARBITRARY=1
      - PMA_HOST=mysql
      - PMA_USER=root
      - PMA_PASSWORD=
    ports:
      - 8102:80

よく分からない人はmysqlのバージョンを8ではなく5.6とか5.7にしてください。そうすればhttp://localhost:8102でphpmyadminも使えるので簡単にデータベースが作成できます。動いてすっきりしたあとにでもまた調べてバージョンを上げてみてください。（ヒント：mysql_native_password）

この場合接続設定はこんな感じです。

  "development": {
    "username": "root",
    "password": null,
    "database": "yourdatabse",
    "host": "127.0.0.1",
    "port": "3308",
    "dialect": "mysql"
  },

実際にデータを読み書き

まずはSequelizeの設定を読み込んで使えるようにします。モデルなどは自動的に読み込んでくれるのでこの１文だけでOKです。

const models = require("../models");

../modelsは生成されたmodelsフォルダの位置です。階層が違う場合は適宜書き換えてください。

ちなみにルーティングを別ファイルに分けている場合など、単にrequireしてもモデルがundefinedになっていることがありますので、その場合は最初にアプリケーションにmodelsを登録しておき、アクション内ではリクエストパラメータで取得すると良いです。

app.set("models", require("../models"));

router.post("/posts", async function(req, res, next) {
  const Post = req.app.get("models").Post;

書き込み

書き込み方法はいくつかあるので一例です。

models.User.build({
    first_name: "Hoge",
    last_name: "Fuga"
  })
  .save()

読み込み

こちらも１例です。plain: trueで取得すると単なるオブジェクトとして利用できるようになります。

router.get("/users", async function(req, res, next) {
  const users = await models.User.findAll();

  res.json(
    users.map(user => {
      return user.get({ plain: true });
    })
  );
});

例えばVueコンポーネント側で取得し

  async asyncData() {
    let { users } = await axios.get("/api/users");
    return { users };
  }

受け取ったら下記のような感じで表示できます。上記の様にasyncDataで取っている場合はサーバーサイドレンダリングされています。

      
        {{ user.name }}

まとめ

とりあえずsequelize-cliがあることでかなり初期設定を短縮できています。これがなかったら特にはじめての人とかは結構つまづく箇所が多いのではないかと思います。

他の言語の他のフレームワークと比べてもさほど使い勝手も変わらず良さそうな感じがしました。

追記）TypeScriptで使うTypeORMも触ってみましたので書いておきます。
TypeORMを使ってアプリケーションを作ってみての雑感

Nuxt+Expressのプロジェクト作成で良さそうなのは？

2018-08-10T08:44:38+09:00

Nuxt.jsとExpressで新規プロジェクトを作成する方法をいくつか検証してみました。Nuxt.jsとExpressでアプリケーションを作成すると、SSR（サーバーサイドレンダリング）もデフォルトでやってくれるし、処理もサーバーサイドとフロント側で共通化できたりもして便利です。

どのような作成方法がある？

プロジェクト自体はvue-cliで作成したりすることができます。

基本的な作成方法

Nuxt.jsのマニュアルに紹介されているように、スターターテンプレートがあります。

vue init nuxt-community/starter-template

これで最小限のNuxt.jsプロジェクトを作成することができますので、これにExpressを入れれば作成は可能です。ただ、もっと簡単にExpressを入れたプロジェクトを作成することができます。

Express入りのテンプレートを使う

上記のnuxt-communityの他のリポジトリを見てみると、他にもいくつかテンプレートが用意されています。TypeScript入りのtypescript-template等。その中にexpress-templateもありますので、そちらを使ってプロジェクトを作成することができます。

vue init nuxt-community/express-template

これならもっと簡単にNuxt.js+Expressのプロジェクトを作成することができます。

ただ、これで試してみたところ、どうもExpress側のプログラムを更新してもホットリロードが行われないようで、その度にいちいちサーバーを再起動しなければなりません。ちょっと面倒だったので他のプロジェクト作成方法も探してみました。

追記）現在はメンテナンスされておらず、使うべきでないものもあったりするようです。その都度確認してください。

create-nuxt-appを使う

同じくnuxt-communityのリポジトリに、create-nuxt-appというものがありました。これはNuxt.jsのアプリケーションを作成する際に、構成を自分で選んで作成することができる非常に便利なものです。

nuxt-community/create-nuxt-app: Create Nuxt.js App in seconds.

下記のどちらかのコマンドで作成することができます。（僕はyarnの方は試していません）

npx create-nuxt-app

yarn create nuxt-app

下記の構成を選択することができます。

サーバーサイドのフレームワーク（Express等）
UIフレームワーク（Bootstrap, Bulma等）
axiosを使うか
EsLintを使うか

他にもissueを見るとTypeScriptを使うかも選択できるようにしたい、といった話も出ているので、実装されると嬉しいです。今後にも期待。

これでExpressを選択するとExpressが動作するプロジェクトを作成することができます。しかもこちらはちゃんとNuxt.js側、Express側どちらのプログラムを修正してもちゃんとホットリロードしてくれるようになっています。（正確に言うと、package.jsonのスクリプトのnodemonで--watchを指定しているためです。監視すべきフォルダが複数あるのであれば何度でも--watchを使うことができます）

ためしにexpress-templateに入っているユーザー情報取得処理をコピーしてみました。server/index.jsに下記のような処理を追加して、users.jsを読み込みます。ついでにルーティングも/apiベースにしておきます。

const router = express.Router();
router.use(require("../routes/users"));
app.use("/api", router);

Vueコンポーネント側でも同様に読み込みます。

  async asyncData() {
    let { data } = await axios.get("/api/users");
    return { users: data };
  }

表示も同様です。


  {{ user.name }}

まとめ

今回はとりあえずNuxt.js+Expressで簡単にプロジェクトを作成する触りの部分だけをやってみました。

他にもMySQL接続やTwitter認証等、アプリケーションに必要なものを試しているので、よろしければそちらも御覧ください。

Nuxt.js+Expressで簡単にTwitter認証

Nuxt.js+Expressでとにかく簡単にORM

Nuxt.js+ExpressのプロジェクトをTypeScript化する