@ro-ze1106 (tomo)

Are you sure you want to delete the question?

If your question is resolved, you may close it.

Leaving a resolved question undeleted may help others!

We hope you find it useful!

SPA開発 本番環境構築について

初学者です。
今は環境構築の段階です。
ReactとRailsでSPAのアプリをAWSで本番環境を構築しようと思っています。
私は、Railsのアプリで本番環境をAWSに構築したことがありますが、
SPAのようなフロントエンドとバックエンドを分けたAWSの本番環境の構築はしたことがありません。
アプリの機能は本番環境をAWSで構築してから開発しようと思っています。
SPAのアプリをAWSで本番環境を構築する方法を色々と調べてましたが、
分かりやすい記事を見つけられずに困っています。
分かりやすい記事やその他のアドバイスがあれば、
ご回答いただければ幸いです。
よろしくお願いします。

0 likes

Rails(graphqlサーバー) + React(Next.js)での自分の経験からだと

Railsを公開URLで運用する場合

  • http://backend... でアクセスできる
  • http://frontend... でアクセスできる
  • Reactがbackendのgraphqlにクライアント側からとしてアクセスしデータを取る

扱っているデータがどこまでプライベートなものなのかによりますが、この場合だとログイン認証をする場合(cookieを使用するとして)、frontendとbackendのドメインによってはなかなかややこしい状況になります。
同じドメインで、サブドメイン違いならそこまでややこしくありませんが、全く別のドメイン同士などではそれなりの設定が必要になります。

ユーザー → ブラウザ → React → Graphqlクライアント → Rails(Graphqlサーバー) → データベース → レスポンス → ブラウザに表示

Railsを公開URLで運用しない場合

  • クライアント側からは http://backend... でアクセス出来ない
  • http://frontend... でアクセスできる
  • React(Next.js)のapi routesを使って、Next.jsのサーバー側でbackendのgraphqlにローカルサーバー同士としてアクセスしデータを取る

この場合だとログイン認証(cookieの管理)はNext.jsだけで出来るので、一般的な処理でクライアント側からNext.jsのサーバー側(api routes側)にcookieが渡せて、検証確認後にapi routes内でローカルとしてのbackendのgraphqlサーバーに接続して..みたいに出来ます。
が、一方バケツリレーが1つ増えます。

ユーザー → ブラウザ → React(Next.js)fetchなどで → Next.jsサーバー側(api routes)Graphqlクライアント → Rails(Graphqlサーバー) → データベース → レスポンス → Next.jsサーバー側(api routes)からデータをそのまま転送 → ブラウザに表示

クライアントとGraphqlサーバー間にNext.jsサーバー側が間に挟まるので、ここがデータを双方向に転送しないといけなくなります。

あくまでもReactとRailsでという事なので、そうでない場合は全てをjavascriptでやってしまって、サーバー側とよりシームレスにする方法もあると思います(javascriptのgraphqlサーバーだとか、データ管理はfirebaseでやってしまうとか)。

0Like

ご回答ありがとうございます。
Railsを公開URLで運用しない場合で構築した場合に
バックエンド側のwebサーバーをnginxで
アプリケーションサーバーはpumaで
フロントエンド側のwebサーバーやアプリケーションサーバーは
どういったものを使用すればよいですか?

0Like

「Railsを公開URLで運用しない」という事なので、自分の構成だと

  • docker-composeを使う
  • frontendはNext.js
  • backendはRails(Graphqlサーバー)
  • もちろんデータベースもdocker内
  • 更にcaddyを使う、docker内で
  • caddyが実質唯一の公開サーバー
  • caddyが http://yourdomain.com で待っておき、リクエストがあったらfrontendにリバースプロキシでそのまま転送する

みたいな感じです。

クライアント → http://... → caddy → frontend → backend → database → レスポンス

という流れかなと。

1Like

同じように全てはdockerでやりますが、

frontend

クライアント → caddy → frontend

backend

クライアント → caddy → backend → database → レスポンス

となるだけですが、ログイン認証などをcookieでやる場合は、

  • 同一ドメインで構成するのか
  • サブドメインで構成するのか
  • 全くの別ドメインで構成するのか

等々で色々工作をしないといけないと思います。

1Like

ご回答ありがとうございます。
今さらですが、初めからAWSで
本番環境構築した方がよいですか?
それとも他の無料のPassを使用して
本番環境構築し、ある程度アプリが完成してからAWSに切り替えた方がよいですか?

0Like

手間

当たり前ですが、プラットフォームによってデプロイ手順がそれなりに違うので、手間だけを考えると最初からAWSのほうが無駄な学習コストはかかりません

料金

料金面では、S3およびCloudFrontにも無料枠があり、AWSアカウントを作成して1年以内であれば大部分が無料になりますし、無料枠が使えなくても本格稼働前であればせいぜい毎月100円もいかないはずですのであまり気にしなくて良いかと思います

参考)
s3料金表
AWS無料枠

少し複雑な料金構成ですが、よく見るとどの料金種別も相当使い込まないと大した金額にならないことが分かります

学習面

ただし、そもそも「最終的に絶対AWS」と決めていない、あるいは決める必要がない(クロスプラットフォーム構成など)のであれば、今の段階でいくつかのプラットフォームを試してみてデプロイ体験を学習してみるのは良い方法だと思います
使ってみると気が変わる、ということもよくありますし

また最終的にAWSと決まっていても、今後根拠をもってクラウドサービス技術選定をできるようになっていきたいのであれば、いくつか試しておくと
「firebaseはこれこれが使いにくいからNetlifyにしよう」
「AWSは好きだけどS3が使いにくいから、そもそもGCPベースで全部構築しよう」
などといった判断ができるようになるかもしれません

ご自身の今の時間的/気持ち的余裕を鑑みてご判断ください

1Like

ご回答ありがとうございます。
特に学習面のアドバイスは今後色々な面で参考にさせていただきます。

0Like

Your answer might help someone💌