Routerが統合されました。3での開発体制に不満はありませんでしたが、フレームワークがバージョンアップしたことにより、インターネット上の情報がどんどん最新版のものに入れ替わっていくことや、フレームワーク自体の性能が上がっていくことを見越して早めにアップデートすることにしました。ビジネスロジックは基本的に変更せず移行することができましたが、やはりルーティングに関する部分はほぼ書き直しとなりました。3で次のページにパラメタを渡して遷移していたところが、URL経由でIDしか渡さないようにしたため、次のページでもバックエンドと通信して情報を手に入れる処理を追加する作業も行いました。各画面にURLが割り振られたことで、画面遷移の実装がとてもシンプルになったり、利用状況の収集がWebのようにやれるようになったりしました。Androidアプリ化するためのフレームワークとしてCordovaを使っていましたが、これまた2019年に正式リリースされたCapacitorに変更しました。Capacitorでは、Cordova環境ではやりづらかったプラグインのGit管理が一番魅力的に感じています。ドキュメントも豊富で、今の所困ったことはありません。Railsを動かしていました。この体制だと次のような課題がありました。・ユーザー数が増えたときに各サーバーが耐えられない可能性がある(当時オートスケーリングの設定はしていなかった)・どのような使われ方をするか分からず、必要以上のリソースを確保し続けることによってコストパフォーマンスが悪くなる・インフラの設定がコード管理されておらず、サーバーの設定が秘伝のタレ化している・ステージング環境が常時起動している必要があり、無駄なコストがかかっているどの課題についても、Docker化したり、オートスケーリングを組んだりすることで対応可能な課題ではあります。それ自体の設計もかなり大変で、かつノウハウが求められる作業に思えました。そんなときに出会ったサーバーレスはまさにイメージ通りのアーキテクチャーでした。RailsからAWSサーバーレスに移行するため、次のようなことを学びつつ一気に開発を進めていきました。・CI/CDパイプラインの構築方法もちろん初めて触れる技術ばかりだったので、ちょっとしたことで数時間悩み続けることは多々ありました。AppSyncのE2Eテストも書き始めました。Railsではフロントエンドもバックエンドのプロジェクトと密結合で開発することが多いですが、AWSサーバーレスにすると基本バックエンドはAPIの提供のみが役割になります。テストの設計がやりやすくなると感じたので、このタイミングでしっかりテストを書いていくことにしました。Chaiを使いました(今は紆余曲折あってJESTに落ち着きました)。テストも正直あまり書いたことがなく、RSpecでちょっとしたモデルのユニットテストをした程度の知識しかありませんでした。E2Eテストを書きました。最終的なテスト体制の構築や実装は他のエンジニアに一任して進めて、現時点では100件ほどのテストがCIで自動的に回るような体制まで持ってくることができました。挑戦しかしていない2019年でしたAWSサーバーレスバックエンドを構築してある程度経った今思うことは、よく挑戦したなぁということです。若手のスタートアップ等で、技術力はまだこれから伸ばしていくフェーズだというチームにこの構成はおすすめはしないかもしれません。Railsをやっていた頃に比べて圧倒的に情報が少なく、かつAWSに関する深い知識が必要になってくるアーキテクチャーだと思います。必死の思いで確保したスケーラビリティを活かし切れるよう、どんどんフロントエンドのアプリケーションを開発して行けたらと思います。ダウンロード#スタートアップ#CTOこの記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。サポートをする「スキ」を押してクリエイターを応援しよう!4いとうてつしEngineering&Design/組織づくり/自分の中のモヤモヤを強みに変えていくためにアウトプットします。CTOとして2019年に取り組んだこと【採用活動編】2いとうてつしデザイン思考でWebアプリの仕様書を改善してみた話。クリエイターへのお問合せnoteカイゼン目安箱クリエイターの。