Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

That's actually a relatively nice, Rails-magic-style approach to solving this sort of thing. Of course, if you were building a more interactive application, you'd already have a JS framework in place that would negate these benefits – but I'm still convinced there's a nice middle-ground for server-rendered Rails apps that avoids the various problems of SPAs.

It would be nice if it worked without JavaScript though – an increasing pain-in-the-arse about the web generally. If only it were possible to have <iframe>s adjust to their content size, then we wouldn't need JavaScript at all!

View on HN

I was the original author of this gem, so it is nice to see it here on HN, I have since passed it on the the caring hands of Semaphore since they wanted to maintain and improve it :-)

The software was built for a forum where the admin buttons was only for specific users, but the rest of the frontend was the same, so we used render_async to render some content for some users, and other content for admins, and the rest of the page could be cached statically.

We later changed it to use edge side includes with Varnish. An example of this is where you add the to your HTML:

    <esi:include src="http://example.com/1.html" alt="http://bak.example.com/2.html" onerror="continue"/>

This will make Varnish fetch the URL(s), assemble the page and present it to the client, so your backend might see more requests, but the client only sees one.

It's an interesting approach. It's only async from the client perspective though. Right? The server still processes the action/render inline? (i.e. it's not spawning a sidekiq process as far as I can tell).

We recently implemented something that's async on the server, using a combination of pusher and sidekiq. This was particularly useful for cases where we access an external API and don't want to hold the unicorn process for too long. So when the response comes back we push it back to the client and display it. Would be interesting to maybe combine this approach with some server-push and background workers and what this gem is doing.

Render-async lets the client render the page, and then request "partials" from the server, the backend sees two different requests from the browser

The inline includes that Varnish does is synchronous for the client, but asynchronous in your backend, your backend sees multiple requests.

I am interested in your pusher+sidekiq implementation, it is a good idea, but it might be a lot of work :)

It's definitely more involved, and might be slightly more complex to generalize, but in essence it's quite straight-forward:

1. Client sends a request via Ajax to a rails controller and simultaneously opens a private pusher channel to wait for a response.

2. Controller returns a response immediately and fires-off a sidekiq job.

3. The sidekiq job does the heavy lifting and pushes the results back via pusher (it can be JSON data, or a rendered partial).

4. Client receives the response via the pusher channel and shows it on the page.

How do you set up a "pusher channel" to the browser? Websocket?

Would love to see a write-up/notes/gist that demos this.

Pusher is based on websockets, yes.

https://pusher.com/websockets

So you are suggesting using a front end cache server like Varnish is better then what you originally programmed for?

It depends - Varnish is great, but in case of error-handling I think it is better to handle that with JavaScript, so you can retry, and you avoid that a timeout or slowdown doesn't block your clients.

On the other hand, I really like to just throw HTML at the user without involving asynchronous JavaScript.

That's a good use-case!

At the very least, it's a very nice stopgap until a full JS frontend is in place. I intend on throwing this into my existing rails app for various optimisations while it awaits an SPA frontend.

I'm also using react-rails on my case to make a bridge between rails and react and it has been very useful so far, you can even render components server-side to test them with rspec.

I don't quite get the reference to "magic"... It's quite easy to get what this does, and surely not every function call can be considered "magic"?

You're right, of course – I would consider this 'Rails magic' because it fits the general pattern of all those cool UJS helpers that are available. Things like `form_for(remote: true)` or `link_to remote: true`. This is just an extension of the same principle, which I think of as being basically magic!

I kinda wish it worked more like UJS though, rather than rendering a partial with <script> tags it could be just rendering some arbitrary <div> tag that, when it exists on the page, fires an event for rendering a partial asynchronously on the page. the UJS helpers for doing this already exist, because `link_to remote: true` is a thing. instead of making the GET request when the link is clicked, we're just triggering the link to be clicked right there in the page.

How would an iframe help avoid needing JS?

Well in this case, it feels like you could easily substitute out the AJAX request with an inline iframe that would embed the asynchronous content into the page. That's not possible, unless you have fixed-size elements or Javascript, since you won't be able to have the frame adapt to the size of its content. It's definitely useful in some cases though – I know that various social plugins used to work like this (I don't know if they do any more!)

just use regular <frame>s and <frameset> ;-)

Reply on news.ycombinator.com