VR backend rails vs serverless: froth or future?
summary
A client project needs a multi‑user, real‑time VR app and the team evaluates serverless versus a conventional backend then chooses Rails 5 API mode for persistence, orchestration and testing instead of lifting core logic into short‑lived lambdas. The build uses Unity + C# for the engine, Photon for real‑time networking, Rails APIs and Action Cable for sync and state, and an SQL DSL to integrate a legacy database. Notes: AWS Lambda cold starts and time limits, testing and monitoring gaps, and aiming for ~100 FPS drive the decision toward Rails.
AI-written summary · about
chapters (22)
- 0:00Intro
- 1:38buzzword bingo
- 1:58hype
- 2:31client
- 3:31service
- 4:26what is service
- 6:09client wants
- 8:22VR cricket
- 9:50Unity
- 11:48Service considerations
- 12:16Autoscaling
- 13:13Cost advantage
- 13:40Community
- 14:29Testing
- 15:36Control
- 16:08Outsourcing complexity
- 16:38Configuration
- 16:51Monitoring
- 17:39Skills
- 19:12Daydream
- 20:26Call to action
- 21:33Invitation
related talks
28mBuilding in Rails, Backbone, and CoffeeScript
46mBuilding modern web-applications with GraphQL & serverless Ruby
31mServerless Rails: Understanding the pros and cons
31m"Ruby Serverless Framework"
21mMigrating Legacy Backends to Serverless in Parallel
51mFaaS or not to FaaS? Visible and invisible benefits of the Serverless paradigma
55mLive Serverless
36mRails Vs. The Client Side