なぜ我々はRailsを選択したのか？Smart Craftバックエンドのご紹介

はじめに Smart Craft テックリードの星井です。 前回の記事で Smart Craft の技術スタックの全体像についてお伝えしましたが、今回はバックエンドについてお話します。 Ruby on Rails / GraphQL な構成になっているので同じような構成を検討している方の参考になれば幸いです。 バックエンドのフレームワーク選定 新しくアプリケーションの開発をやるぞとなったときに、バックエンドで何を使うかというのは毎回頭を悩ませる人が多いのではないでしょうか？ フロントエンドに関しては最近だととりあえず React を使っておけば文句を言う人はいないと言う認識ですが（偏見）、バックエンドはいろいろあって迷いますよね。 自分は Rails 信者でして個人的に何かを作る時には脳死で Rails を採用することが多いですが、Smart Craft でのプロダクト開発は当然そんな安易

[takeag]

型が無いことで他に辛いのは可読性かな。初見でコード読んだとき、型が無いと各処理を追わないと、何が渡ってきてんのか分からないのが辛いし怖い。言語選択時には使い捨てシステム以外では型は必須レベル

[YassLab]

"Convention over Configuration(設定より規約)の原則に則ったフレームワークとしてのデザインによって私達が書かなければいけないコードの行数は少なくて済むケースが多いと感じています。そして我々はより業務ロジックに集中"

[Derabon]

開発初期の効率の良さはわかるが、それなりに息の長いサービスになると、やっぱり型欲しいよねー、というのを何度も見てきている。

[dorokei]

なぜHotwireを採用しないのだ

[earu]

技術選定の参考になる

[kabuakantech]

RailsはORマッピングがとにかく偉大で開発工数の削減に寄与できるのだけど、それ以外に欠点が多いのがつらい

[shingo-sasaki-0529]

インタフェース周りの型は GraphQL でスキーマ駆動でバリデーションまで自動でできるって考えると、型の無さの問題は結構解決できるものなのかな。

[strawberryhunter]

GraphQLはコミュニケーションコストの削減のために実行時にコストを払って解決するという、とても経済従属的なもの。そのアプローチにロマンを感じないので弊社ではナシだよねって理屈を今整理した。

[uzuki05]

“Rails の品質が開発者の経験やセンスに依存してしまう” “Rails は難しい（簡単な様に見えて）けれども、うまく使うことができれば効率よく堅牢なアプリケーションが実装できる”

[hate_nao]

Rails Tutorialまたやってみようかな

[diveintounlimit]

GraphQL＝モダン、GraphQL使えばだいたい解決みたいな思考は同意しかねる

[bake0937]

私ではなかなか言語できない要素を上手く言語してまとめられていてホントすごいと思いました!