DynamoDBとの接続でlaravel-dynamodbを使ってみた感想

DynamoDBとの接続でlaravel-dynamodbを使ってみた感想

DynamoDBとの接続でlaravel-dynamodbを使ってみた感想

laravel-dynamodについて簡単にまとめます。

  • dynamodb-localもコンパイルされたある意味完成されたDockerが存在している
  • 勉強用資料としてはとても優れている
  • とりあえず試すには最適(これ以上の解はない)
  • 本番環境で利用するにはdynamodb-localの切り離しが必要だがここが心配になるスクリプト構成をしている

個人的な感想でしかありませんが、私はこの様に感じました。
laravelがバックエンドの本番環境で実装するならAWS-SDK-for-PHPAWS-SDK-for-JavaScriptの2択だと思います。

Laravel-dynamodbのスゴイところ

  • インストールが超楽/超早
  • NoSQLに抵抗があってもそれを打ち消してくれるEloquent Likeな抽出文

最初のハードルはテーブルを作成するところになります。
テーブルを作成してしまった後は、正直言ってもうLaravelEloquentです。
それくらい抵抗なく抽出文を記載できます。

これですから。Eloquent likeでしょ。
入口としては入りやすいですが、それ故に 「noSQLってなんだったっけ ?」 と思ってしまうところもあります。

aws-sdk-for-phpだとこんな感じで書く様です。(抽出条件の内容は異なります。)

比べるとよく分かりますよね、圧倒的な書きやすさが。

Laravel-dynamodbのツライところ

今回の環境では、SES先の社長より「これでいいんじゃね?」とlaravel-dynamodbをプッシュされて居た事もありコイツいで行くつもりでした。が、テスト用のAWS上のDynamoDBにアクセスしてみて「???」と思うコードが点在していました。

【作りやすい環境で構築してバグとり】<【公式提供な環境で実装し初期バグを減らす】

その結果として、この様な判断に至り、AWS-SDKでの開発が確定しました。

Laravel-dynamodbで散見した課題

私がGitHubから最初のコードを取得したのも問題だと思います。
このコードの中には、configなどにハードコートされたパートが複数ありました。
結果として「.envを修正したのに何も変わらない」という状況を引き起こし「バグが出た時に探すコストが大変」との判断が降りました。

具体的にはこんなところです。

■.env.php

■config/aws.php

■docker-compose.yml

1箇所修正しても他がハードコートされているので動かない。
「完全に動かない」ならまだ良いが、「まれに動かない」となった場合には問題箇所の確認作業にコストと時間がかかる可能性がある。
=> 本番環境の構築について、あえて選ぶ必要はない。

まとめ

dynamodb-localを利用した環境をあっという間に構築でき、ORMで簡単に記載ができる。
入口としてはもう最高のツールだと思います。

課題は実際に運用するとなるとどう判断するかに尽きます。
今回参画しているプロジェクトでは私から「やめましょう」と伝えました。

そもそも、バックエンドがDynamoDBに直接繋いでやりとりするメリットって固定な4つのカラムで検索するくらいしかありません。
Lamdba使っていじったデータをAPIで受け取った方が遥かに効率が良いと思います。
事情によりLambdaの利用ができない場合の代替手段程度に思っていれば、まぁそこそこ使える道具。

それがlaravel-dynamodbの立場だと思います。超絶書きやすいんですけどね。