このステージのパスは省略ができません。そのため、1階層下がる前提で考える必要があります。リソースのパスはルートパス(/assets/app.jsのような書き方)で出力されます。このままだとhttps://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/assets/app.jsを参照してしまいリソースを取得できません。設定してあげる必要があります。href="/dev/">が追加されます。パスがルートパスで指定されていたとしてもhttps://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/assets/app.jsを参照するようになります。プロパティで行えます。設定しないようなコードになっています。関しての対応は不要な場合もあるようです。かかっていると表示されません。機能を使う必要はないでしょう。機能が備わっています。ありがたい機能ではあるのですが、このままだとブラウザで表示できなくなってしまいます。機能が備わっているようです。かかった状態になってしまい、ブラウザがデコードできないのだと推測されます。Nuxt.js)を見てみると独自のミドルウェアを定義できるようです。コードを覗いてみると関数を設定させると独自のミドルウェアを定義できるみたいです。プロパティで設定できます。以上がフロントエンド側のコードです。aws-serverless-expressを提供しているからです。コードの実行に関しての説明を少しだけしておきます。イベントがトリガーとなり実行される仕組みになっています。コードはハンドラーを用意するような形になります。コードを書く場合は、ハンドラーとメインの処理が書かれたコードを分けるようにしています。分ける理由はローカルでメインの処理だけローカルで実行して動作確認をしたり、テストをやりやすくするためです。今回も同様にハンドラーであるhander.jsとメインの処理であるapp.jsに分けて記述しています。それぞれについて書いていきます。ハンドラーハンドラーの方は短いです。関数にハンドラー関数の引数を渡しているだけです。インスタンスを生成しています。動かす場合はnuxt.renderを使います。関係で、リクエストのパスを変えてあげる必要があります。値が渡るときにステージのパスである/dev/が渡ってきません。そのためnuxt.render関数にに渡る前に/dev/を付加してあげる必要があります。※/dev/が入っているBASE_URLは環境変数として定義していて、process.envから取得させています。※環境変数はserverless.ymlで設定しています。ミドルウェアに分けました。サーバーが立ち上がるようにも変更を加えました。フォルダーの構成は次のようになります。ミドルウェアは登録した順に処理を実行し、次のミドルウェアに渡していくような役割を持っています。つの役割を持たせて処理を分割しました。中身に関してはそれぞれ大したことはしていないのでサンプルコードの方をご覧ください。メソッドを呼ぶ必要があるようです。このコードからapp.use(nuxt.render);このコードに更新しました。next);});以上がサーバー側のコードです。まとめ盛りなだくさんになってしまいました。問題児に見えてしまっているかもしれません。サーバーとして使うことに特化しているわけではありません。めんどうな手間も仕方ないことだと割り切りましょう。カスタムドメインを使うことでめんどうな手間もほぼ解消できます。前に置くことでカスタムドメインを設定することもできます。この話は理想の話として補足に書いています)一応サンプルではカスタムドメインを使用することも考慮して、次のコマンドを用意しています。設定されなくなります。カスタムドメインを設定する前提の場合はこちらのコマンドを利用してください。deployのコマンドは理想の話のデプロイができるようなコマンドに更新されました。カスタムドメインを使う場合は理想の話の構成を参考にされてください。今回はここでいったん終わりにします。明日はsunecosuriさんです。Qiitaクリック時に範囲選択するコンポーネントは便利だなと思いました。このサイトでのコードのコピーとかに応用できたらなと思います。下に補足として、色々書いてるのでよかったら見てください。補足ここからは補足的な内容になってます。年近くたったので、運用のノウハウを追記しておきます。いってもノウハウはほぼありません。関連するコードの変更は行っていません。サーバーレスのメリットを存分に受けていると言えそうです。メリットだけということもありません。起動が遅いこともあります。実行を監視していると極稀にですがレスポンスを返すのに数十秒かかるケースがあるようです。タイムアウト時は静的ページを返すようにしておくのがベストだと思います。トライアル期間しか使っていなかったのですが、実行時間や実行回数などのデータが連携するだけで可視化されるようになったのでとても便利でした。利用することもできると思います。筆者は利用を始めていませんが、時間があるときのタスクに積んでいます。メモリは可動するサーバーにも影響します。高ければ高いほどスペックの良いサーバーで稼働します。ここは色々試してみてサービスに最適なところを探すのがよいでしょう。置いていると思います。キャッシュを参照することになるので、低めに設定しておいてもけっこうなんとかなります。最後にキャッシュのお話です。キャッシュは運用を間違えると情報漏えいに繋がり兼ねないので設定は慎重に行うべきです。設定するものを追加しています。簡単にですが次のようなものです。以下はユーザーの設定ページなど)。cacheMiddleware}他にもなにかノウハウ的なものが見つかれば追記していこうと思います。先に全体像となる構成図から。サービスのそれぞれの役割は次のようになってます。キャッシュ機能は高いなぜか時間単位で課金されてしまうこのような理由から上記のような構成図になります。実際に実務でのプロジェクトでは上記のような構成になっています。冒頭にも書きましたが、この話を同人誌として出してました。販売しているのでご興味ある方はそちらをご参照ください。載ってるので、気になるものがありましたらご購入いただけると嬉しいです。制限が関連してきます。ファイル)は50MBとなっています。