XtoneでのWebサービス構築時の技術選定

エクストーンの豊田です。エクストーンでも技術ブログを始めることになりました。最初なのでエクストーンでの普段の業務と採用している技術等についてお話ししたいと思います。

エクストーンでは主にウェブサイトならびにiOS、Android向けのアプリの開発を行っています。受注開発が中心ですが、エンジニアも含めてよりよいアプリケーションを作成するためにはどうすればいいかを様々な観点で提案・実装をさせていただいています。その中でどのような技術スタックを利用してサービスを構築するか等も含め、エクストーンで決めることがほとんどです。どのような案件かによって採用する技術スタックは変わってきますが、よく採用している技術についてここで紹介していきたいと思います。

Web開発で主に利用している技術スタック

  • プログラミング言語 / フレームワーク
    • Frontend
      • TypeScript, React, Next.js, Vue.js, Nuxt.js
    • Backend
      • Ruby, Ruby on Rails, TypeScript, express
  • アプリケーションの実行環境
    • AWS
      • EC2, Lambda, ECS Fargate
    • Google Cloud
      • Cloud Functions (Firebase Functions含む), Cloud Run
    • その他
      • Heroku, Vercel
  • データベース
    • RDBMS
      • MySQL, PostgreSQL
    • NoSQL
      • AWS Dynamo, firestore
    • キャッシュDB
      • redis, memcached
    • 全文検索
      • ElasticSearch, Algolia
    • Others
      • BigQuery
    • ファイルストレージ
      • AWS S3, Google Cloud Storage
  • コンテンツ配信
    • AWS CloudFront, Google Cloud CDN, Cloudinary
  • 認証
    • AWS Cognito, GCP Identity Platform, Firebase Authentication, Auth0

この記事では、メインで主に採用しているアプリケーションフレームワーク(Ruby on Rails, Next.js)について、何故それを利用するようになったのか等のお話をしたいと思います。

Ruby on Rails

エクストーンでは2012年頃からWebアプリケーションの構築にRuby on Railsを利用しています。採用当初はフロントエンドからバックエンドまで全ての役割を担当していましたが、近年ではフロントエンドを切り離すことが多く、主にAPI開発に利用しています。 Ruby on Railsを当初採用した理由としてはrspecの存在がありました。当時、どのように開発者が自然にテストコードを書く習慣をつけられるかということにチャレンジしており、様々なテストフレームワークを試したところ、Ruby on Rails + rspecという組み合わせが比較的楽にテストを記述できたため、そのまま全社的にRuby on Railsをメインの開発環境とする選択を行いました。以降、飛躍的にテストコードが書かれる割合が上がり、現在では「あるといいね」から「あって当たり前」という水準まで社内のテスト文化を引き上げることに成功しました。

rspecではモック・スタブの記述や、RDBMSにテスト事前データの準備(エクストーンではfactory-botを利用)が容易に行えるため、様々な状況においてテストの記載に悩むことが少なく、状況に合わせて最適なテストを記載しやすいです。

他にも、Ruby on Railsを採用することで、エンジニアのモデリング能力を成長させることが出来ました。DBのモデリングやRESTful APIの設計など、いわゆるRails wayに沿った開発を行うことでよりよい設計になることが多く、リソースの情報をそのままコードにマッピング出来るため、設計がうまくいくとコードも綺麗になることが多いです。このあたりの話は長くなるので、また別記事等でお話しできる機会があるといいかなと思っています。

Next.js

近年のフロントエンドの複雑化に伴い、フロントエンド用のフレームワークを別途採用することがここ5年くらいで増えてきています。過去にはjQuery、Backbone.jsから始まり、Vue.jsやReactなどのバーチャルDOMを利用したフレームワークを、採用することが多くなっています。特に大規模なプロジェクトに関してはReact + Next.jsを利用することが多いです。

最初にNext.jsを採用した理由は「シングルページアプリケーションにおいて簡単にサーバーサイドレンダリングをしたい」というシンプルな理由でした。具体的にはTwitterやFacebookなどのSNSでとあるページのURLが共有された際、Open Graph Protocolによってそのページの詳細や画像を表示させたいという要求がありました。しかし、TwitterやFacebookのクローラーはJavaScriptを解釈してくれないため、JavaScriptの実行によってDOMを生成するシングルページアプリケーションと相性が悪いです。ページの概要や画像はHTMLのmetaタグによって記述されますが、動的に生成されたmetaタグをTwitterやFacebookのbotは理解することが出来ません。そのため、JavaScriptによってではなく、サーバーサイド側であらかじめHTMLをレンダリングしておく必要があります。

Next.jsでは暗黙的なサーバーサイドレンダリングが可能で、最初のステートによってレンダリング可能な部分に関してはサーバー側でレンダリングした上でブラウザに返すようになっています。そのためAPI等からのデータフェッチ部分のみを明示的にサーバーサイドで行うようにし、そのステートをフロント側に渡すことで、Reactの部分では何も考えずにmetaタグのサーバーサイドレンダリングが可能になります。

デザインフレームワークについてはまだエクストーン内でこれを使う、という決まったものは無く、案件毎に選定をしている状態ですが、コンポーネントのデザイン定義にstorybookを採用することが増えています。デザイナーとデザインのやりとりをする際にパーツリストを作成することが多いのですが、storybookを利用することでパーツリストとコンポーネントの見た目の実装が合わせて行われるため、トータルのコストが減少することが期待できます。

その他、Next.jsにはBFF(Backend for Frontend)の役割を期待します。自前で用意するAPI以外にも、例えば認証管理用のIDaaSであったり、その他の外部サービスだったりを利用するに当たって、Next.jsのサーバーサイド側で抽象化し、バックエンドの異なるサービスを意識せずに利用できるようにすることが目的です。これによりフロントエンド側はバックエンドの実装を気にすること無く、BFFによって定義されたAPIのみ知っていればよいという状況を作ることが出来ます。

おわりに

今回は1回目ということで、エクストーンで利用しているサーバーサイドの技術選定とその採用のきっかけをお話しさせていただきました。各フレームワークに期待するものはここに記載したもの以上のものがまだまだあるのですが、それについてはまた今後の記事で紹介できればと思っています。

同様のテーマでアプリについてやインフラについても近いうちに記事に出来れば思っています。