Ruby on Jetsでハマったこと

土居です。本日ははじめてRuby on Jetsを利用していて、ハマった点を紹介したいと思います。

Ruby on Jets とは

Rubyのサーバーレスフレームワークです。Rubyで書かれたアプリケーションをAWS Lambdaにデプロイし、Amazon API GatewayでLambdaへルーティングするURLエンドポイントを生成します。

Ruby on Railsと同様の記法で記述でき、利用できるコマンドも同様の物が多いので、経験者はスムーズに利用できるのではないでしょうか。

一方、ハマった点もありました。とくに開発中にローカルサーバーにおいて実行している状態では意図した通りに動いていたのが、サーバーレス環境へデプロイすると動かなくなる場合があります。

デプロイコマンドへのAWS Credentialsの渡し方

Lambdaには予約済み環境変数があり、それに含まれる変数をあらかじめCI実行時に渡すなどしている場合、以下のようなエラーとなります。

Building CloudFormation templates.
You have configured some environment variables that are reserved by AWS Lambda.

AWS_ACCESS_KEY_ID
AWS_REGION
AWS_SECRET_ACCESS_KEY

The deployment to AWS Lambda will failed when using reserved variables.
Please remove these reserved variables.

AWS credentialsは~/.aws/credentialsにあらかじめ記載しておくことで対処できます。

[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

また、jets deployコマンドの実行時に同時に渡してもOKです。

リソースのネスト

Jets.application.routes.draw do
  resources :customers do
    resources :projects do
      resources :billings do
      end
    end
  end

このようにconfig/routes.rbにネストしたリソースを定義しているとローカルでは問題なくルーティングされていたのですが、
デプロイしようとすると三階層目のルーティングの生成で失敗してしまいました。二階層目まででないと、API Gatewayの生成がうまくいかないようです。三階層目はネストせずに、直接記述することで対処しました。

RailsにあってJetsでは動作しない機能

i18nがJetsでは動作しないため、エラーメッセージの内容を日本語化したかった時に、errors.addを用いてエラーメッセージを直接変更してやる必要がありました。
他にも、rails-ujsの機能(viewのdata-methodなど)がデプロイ環境では効いていないようでした。

まとめ

いくつかハマった点はありましたが、ほぼRailsの感覚で書け、シンプルで使いやすいと感じました。Railsと異なる点を押さえ、どのように代替できるかを学んで活用していければと思います。

参考

公式
GitHub