HotwireとNext.jsをちゃんと見て比較しよう#本サイトでは、React/Next.jsに詳しいフロントエンドエンジニアを対象に、実際に動くコードと実際に動くデモを体感しながら HotwireとReact/Next.jsを比較します。 各技術でのUIの作り方を伝えるだけでなく、さまざまな状況での動きを確認していただくために、仕組みや限界も紹介します。そのため、かなり細部の議論もしています。 HotwireでもNext.jsと同等か、それ以上のUI/UXが実現できます。「Hotwireは簡単だけど、React/Next.jsの方が優れたUI/UXが作れる」というのは、かなり特殊なものでない限りは誤解ですHotwireはバックエンド非依存です。Rails, Laravel, Django, Go, Nodeでも関係なく動きます。実際、本サイトのHotwireコードはNext.js AP
GMOアドマーケティングの吉岡です。 今回の記事ではRails 7で追加されたHotwireという技術について、何が良いのか?どんなことができるのか?を話したいと思います。 Hotwireとは? 大量のJavaScriptを使わずに、モダンなWebアプリケーションを作るためのアプローチ JSONではなくHTMLベース サーバーサイドでHTMLを生成し、WebSocketでWebブラウザへ送信 構成する主な要素 Turbo Stimulus Hotwireを使うと何が良いのか? Rails6以前の環境 最新バージョンのjs(ES6)を使いたい →主要なブラウザが対応していないため、ブラウザで動作するES5にトランスパイルする必要がある そのために必要なパッケージとその役割 node.js ES6のjsをサーバー側で解釈するために必要 ES6のjsをES5にトランスパイルするため、node.j
Firebase Authentication を使う場合、ユーザーモデルとテストはどうする? Rails で個人用の英単語帳アプリを開発しています。開発環境は Rails 7.0.4 + Ruby 3.1.2 です。 ユーザ認証に Firebase Authentication を導入すると、フォームに入力した email と password を Firebase Authentication API に渡して返り値を受け取るだけで認証が実装できます。認証のためにユーザーモデルを作成する必要はありません。 ただし、ユーザごとのデータを保存するテーブルの関連付けとしてユーザーモデルは必要になります。私の場合、英単語帳を flaschcards というテーブルに保存しているため、「誰が登録した英単語か」を識別するためにユーザーモデルを作成することにしました。ユーザーを作成するために外部の
『Sustainable Web Development with Ruby on Rails』はRails使ってるなら絶対面白いと思う David Bryant Copelandの『Sustainable Web Development with Ruby on Rails』を読んでいますが、この本めちゃめちゃ面白いですね。 Railsの設計で悩んだことのある人なら絶対読んで損はないというか、共感したり反発したりにやにやしたりで楽しめると思います。RailsというかWebアプリ開発の歴戦の勇士(正直あまり若くなく、つらい経験を重ねてきた生き残り的な人)が語るベストプラクティス感があります。 本書の構成 大きく3部構成です。 Introduction その名の通り導入です。本書の目的、Railsのアーキテクチャの紹介と、ビジネスロジックの話など。 「Sustainable」とは何か? とい
Caution この記事はDHHファンの妄想によるシナリオが多分に含まれます。 というかほとんどです。 成り立ちが間違ってることも当然あるように思うので話半分で読んでください。 これは一体 最近のRailsフロントエンドやDHHの活動には一連の流れがあるわけですが、一部トレンドに沿ってない部分がある故にそれが汲めないというところがあるのではと思います。 それらの流れを記憶が定かなうちにつないで記録しておこうという記事です。 前提知識 Railsの生みの親、Rubyist Basecamp(社) DHHがCTOやってる会社 Basecamp(サービス) Basecamp(社)が開発してるプロジェクト管理ツール Trixを開発してたある日 Basecamp(サービス)に組み込まれてるリッチテキストエディタのtrixをcustomElements使って開発してたある日、DHHはあることに気づく。
September 24, 2021 Stimulus 3 + Turbo 7 = Hotwire 1.0 For so long, it felt like I could only tell half the story of how we make software for the web at Basecamp. Too many of the chapters about our front-end approach were missing key pages. Sure, we had some of it out there. Turbolinks, for example, hark back to 2012, when I was inspired by Chris Wanstrath's ideas in pjax, and took them further. An
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: 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のスポンサーでもあります。 長文につき前編と後編に分割しました。 サマリー The HEY stack: - Vanilla Ruby on Rails on the backend, running on edge - Stimulus, Turbolink
事業成長を加速させたエンジニアリングのウラ側 https://medpeer.connpass.com/event/211745/
CTO室SREの@sinsokuです。 Dockerイメージのビルドを高速化するため、試行錯誤して分かった知見などをまとめて紹介します。 AWSのインフラ構成 assetsもECSから配信し、CloudFrontで /assets と /packs をキャッシュする構成になっています。 Rails on ECS デプロイ時にassetsが404になる問題 以前の記事に詳細が書かれているため、ここでは問題の紹介だけしておきます。 Rails等のassetsファイルをハッシュ付きで生成し配信するWebアプリケーションの場合、ローリングアップデートを行うと、アップデート時に404エラーが確立で発生してしまいます。 引用: メドピアのECSデプロイ方法の変遷 Dockerfile 実際のDockerfileには業務上のコード、歴史的な残骸などが含まれていたので、綺麗なDockerfileを用意しま
はじめに こんにちは、サーバーサイドエンジニアの@hokitaです。 この記事は Enigmo Advent Calendar 2020 の 16 日目の記事です。 弊社が運営するBUYMAは現状モノレポで管理されており、10年以上も運営しているサービスなのでソースも肥大化していて、メンテナンスが難しくなってきました。 そこで現在、本体から少しずつマイクロサービスに切り離していこうとしています。 その取組の中で配送処理の一部をマイクロサービス化する作業に携わることができました。今回はBUYMA本体と配送サービスとの通信にイベント駆動アーキテクチャを導入した話をしていきます。 イベント駆動アーキテクチャ マイクロサービスでサービスを切り分ける場合、それぞれ責務が分かれるように分割するかと思います。 しかしサービス間の通信手段によっては各サービスが密になる恐れがあります。 そこでイベント駆動ア
この文書は、ある組織において、ある一つの Ruby on Rails で書かれたサービスの全部または一部を、(言語A) で書き直したい、という proposal に対して qsona が表明した意見の文を、一部手直ししたものです。このサービスは、現在担当しているチームとは別の人が初期実装をしたものであり、現在はまだ小規模ですが、今後新しいチームの手により発展していくもので、現在の規模のうちに要件や新しいチームメンバーに最適な言語で書き直すという選択は十分合理的です。また、この組織内のコードは、Ruby on Rails で書かれているものが大半であり、さらに組織としてマイクロサービスアーキテクチャの方向を目指している、という前提の上でお読みいただければと思います。もちろん文責は qsona 個人にあり、qsona の属する組織の意見とは関係ありません。 ------------------
passwordless という gem が最近リリースされたようなので少し触ってみた。 名前の通り認証時にパスワードを必要とせず、いわゆる Magic Link によるログイン機構を Rails アプリケーションで実現できる。 Magic Link とは Slack や Medium が実装しているこの機能は「リンクを知ることのできる立場にあれば本人であろう」という二要素認証に似たアイデアに基づいている。 ユーザーがパスワードを覚える必要がないというUX観点だけでなく、パスワードによる認証の弱点とされる推測やブルートフォース攻撃による不正アクセスや乗っ取りのリスクを低減できるメリットがあるとされている。 japanese.engadget.com postd.cc とにかく試す test/dummy ディレクトリにダミーの Rails アプリが実装されているので clone して起動する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く