-
Notifications
You must be signed in to change notification settings - Fork 7
Streaming Consideration
Zete edited this page Sep 30, 2013
·
2 revisions
Let's address the original problem: why we need streaming?
When an action takes too much time, say, when it has to do an oauth validation with google. In usual applications the client may not have any of the result page until the action completes. One solution is to use streaming, and send chunks eagerly. But template rendering in Rails is not friendly to streaming, then I came to the idea of the first streaming design, and let Fiber.yield trigger the render buffer flushing.
But it is not very useful indeed, and makes the View class too complex. One can usually use front-end techniques to do the same job: render a page with quick data at hand, and ajax load the rest that takes time.
- Getting started with a single file
- Getting started with a project structure
- Configure options
- Modulize actions with controller
- Routing and path helper
- Action metadata and content format
- Header, param, session and cookie
- Flash
- The request object
- Response helpers
- Render, layout and partial
- View streaming
- Other helpers
- Custom helpers
- Action lifecycle callbacks
- Test helper
Recipes(todo)
- [Web server]
- [Secure headers]
- [Mapping different paths to a same controller]
- [I18n]
- [Form helpers]
- [Oauth]
- [Test]
-- Digging deeper --