尧图网页设计 
为前端 JavaScript 应用接入后端Rails 自建 API 与 Firebase BaaS 实战指南GitHub推荐项目精选 cu / curriculum 课程解析【免费下载链接】curriculumThe open curriculum for learning web development项目地址: https://gitcode.com/GitHub_Trending/cu/curriculum导读本指南源自 archive/rails_backend_old.md对应课程体系中JavaScript 与后端的关键一课。当你已经能用纯客户端 JavaScript 做出各种交互时应用仍然缺少一块拼图数据无法持久化——用户一刷新页面偏好设置与所有变更都会消失。本文将系统讲解两条打通前端的路线一条是使用 Ruby on Rails 自建 JSON API 后端重点覆盖无侵入式 JavaScript、content_for引入页面脚本、AJAX 批量加载数据、CSRF 令牌处理与 JSON 数据引导另一条是借助 Firebase 这类 Backend-as-a-ServiceBaaS快速外包后端能力。读完本文你将掌握前端 JavaScript ↔ 后端之间传递数据的完整方法并能在课程项目如照片标记游戏中落地实践。一、问题起点为什么纯客户端应用需要后端纯客户端 JavaScript 能做很多事但有一个致命缺陷除非借助 Local Storage否则应用一旦刷新页面就会忘记用户的一切状态——偏好设置、输入内容、所有变更全部归零。Local Storage 是很好的第一层方案但它并不理想数据只保存在用户当前访问的那台电脑上换一台设备登录同一用户应用就不认识他了。要让应用在不同设备间记住用户数据必须引入一个真正的后端。这正是本课要解决的核心问题也是从会写前端迈向全栈的分水岭。两条路线怎么选课程给出了两条明确的路线详见 archive/rails_backend_old.md路线 ARuby on Rails 自建后端——如果你走的是 Full Stack Ruby on Rails 路径你已经拥有从零构建完整 Web 应用所需的全部工具直接动手写后端即可路线 BBaaS 外包后端——如果你跳过了 Ruby/Rails或者走 Full Stack JavaScript 路径暂时还不足以从零搭建完整应用可以把后端能力外包给 Firebase 或 Apigee 这类 Backend-as-a-Service后端即服务厂商。两条路线在本课程中都有对应的项目实践例如照片标记游戏Wheres Waldo项目就明确支持用 Rails 或 Firebase 作为后端二选一见 archive/javascript/javascript_and_the_backend/project_wheres_waldo_a_photo_tagging_app.md。二、路线 A用 Rails 自建 JSON 后端2.1 前置准备回顾 Rails 的 API 能力在让前端 JavaScript 与 Rails 后端对话之前课程要求你先重读 Rails 课程中构建自己的 API一课当前仓库的对应现代版本是 ruby_on_rails/apis/apis_and_building_your_own.md刷新如何搭建一个能处理 JSON 请求的 Rails 后端。核心观念是你的 Rails 应用本质上已经是一个 API。浏览器请求页面时本质上就是在对 Rails 应用发起 API 请求只不过渲染 HTML 太常见以至于我们把 HTML 当成了默认响应类型。当你不想关心页面结构、只想直接拿到数据时请求同一个 URL 的 JSON 版本即可。Rails 会根据请求文件的扩展名如example.json判断你想要的响应格式。在服务器日志里可以看到处理方式的变化Started GET /posts/new for 127.0.0.1 at 2013-12-02 15:21:08 -0800 Processing by PostsController#new as HTML使用.json扩展名后Started GET /posts.json for 127.0.0.1 at 2013-12-04 12:02:01 -0800 Processing by PostsController#index as JSON2.2 用respond_to渲染 JSON想让同一个控制器动作既能返回 HTML 又能返回 JSON最经典的方式是使用respond_to方法class UsersController ApplicationController def index users User.all respond_to do |format| format.html # index.html.erb format.xml { render :xml users } format.json { render :json users } end end endrespond_to向块传入一个 format 对象你可以在上面挂载对应的渲染调用。render函数足够智能传入:json键时它会对值这里是users调用#to_json把 Ruby 对象序列化成 JSON 字符串传给请求方详见 apis_and_building_your_own.md 的 Rendering JSON or XML 小节。2.3 控制返回字段as_json而非to_json假设你不想在 API 响应中暴露用户的 email 字段。旧做法是重写#to_json但现代做法是重写#as_json——因为#to_json内部会先执行#as_json拿到待渲染的属性哈希再用ActiveSupport::json.encode完成真正的 JSON 序列化。改#as_json就能精准控制要返回哪些属性这一层# app/models/user.rb class User ActiveRecord::Base # 方案 1完全覆盖 #as_json只返回 name def as_json(_options{}) { :name self.name } # 不含 email 字段 end # 方案 2在默认 #as_json 基础上叠加 only 选项 def as_json(options{}) super({ only: [:name] }.merge(options)) end end控制器侧只需照常渲染 JSON 即可render会自动替你调用#to_json# app/controllers/users_controller.rb class UsersController ApplicationController def index render :json User.all end end2.4 错误响应与 API 安全有时你只想返回一个不带响应体的 HTTP 错误码Rails 的head方法提供了优雅的方案# app/controllers/users_controller.rb class UsersController ApplicationController def index head :not_found end end对外安全方面如果只想让已登录用户调用 API现有的before_action认证逻辑同样适用例如before_action :require_login未登录用户不应能通过 API 请求敏感数据。需要注意如果你的 API 要服务于浏览器之外的客户端如命令行工具浏览器 cookie 会话认证就不可靠了这也是大多数 API 会给每个授权用户签发令牌、并要求请求时携带令牌的原因相关讨论见 apis_and_building_your_own.md 的 External facing security 小节。三、让前端 JavaScript 与 Rails 对话AJAX 与数据传递3.1 无侵入式 JavaScriptUnobtrusive JavaScript本课 Rails 路线的一个核心学习目标是理解无侵入式 JavaScriptUnobtrusive JavaScript, UJS如何工作。其思想是JavaScript 行为与 HTML 结构分离。页面中的链接、表单只声明语义化行为例如data-*属性脚本通过监听这些声明来渐进增强页面而不是把onclick...这类内联事件处理器直接写死在 HTML 标签里。这样做的好处包括HTML 保持干净、可维护即使脚本加载失败页面核心功能仍可用行为可以集中管理、统一升级更容易测试与复用。Rails 的 UJS 体系配合 Turbo让普通表单在默认情况下以 TURBO_STREAM 方式异步提交而无需手动写 AJAX 回调。你可以在运行rails server的控制台日志中看到这一点提交表单时日志会显示Processing by UsersController#create as TURBO_STREAM见 ruby_on_rails/forms_and_authentication/form_basics.md。这意味着表单提交不再触发完整的页面刷新周期。3.2 在指定视图页面加载自定义 JavaScriptcontent_for课程作业要求重点研读 Daniel Kehoe 的 Using JavaScript in your Rails App并特别提示依赖相关的内容可以略读但文末关于content_for的部分要重点关注。content_for是 Rails 视图布局中的一块命名内容区。它的典型用法是在子视图如show.html.erb中用content_for :javascript包裹一段只属于该页面的脚本或标签再在布局文件的/body之前用yield :javascript输出。这样就能做到只有当前页面加载它自己需要的自定义 JavaScript而不是把所有页面的脚本一股脑打包进全局%# app/views/posts/show.html.erb % % content_for :javascript do % script // 仅本页需要的初始化逻辑 window.App.initPostPage(); /script % end %%# app/views/layouts/application.html.erb % ... % yield :javascript %content_for配合yield :名称是按页面按需加载 JavaScript的标准答案也是本课知识检查的第一道题如何在指定 Rails 视图页面加载自定义 JavaScript——答案就是content_for加yield。3.3 为什么用 AJAX 加载大批量数据本课另一个学习目标是解释为什么要用 AJAX 加载大批量数据。答案可以概括为三点避免整页刷新传统同步请求每次都要重新下载并渲染整个 HTML 页面即使你只需要一小块数据AJAX 只请求数据JSON/XML前端局部更新响应体更小、更快改善用户体验页面不白屏、不跳转用户停留在当前上下文操作更连贯按需加载把初始页面 HTML与大量数据解耦首屏可以快速呈现重量级数据如长列表、图表数据集在合适时机通过 AJAX 拉取避免首屏加载被拖慢。课程原文的表述是我们会在如何把数据从一端传到另一端上给出一些最佳实践其余就交给你了——你已经有把所有拼图拼在一起所需的一切。3.4 把 JSON 数据引导Bootstrap进 Rails 视图课程作业还要求阅读 Bootstrapping JSON data into a Rails View学习如何把后端数据安全地传给前端。所谓引导 JSON是指在首次页面渲染时就把后端数据以 JSON 形式嵌入 HTML而不是等页面加载完后再发一次 AJAX 请求。典型的安全做法是script typeapplication/json idapp-data% raw data.to_json %/script前端再通过JSON.parse(document.getElementById(app-data).textContent)读取。这种方式避免了把 JSON 直接内联进 JavaScript 代码防止因特殊字符导致脚本语法错误或注入风险也是从 Rails 应用向 JavaScript 传数据这一知识检查题的标准答案。3.5 CSRF 令牌别让 Rails 对你大喊大叫当你的 JavaScript 发起 POST/PATCH/DELETE 请求时很可能遇到 Rails 的经典报错Warning, cant verify CSRF token authenticity。原因在于 Rails 默认开启了跨站请求伪造CSRF防护每个由 Rails 生成的表单都会携带一个唯一的随机字符串authenticity_tokenRails 用它保证接收到的表单输入确实来自你的站点机制详解见 ruby_on_rails/forms_and_authentication/form_basics.md 的 The authenticity token 小节。Parameters: {utf8✓, authenticity_tokenjJa87aK1OpXfjojryBk2Db6thv0K3bSZeYTuW8hF4Ns, emailfoobar.com, commitSubmit Form}如果 Rails 处理表单输入时发现参数里缺少authenticity_token或者令牌值与预期不匹配会直接抛错而不是继续处理请求。因此当你用 JavaScript 手写 AJAX 请求而非 Rails 表单助手生成时必须手动带上 CSRF 令牌。常见做法是从页面元标签中读取% csrf_meta_tags %const token document.querySelector(meta[namecsrf-token]).getAttribute(content); fetch(/some/resource, { method: POST, headers: { Content-Type: application/json, X-CSRF-Token: token }, body: JSON.stringify({ /* 你的数据 */ }) });这里的关键点在页面 HTML 中把csrf_meta_tags输出为meta namecsrf-token再由 JavaScript 读取后放进请求头X-CSRF-Token就能解决无法验证 CSRF 令牌真实性的问题。课程 Additional Resources 中列出的两条 Stack Overflow 问答正是围绕这个话题抓取 Rails 表单 CSRF 令牌以及为 JavaScript 动态创建的表单补充 CSRF 防护。四、路线 B把后端外包给 FirebaseBaaS如果你没有 Rails 背景同样可以让前端应用获得持久化能力——把后端外包给 BaaS。本课选择 Firebase 作为学习对象Apigee 作为同类替代提及。4.1 Firebase 提供哪些服务课程作业要求先探索 Firebase 的产品矩阵现阶段重点放在Cloud FirestoreNoSQL 云数据库其他服务按需选用服务用途本课定位Cloud Firestore云数据库存储与同步应用数据重点关注Firebase Hosting托管静态站点与应用可选首个项目可能用到Cloud Storage存储图片、视频等大文件可选大概率用不到Authentication用户注册登录与身份认证可选首个项目大概率用不到课程明确建议第一个 Firebase 项目大概率用不到 Cloud Storage 和 Authentication先把 Firestore 用起来。4.2 从零配置Google Codelab 实操完成 Firebase Web CodelabFirebase Web Codelab是课程作业的第二步它带你逐步搭建一个运行在 Firebase 上的示例应用覆盖创建 Firebase 项目安装并初始化 Firebase 所需的脚本与配置将示例应用接入 Firestore 等核心服务若被卡住可跳过本地模拟器emulator环节——课程特别标注有些同学在 Codelab 的 emulator 步骤会遇到问题可以暂时跳过不影响后续学习。4.3 把旧项目改造成使用 Firebase完成 Codelab 后回到之前的项目例如图书馆项目或待办事项应用按照 Firebase Web 设置指南准备与 Firebase 后端交互。这里有两条子路线托管在 Firebase Hosting在 Firebase 控制台初始化并部署后直接使用 Firebase 提供的脚本与配置托管在其他地方如 GitHub Pages课程给出明确警告——如果你不打算把应用托管在 Firebase Hosting而是留在原位置就要查看设置指南 Step 4 之下的部分找到指向 Available Libraries 页面的链接然后运用 Codelab 中学到的知识把配置脚本换成适合自己的托管方式让应用真正与 Firebase 交互现代版课程还补充了需要把 GitHub Pages 域名加入 Firebase 的认证授权域名列表。完成这两步后你的前端应用就能通过 Firebase SDK 直接读写 Firestore 等云服务实现跨设备的数据持久化与同步。4.4 学习目标与知识检查Firebase 路线完成本路线的标志是能回答以下问题Firebase 提供了哪些服务——数据库Firestore、托管Hosting、对象存储Storage、认证Authentication等见上方表格如何让应用从 Firebase Hosting 和/或外部主机如 GitHub Pages使用这些服务——通过 Firebase Web 设置指南完成项目初始化与 SDK 接入外部托管时需注意配置脚本与认证域名如何让应用与各项 Firebase 服务通信并双向传递数据——通过 Codelab 中的读写示例掌握 Firestore SDK 的基本调用模式。五、把两条路线落到项目里照片标记游戏本课知识最终在 archive/javascript/javascript_and_the_backend/project_wheres_waldo_a_photo_tagging_app.md 的照片标记游戏中得到综合检验。该项目的技术要点与本课主题一一对应任务本质在一张大照片中让用户找出 Waldo、巫师、Wilma 等角色用户点击照片时弹出定位框与角色下拉菜单选择角色后向后端校验该角色是否真的位于定位框内正确则打上标记错误则给出提示后端的作用角色坐标与校验逻辑放在后端选 Rails 时计时要放在服务器端记录——课程特别强调否则用户能黑掉自己的分数选 Firebase 时计时放在前端后端选型用 Rails 时创建一个精简 Rails 应用先承载 HTML 页面用 Firebase 时新建 Firebase 项目并把必要脚本链接到 HTML 底部开发顺序先把前端交互做完点击弹出定位框、点击外部移除再接入后端校验最后串起选择角色 → 校验 → 放置标记的完整链路并加上计时、输入姓名进排行榜的收尾功能可选扩展在数据库中加载多张图片允许用户在开局前自选。六、结语与继续深入的方向从刷新即失忆的纯前端应用到拥有持久化能力的全栈应用本课给出了两条成熟路径Rails 自建 APIrespond_to渲染 JSON、as_json控制字段、content_for按页加载脚本、AJAX 批量拉数据、CSRF 令牌防护与 Firebase BaaSFirestore 为核心、Hosting 托管、SDK 双向通信。想继续深入可以在当前仓库中找到以下关联材料Rails API 构建的完整讲解含head错误响应、SOA 架构、API 令牌见 ruby_on_rails/apis/apis_and_building_your_own.mdRails 表单、authenticity_token与验证失败的完整生命周期见 ruby_on_rails/forms_and_authentication/form_basics.md课程现代版的两条对应路线Rails 版与 BaaS 版位于 archive/javascript/javascript_and_the_backend/using_rails_for_your_backend.md 与 archive/javascript/javascript_and_the_backend/using_baas_for_your_backend.md综合实战项目见 archive/javascript/javascript_and_the_backend/project_wheres_waldo_a_photo_tagging_app.md。【免费下载链接】curriculumThe open curriculum for learning web development项目地址: https://gitcode.com/GitHub_Trending/cu/curriculum创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 为前端 JavaScript 应用接入后端：Rails 自建 API 与 Firebase BaaS 实战指南（GitHub推荐项目精选 cu / curriculum 课程解析）
为前端 JavaScript 应用接入后端Rails 自建 API 与 Firebase BaaS 实战指南GitHub推荐项目精选 cu / curriculum 课程解析【免费下载链接】curriculumThe open curriculum for learning web development项目地址: https://gitcode.com/GitHub_Trending/cu/curriculum导读本指南源自 archive/rails_backend_old.md对应课程体系中JavaScript 与后端的关键一课。当你已经能用纯客户端 JavaScript 做出各种交互时应用仍然缺少一块拼图数据无法持久化——用户一刷新页面偏好设置与所有变更都会消失。本文将系统讲解两条打通前端的路线一条是使用 Ruby on Rails 自建 JSON API 后端重点覆盖无侵入式 JavaScript、content_for引入页面脚本、AJAX 批量加载数据、CSRF 令牌处理与 JSON 数据引导另一条是借助 Firebase 这类 Backend-as-a-ServiceBaaS快速外包后端能力。读完本文你将掌握前端 JavaScript ↔ 后端之间传递数据的完整方法并能在课程项目如照片标记游戏中落地实践。一、问题起点为什么纯客户端应用需要后端纯客户端 JavaScript 能做很多事但有一个致命缺陷除非借助 Local Storage否则应用一旦刷新页面就会忘记用户的一切状态——偏好设置、输入内容、所有变更全部归零。Local Storage 是很好的第一层方案但它并不理想数据只保存在用户当前访问的那台电脑上换一台设备登录同一用户应用就不认识他了。要让应用在不同设备间记住用户数据必须引入一个真正的后端。这正是本课要解决的核心问题也是从会写前端迈向全栈的分水岭。两条路线怎么选课程给出了两条明确的路线详见 archive/rails_backend_old.md路线 ARuby on Rails 自建后端——如果你走的是 Full Stack Ruby on Rails 路径你已经拥有从零构建完整 Web 应用所需的全部工具直接动手写后端即可路线 BBaaS 外包后端——如果你跳过了 Ruby/Rails或者走 Full Stack JavaScript 路径暂时还不足以从零搭建完整应用可以把后端能力外包给 Firebase 或 Apigee 这类 Backend-as-a-Service后端即服务厂商。两条路线在本课程中都有对应的项目实践例如照片标记游戏Wheres Waldo项目就明确支持用 Rails 或 Firebase 作为后端二选一见 archive/javascript/javascript_and_the_backend/project_wheres_waldo_a_photo_tagging_app.md。二、路线 A用 Rails 自建 JSON 后端2.1 前置准备回顾 Rails 的 API 能力在让前端 JavaScript 与 Rails 后端对话之前课程要求你先重读 Rails 课程中构建自己的 API一课当前仓库的对应现代版本是 ruby_on_rails/apis/apis_and_building_your_own.md刷新如何搭建一个能处理 JSON 请求的 Rails 后端。核心观念是你的 Rails 应用本质上已经是一个 API。浏览器请求页面时本质上就是在对 Rails 应用发起 API 请求只不过渲染 HTML 太常见以至于我们把 HTML 当成了默认响应类型。当你不想关心页面结构、只想直接拿到数据时请求同一个 URL 的 JSON 版本即可。Rails 会根据请求文件的扩展名如example.json判断你想要的响应格式。在服务器日志里可以看到处理方式的变化Started GET /posts/new for 127.0.0.1 at 2013-12-02 15:21:08 -0800 Processing by PostsController#new as HTML使用.json扩展名后Started GET /posts.json for 127.0.0.1 at 2013-12-04 12:02:01 -0800 Processing by PostsController#index as JSON2.2 用respond_to渲染 JSON想让同一个控制器动作既能返回 HTML 又能返回 JSON最经典的方式是使用respond_to方法class UsersController ApplicationController def index users User.all respond_to do |format| format.html # index.html.erb format.xml { render :xml users } format.json { render :json users } end end endrespond_to向块传入一个 format 对象你可以在上面挂载对应的渲染调用。render函数足够智能传入:json键时它会对值这里是users调用#to_json把 Ruby 对象序列化成 JSON 字符串传给请求方详见 apis_and_building_your_own.md 的 Rendering JSON or XML 小节。2.3 控制返回字段as_json而非to_json假设你不想在 API 响应中暴露用户的 email 字段。旧做法是重写#to_json但现代做法是重写#as_json——因为#to_json内部会先执行#as_json拿到待渲染的属性哈希再用ActiveSupport::json.encode完成真正的 JSON 序列化。改#as_json就能精准控制要返回哪些属性这一层# app/models/user.rb class User ActiveRecord::Base # 方案 1完全覆盖 #as_json只返回 name def as_json(_options{}) { :name self.name } # 不含 email 字段 end # 方案 2在默认 #as_json 基础上叠加 only 选项 def as_json(options{}) super({ only: [:name] }.merge(options)) end end控制器侧只需照常渲染 JSON 即可render会自动替你调用#to_json# app/controllers/users_controller.rb class UsersController ApplicationController def index render :json User.all end end2.4 错误响应与 API 安全有时你只想返回一个不带响应体的 HTTP 错误码Rails 的head方法提供了优雅的方案# app/controllers/users_controller.rb class UsersController ApplicationController def index head :not_found end end对外安全方面如果只想让已登录用户调用 API现有的before_action认证逻辑同样适用例如before_action :require_login未登录用户不应能通过 API 请求敏感数据。需要注意如果你的 API 要服务于浏览器之外的客户端如命令行工具浏览器 cookie 会话认证就不可靠了这也是大多数 API 会给每个授权用户签发令牌、并要求请求时携带令牌的原因相关讨论见 apis_and_building_your_own.md 的 External facing security 小节。三、让前端 JavaScript 与 Rails 对话AJAX 与数据传递3.1 无侵入式 JavaScriptUnobtrusive JavaScript本课 Rails 路线的一个核心学习目标是理解无侵入式 JavaScriptUnobtrusive JavaScript, UJS如何工作。其思想是JavaScript 行为与 HTML 结构分离。页面中的链接、表单只声明语义化行为例如data-*属性脚本通过监听这些声明来渐进增强页面而不是把onclick...这类内联事件处理器直接写死在 HTML 标签里。这样做的好处包括HTML 保持干净、可维护即使脚本加载失败页面核心功能仍可用行为可以集中管理、统一升级更容易测试与复用。Rails 的 UJS 体系配合 Turbo让普通表单在默认情况下以 TURBO_STREAM 方式异步提交而无需手动写 AJAX 回调。你可以在运行rails server的控制台日志中看到这一点提交表单时日志会显示Processing by UsersController#create as TURBO_STREAM见 ruby_on_rails/forms_and_authentication/form_basics.md。这意味着表单提交不再触发完整的页面刷新周期。3.2 在指定视图页面加载自定义 JavaScriptcontent_for课程作业要求重点研读 Daniel Kehoe 的 Using JavaScript in your Rails App并特别提示依赖相关的内容可以略读但文末关于content_for的部分要重点关注。content_for是 Rails 视图布局中的一块命名内容区。它的典型用法是在子视图如show.html.erb中用content_for :javascript包裹一段只属于该页面的脚本或标签再在布局文件的/body之前用yield :javascript输出。这样就能做到只有当前页面加载它自己需要的自定义 JavaScript而不是把所有页面的脚本一股脑打包进全局%# app/views/posts/show.html.erb % % content_for :javascript do % script // 仅本页需要的初始化逻辑 window.App.initPostPage(); /script % end %%# app/views/layouts/application.html.erb % ... % yield :javascript %content_for配合yield :名称是按页面按需加载 JavaScript的标准答案也是本课知识检查的第一道题如何在指定 Rails 视图页面加载自定义 JavaScript——答案就是content_for加yield。3.3 为什么用 AJAX 加载大批量数据本课另一个学习目标是解释为什么要用 AJAX 加载大批量数据。答案可以概括为三点避免整页刷新传统同步请求每次都要重新下载并渲染整个 HTML 页面即使你只需要一小块数据AJAX 只请求数据JSON/XML前端局部更新响应体更小、更快改善用户体验页面不白屏、不跳转用户停留在当前上下文操作更连贯按需加载把初始页面 HTML与大量数据解耦首屏可以快速呈现重量级数据如长列表、图表数据集在合适时机通过 AJAX 拉取避免首屏加载被拖慢。课程原文的表述是我们会在如何把数据从一端传到另一端上给出一些最佳实践其余就交给你了——你已经有把所有拼图拼在一起所需的一切。3.4 把 JSON 数据引导Bootstrap进 Rails 视图课程作业还要求阅读 Bootstrapping JSON data into a Rails View学习如何把后端数据安全地传给前端。所谓引导 JSON是指在首次页面渲染时就把后端数据以 JSON 形式嵌入 HTML而不是等页面加载完后再发一次 AJAX 请求。典型的安全做法是script typeapplication/json idapp-data% raw data.to_json %/script前端再通过JSON.parse(document.getElementById(app-data).textContent)读取。这种方式避免了把 JSON 直接内联进 JavaScript 代码防止因特殊字符导致脚本语法错误或注入风险也是从 Rails 应用向 JavaScript 传数据这一知识检查题的标准答案。3.5 CSRF 令牌别让 Rails 对你大喊大叫当你的 JavaScript 发起 POST/PATCH/DELETE 请求时很可能遇到 Rails 的经典报错Warning, cant verify CSRF token authenticity。原因在于 Rails 默认开启了跨站请求伪造CSRF防护每个由 Rails 生成的表单都会携带一个唯一的随机字符串authenticity_tokenRails 用它保证接收到的表单输入确实来自你的站点机制详解见 ruby_on_rails/forms_and_authentication/form_basics.md 的 The authenticity token 小节。Parameters: {utf8✓, authenticity_tokenjJa87aK1OpXfjojryBk2Db6thv0K3bSZeYTuW8hF4Ns, emailfoobar.com, commitSubmit Form}如果 Rails 处理表单输入时发现参数里缺少authenticity_token或者令牌值与预期不匹配会直接抛错而不是继续处理请求。因此当你用 JavaScript 手写 AJAX 请求而非 Rails 表单助手生成时必须手动带上 CSRF 令牌。常见做法是从页面元标签中读取% csrf_meta_tags %const token document.querySelector(meta[namecsrf-token]).getAttribute(content); fetch(/some/resource, { method: POST, headers: { Content-Type: application/json, X-CSRF-Token: token }, body: JSON.stringify({ /* 你的数据 */ }) });这里的关键点在页面 HTML 中把csrf_meta_tags输出为meta namecsrf-token再由 JavaScript 读取后放进请求头X-CSRF-Token就能解决无法验证 CSRF 令牌真实性的问题。课程 Additional Resources 中列出的两条 Stack Overflow 问答正是围绕这个话题抓取 Rails 表单 CSRF 令牌以及为 JavaScript 动态创建的表单补充 CSRF 防护。四、路线 B把后端外包给 FirebaseBaaS如果你没有 Rails 背景同样可以让前端应用获得持久化能力——把后端外包给 BaaS。本课选择 Firebase 作为学习对象Apigee 作为同类替代提及。4.1 Firebase 提供哪些服务课程作业要求先探索 Firebase 的产品矩阵现阶段重点放在Cloud FirestoreNoSQL 云数据库其他服务按需选用服务用途本课定位Cloud Firestore云数据库存储与同步应用数据重点关注Firebase Hosting托管静态站点与应用可选首个项目可能用到Cloud Storage存储图片、视频等大文件可选大概率用不到Authentication用户注册登录与身份认证可选首个项目大概率用不到课程明确建议第一个 Firebase 项目大概率用不到 Cloud Storage 和 Authentication先把 Firestore 用起来。4.2 从零配置Google Codelab 实操完成 Firebase Web CodelabFirebase Web Codelab是课程作业的第二步它带你逐步搭建一个运行在 Firebase 上的示例应用覆盖创建 Firebase 项目安装并初始化 Firebase 所需的脚本与配置将示例应用接入 Firestore 等核心服务若被卡住可跳过本地模拟器emulator环节——课程特别标注有些同学在 Codelab 的 emulator 步骤会遇到问题可以暂时跳过不影响后续学习。4.3 把旧项目改造成使用 Firebase完成 Codelab 后回到之前的项目例如图书馆项目或待办事项应用按照 Firebase Web 设置指南准备与 Firebase 后端交互。这里有两条子路线托管在 Firebase Hosting在 Firebase 控制台初始化并部署后直接使用 Firebase 提供的脚本与配置托管在其他地方如 GitHub Pages课程给出明确警告——如果你不打算把应用托管在 Firebase Hosting而是留在原位置就要查看设置指南 Step 4 之下的部分找到指向 Available Libraries 页面的链接然后运用 Codelab 中学到的知识把配置脚本换成适合自己的托管方式让应用真正与 Firebase 交互现代版课程还补充了需要把 GitHub Pages 域名加入 Firebase 的认证授权域名列表。完成这两步后你的前端应用就能通过 Firebase SDK 直接读写 Firestore 等云服务实现跨设备的数据持久化与同步。4.4 学习目标与知识检查Firebase 路线完成本路线的标志是能回答以下问题Firebase 提供了哪些服务——数据库Firestore、托管Hosting、对象存储Storage、认证Authentication等见上方表格如何让应用从 Firebase Hosting 和/或外部主机如 GitHub Pages使用这些服务——通过 Firebase Web 设置指南完成项目初始化与 SDK 接入外部托管时需注意配置脚本与认证域名如何让应用与各项 Firebase 服务通信并双向传递数据——通过 Codelab 中的读写示例掌握 Firestore SDK 的基本调用模式。五、把两条路线落到项目里照片标记游戏本课知识最终在 archive/javascript/javascript_and_the_backend/project_wheres_waldo_a_photo_tagging_app.md 的照片标记游戏中得到综合检验。该项目的技术要点与本课主题一一对应任务本质在一张大照片中让用户找出 Waldo、巫师、Wilma 等角色用户点击照片时弹出定位框与角色下拉菜单选择角色后向后端校验该角色是否真的位于定位框内正确则打上标记错误则给出提示后端的作用角色坐标与校验逻辑放在后端选 Rails 时计时要放在服务器端记录——课程特别强调否则用户能黑掉自己的分数选 Firebase 时计时放在前端后端选型用 Rails 时创建一个精简 Rails 应用先承载 HTML 页面用 Firebase 时新建 Firebase 项目并把必要脚本链接到 HTML 底部开发顺序先把前端交互做完点击弹出定位框、点击外部移除再接入后端校验最后串起选择角色 → 校验 → 放置标记的完整链路并加上计时、输入姓名进排行榜的收尾功能可选扩展在数据库中加载多张图片允许用户在开局前自选。六、结语与继续深入的方向从刷新即失忆的纯前端应用到拥有持久化能力的全栈应用本课给出了两条成熟路径Rails 自建 APIrespond_to渲染 JSON、as_json控制字段、content_for按页加载脚本、AJAX 批量拉数据、CSRF 令牌防护与 Firebase BaaSFirestore 为核心、Hosting 托管、SDK 双向通信。想继续深入可以在当前仓库中找到以下关联材料Rails API 构建的完整讲解含head错误响应、SOA 架构、API 令牌见 ruby_on_rails/apis/apis_and_building_your_own.mdRails 表单、authenticity_token与验证失败的完整生命周期见 ruby_on_rails/forms_and_authentication/form_basics.md课程现代版的两条对应路线Rails 版与 BaaS 版位于 archive/javascript/javascript_and_the_backend/using_rails_for_your_backend.md 与 archive/javascript/javascript_and_the_backend/using_baas_for_your_backend.md综合实战项目见 archive/javascript/javascript_and_the_backend/project_wheres_waldo_a_photo_tagging_app.md。【免费下载链接】curriculumThe open curriculum for learning web development项目地址: https://gitcode.com/GitHub_Trending/cu/curriculum创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考