Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Sync – Realtime partials with Rails

chrismccord.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Show HN: Sync – Realtime partials with Rails

#21

Post by marcamillion »

I really like this.

The only thing that kinda threw me off a bit was putting the partials in the /views/sync/resource/ folder. Feels a bit non-RESTy.

I imagine, for a sufficiently complex app that sync folder will become a bit messy - although, I guess it's like the 'layout' folder.

That's just me being nitpicky though.

This is awesome.

As others pointed out, this would be perfect if it weren't for the fact that you have to use additional resources to use it properly. i.e. another dyno for Faye or use Pusher.

Thanks for this though.

Edit: One thing I would love to know is how this interacts with caching though. Russian Doll Caching specifically. Every time an attributed is update, does it bust the entire cache and have to reload that entire fragment - as opposed to just the partial?

Re: Show HN: Sync – Realtime partials with Rails

#22

Post by chrismccord »

marcamillion wrote: post #21

I really like this. The only thing that kinda threw me off a bit was putting the partials in the /views/sync/resource/ folder. Feels a bit non-RESTy. I imagine, for a sufficiently complex app that sync folder will become a bit messy - although, I guess it's like the 'layout' folder. That's just me being nitpicky though. This is awesome. As others pointed out, this would be perfect if it weren't for the fact that you…

The partials each get separated into their own folder based on their model name. So it's not a grab-bag of random partials – it's the same folder structure an application would use for its regular views, but instead with a parent sync folder. ie, if a views/users/ directory contained "_profile.html.erb", you would move the sync partial to views/sync/users/. Having to run an additional process is the best case scenario right now unless we can get websockets into Rails/Ruby land, but I'm a believer that this approach is the best solution for current tooling suits the problem quite well. In regards to russian doll caching I'll have to take a look and verify what's going on under the hood, but sync will work fine with fragment caching outside and within a sync'd partial as long as the cache keys properly account for the resource/scope. When a model is updated on the server and `sync_update user` is called, Sync will render every partial to string in the views/sync/users directory, and dispatch a message to listeners on each channel for each partial. So the sync will only re-render what's contained in the sync'd partial. If you have fragment caches within your sync'd partial, they will only bust if their cache key has expired just like a normal render. Hopefully that helps. Thanks for the input/complements

Re: Show HN: Sync – Realtime partials with Rails

#23

Post by marcamillion »

chrismccord wrote: post #22
marcamillion wrote: post #21

I really like this. The only thing that kinda threw me off a bit was putting the partials in the /views/sync/resource/ folder. Feels a bit non-RESTy. I imagine, for a sufficiently complex app that sync folder will become a bit messy - although, I guess it's like the 'layout' folder. That's just me being nitpicky though. This is awesome. As others pointed out, this would be perfect if it weren't for the fact that you…

The partials each get separated into their own folder based on their model name. So it's not a grab-bag of random partials – it's the same folder structure an application would use for its regular views, but instead with a parent sync folder. ie, if a views/users/ directory contained "_profile.html.erb", you would move the sync partial to views/sync/users/. Having to run an additional process is the best case scenari…

Ahhh ok. I get you, re: the caching.

This is very cool. I have been waiting for something like this, to dive into the real-time web. Wading into client-side JS frameworks has been low on my bucket-list, but I am glad I can finally get something like this to add some 'rich interactivity' to my app.

I definitely agree with everybody else, this should be baked into Rails core - for sure.

I would have thought that with Basecamp Next and the direction that DHH said Rails was going (with aggressive caching and pushing only JSON down the wire) that this implementation would have been included in Rails 4. I was disappointed when it wasn't.

Thanks for doing this. Really appreciate it.

Re: Show HN: Sync – Realtime partials with Rails

#26

Post by tomhallett »

chrismccord wrote: post #22
marcamillion wrote: post #21

I really like this. The only thing that kinda threw me off a bit was putting the partials in the /views/sync/resource/ folder. Feels a bit non-RESTy. I imagine, for a sufficiently complex app that sync folder will become a bit messy - although, I guess it's like the 'layout' folder. That's just me being nitpicky though. This is awesome. As others pointed out, this would be perfect if it weren't for the fact that you…

The partials each get separated into their own folder based on their model name. So it's not a grab-bag of random partials – it's the same folder structure an application would use for its regular views, but instead with a parent sync folder. ie, if a views/users/ directory contained "_profile.html.erb", you would move the sync partial to views/sync/users/. Having to run an additional process is the best case scenari…

Can you provide some details on why the partials have to be namespace'd to the sync directory? My guess is: sync partials can only be "resource" based, and can't be given locals like a regular partial. Therefore, sync-partials are a subset of regular partials, so a different directory makes the distinction very clear.

Just curious what the reason is.

Looks very cool, I will definitely try it out!

Re: Show HN: Sync – Realtime partials with Rails

#27

Post by wilg »

hifier wrote: post #24

This looks really great. Does anyone have any thoughts on how this could be combined with client friendly templating so that the rendering of the partial could be done client side for updates, but server side for the initial page load?

If I understand right, the whole point of Sync is to avoid having to do this.

Re: Show HN: Sync – Realtime partials with Rails

#28

Post by chrismccord »

tomhallett wrote: post #26
chrismccord wrote: post #22

Earlier quoted context omitted.

The partials each get separated into their own folder based on their model name. So it's not a grab-bag of random partials – it's the same folder structure an application would use for its regular views, but instead with a parent sync folder. ie, if a views/users/ directory contained "_profile.html.erb", you would move the sync partial to views/sync/users/. Having to run an additional process is the best case scenari…

Can you provide some details on why the partials have to be namespace'd to the sync directory? My guess is: sync partials can only be "resource" based, and can't be given locals like a regular partial. Therefore, sync-partials are a subset of regular partials, so a different directory makes the distinction very clear. Just curious what the reason is. Looks very cool, I will definitely try it out!

You're right about part of the reason. One reason the partials are namespaced is indeed to serve as a distinction since at the moment, only the resource can hold the context for the partial. ivars will be visible from both the parent view render and controller sync calls, but likely not reliable since the partials will be rendered from different actions. The main reason they are namespaced is to allow rendering of all partials for the sync'd resource when publishing syncs in the controller. We can just ask the resource to give us all its partials in the views/sync/[resource pluralized] directory and only render those partials that are realtime, versus needlessly rendering all partials (including non-realtime) in the 'normal' resource directory.

Re: Show HN: Sync – Realtime partials with Rails

#30

Post by hifier »

wilg wrote: post #27
hifier wrote: post #24

This looks really great. Does anyone have any thoughts on how this could be combined with client friendly templating so that the rendering of the partial could be done client side for updates, but server side for the initial page load?

If I understand right, the whole point of Sync is to avoid having to do this.

It would simply be a change in the templates that you use and how the changes are communicated to the client. It could still work the same way from the perspective that the changes are pushed to the client and the DOM is automatically replaced. The reason that I ask is that this could offload some of the server side processing to the client and also reduce the amount of data transfered over the wire. The server would be pushing JSON instead of HTML. From the dev's perspective you'd just be using a different templating framework. I wonder how the current implementation would scale, I imagine it would take some serious processing power to get to 100k+ concurrent, active users.
Post reply on HN