サマリー システム構成の変遷 創業フェーズ はじめての API と技術選定 GraphQL 移行直前 GraphQL への移行を決めたきっかけ GraphQL 移行方針 移行期間 ふりかえり 1つ目の方針は正解だった 2つ目の方針は微妙だったかもしれないけど、正解だったかもしれない 3つ目の方針はやはり苦戦した さいごに サマリー サービス開始から3年経った Next.js + Rails なシステム 全ての API を REST から GraphQL にリプレース 約9ヶ月かかりました 早速フロントエンドの都合でバックエンドにも手を入れるということが減って快適です という話です。 システム構成の変遷 創業フェーズ 1人目エンジニアとして入社して、何から手を付けようかなーと考えた結果、事業の肝の部分からシステム化していくことにしました。弊サービス https://moneiro.jp/ は
はじめに Smart Craft テックリードの星井です。 前回の記事で Smart Craft の技術スタックの全体像についてお伝えしましたが、今回はバックエンドについてお話します。 Ruby on Rails / GraphQL な構成になっているので同じような構成を検討している方の参考になれば幸いです。 バックエンドのフレームワーク選定 新しくアプリケーションの開発をやるぞとなったときに、バックエンドで何を使うかというのは毎回頭を悩ませる人が多いのではないでしょうか？ フロントエンドに関しては最近だととりあえず React を使っておけば文句を言う人はいないと言う認識ですが（偏見）、バックエンドはいろいろあって迷いますよね。 自分は Rails 信者でして個人的に何かを作る時には脳死で Rails を採用することが多いですが、Smart Craft でのプロダクト開発は当然そんな安易
Rubyist Hotlinksにインスパイアされて始まったRubyistめぐり。第1回は高橋征義さんをゲストに迎えて、お話を聞きました。こちらは後編です。前編はこちら。 Rubyが他の言語に与えた影響 藤村：第2部、高橋さんについて聞いてみようと思います。今更ながらRubyについて聞きたいんですけど、好きな機能とかありますか？ 高橋：好きな機能ですか？あんまり機能としてこれというのなくて、全体的に使い勝手がいいですね。まあでも、そういう意味でいえばオープンクラスの方がいいんじゃないの？みたいな感じがしますね。オープンクラスじゃないRubyはつらそうだって。 藤村：確かに。 高橋：つらそうというかつまらなさそうですね。オープンクラスが原因でつらいことになるのはわかるんですけど、でもあれがないんだったら他の言語でもいいよね、って。 藤村：Rubyがああじゃなかったら他の言語は今のようになって
はじめに Railsアプリケーションを長く運用していると避けて通れないのがRailsのバージョンアップです。 古いバージョンのRailsは順次サポートの対象から外れていく（＝不具合修正やセキュリティ対応がされなくなる）ため、バージョンアップをせずに運用するわけにはいきません。 そこでこの記事では僕・伊藤淳一がRailsアプリのバージョンをアップグレード（アップデート）する手順を紹介します。 この手順はこれまで何度もRailsアプリケーションをアップグレードしてきた僕の知見が詰まった、いわば「秘伝のタレ」的なアップグレード手順です。 想定するRailsアプリケーション この記事で想定しているのは以下のようなRailsアプリケーションです。 開発者1人でもなんとか面倒が見れるレベルの規模（＝アップグレードは1人で作業する想定） 趣味で作っているのではなく、外部のユーザーがいるRailsアプリ（
こんにちは、id:r7kamura です。業務委託という形で1年ほど関わりながら、美容のクチコミサービスLIPSに利用しているRuby on Rails (以下Rails) というWebアプリケーションフレームワークのバージョンを、4.2から6.1に上げました。 Rails 4.2のリリースは2014年、Rails 6.1のリリースは2020年なので、およそ6年分のバージョンアップを一気に推し進めたことになります。 今回はこれを題材に、この手のフレームワークのバージョンアップ時に起こりがちな諸問題や、やって良かったこと悪かったこと等について振り返ろうと思います。 あまりRailsに限った話はしないように心掛けて書いたので、こういったバージョンアップ作業に興味がある方にはぜひ読んでいってもらえればと思います。 変更の粒度など レビューのやり方 複数データベース対応で困った話 テストがなくて困
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Hotwire: Reactive Rails with no JavaScript? — Martian Chronicles, Evil Martians’ team blog 原文公開日: 2021/04/12 原著者: Vladimir Dementyev -- Evil Martiansリード開発者。 サイト: Evil Martians -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 長文につき前編と後編に分割しました。今回は後編です。 HotwireはRailsを「ゼロJavaScript」でリアクティブにできるか？前編（翻訳） 前編: TurbolinksをTurbo Driveに置き換える 前編: Turb
Hotwire is an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire. This makes for fast first-load pages, keeps template rendering on the server, and allows for a simpler, more productive development experience in any programming language, without sacrificing any of the speed or responsiveness associated with a tradi
「iCARE Dev Meetup #18」�で発表した資料です https://icare.connpass.com/event/201662/
自分が目指したいRailsアプリの形とは何か、ということについて考えていた。 常日頃から考えていたRailsアプリでの不満をこの議論に合流させた結果、「Rubyを書くときに当たり前にやるようなことを、Railsアプリを書くときでも当たり前のようにやる」というところが肝で、自分が目指したいRailsアプリの形はその先にあるのではないか、と一旦結論付けてみることにした。 「普通にRubyでコードを書くときはやらないけど、Railsだったらこう書く」という何かが存在していることが、さまざまな失敗の原因をつくっていると思う。 RubyとRailsが地続きに繋がっていないというか、どこかで断絶があり、そこから筋の悪い設計が生まれている ―あるいは持ち込めるはずの良い設計を持ち込めていない― のではないか、という話。 実際にはどの辺りが気になっているのか？という例を挙げると、氷山の一角を指摘するだけな
2019.08.19 週刊Railsウォッチ（20190819-1/2前編）祝: Rails 6がついにリリース、RailsガイドもRails 6に対応、Arelはpublicだったかほか こんにちは、hachi8833です。休日はトイレの壁紙を剥がして珪藻土を塗り塗りする作業で終わりました。 参考: 【これさえ読めば大丈夫】はじめての漆喰・珪藻土 塗り壁DIY完全ガイド つっつきボイス:「自宅の壁？😆」「冬になるたびにトイレの壁にめちゃくちゃ結露してカビの温床になってました🦠」「構造上結露しちゃう家とかありますよね☺️」「団地ともお的な昭和な団地なので冬場はコンクリから外の冷気がもろに伝わってきます😅」 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついた
先日、Rails 6が正式にリリースされました。 ついにRails 6が正式リリースされたようです！🎉 Rails 6.0: Action Mailbox, Action Text, Multiple DBs, Parallel Testing, Webpacker by default, and Zeitwerk | Riding Rails https://t.co/pHoJb68B97— Junichi Ito (伊藤淳一) (@jnchito) 2019年8月16日 だから、というわけでもないのですが、Rails関連の記事をいくつか書いてQiitaにアップしています。 Railsアプリのアップグレードの手順 1つ目はRailsアプリのアップグレード（バージョンアップ）の手順です。 永久保存版！？伊藤さん式・Railsアプリのアップグレード手順 - Qiita qiita.com
Rails 6.0: Action Mailbox, Action Text, Multiple DBs, Parallel Testing, Webpacker by default, and Zeitwerk Dealing with incoming email, composing rich-text content, connecting to multiple databases, parallelizing test runs, integrating JavaScript with love, and rewriting the code loader. These are fundamental improvements to the fundamentals of working with the web and building fast and fresh appl
はじめまして。2019年4月から妊娠・出産アプリ『Babyプラス』の開発チームにJOINした濱田です。 『Babyプラス』のバックエンドはRailsで実装されているのですが、とあるCSV生成処理がとても遅かったので100倍以上に高速化しました。この過程でRailsアプリの処理高速化に関する以下の知見が得られたので、具体例を交えて共有します。この知見は、ActiveRecordを使用してMySQLなどのRDBMSからデータ抽出をする様々な場面で活用できると思います。 いわゆる「N+1問題」を起こさないのは基本 「ActiveRecordインスタンスの生成コスト」はそれなりに高い pluckはjoinsと組み合わせることで他テーブルのカラム値も取得できる 前提: DBスキーマとデータ規模 今回の処理高速化に関わるモデルのDBスキーマとデータ規模は以下の通りです。なお、これらは本エントリ向けに少
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く