7 ms·

Show HN: Sync – Realtime partials with Rails

143 points by chrismccord 14y ago

TallboyOne 14y ago
Very cool, I like
killion 14y ago
Great! This will come in handy for new projects. Unfortunately we had to create the same thing for our existing stuff.
joshcrowder 14y ago
This is brilliant, looking forward to using this. Is this in use anywhere?
- chrismccord 14y ago
  I just pushed out the official release this weekend and don't have any apps yet running in production. My goal is to have people start building out apps and support any uncovered use cases that crop up. Having said that, there's no reason this can't be run in production and I plan on deploying a couple example apps so people can play around.
  - tortilla 14y ago
    This looks perfect for a current project with a quite a bit of jQuery and partials. I may just redo using Sync. Do you have any recommendations for using on Heroku? Should I just use Pusher? Also does this work with Rails 4?
    - chrismccord 14y ago
      Faye will gladly run on Heroku with a foreman process, but I think Pusher is a tough choice to beat to get you up and running quickly. Sync does indeed support Rails 4. In fact, the demo app in the screencast is a Rails 4 app :)
      - scoot 14y ago
        So either Pusher or Faye are required, and Pusher is a commercial service, whilst Faye requires a dyno to run on Heroku? Have I got that right? TBH I'm not familiar with either Pusher or Faye, so just trying to grok the dependancies for Sync.
        chrismccord 14y ago
        That's correct. If on Heroku, Faye would run in it's own dyno process, while Pusher is a commercial product. Sync requires a pubsub server to talk to, so either is a must. I suggest prototyping out with the Pusher free plan if you just want to throw something up to experiment with.
livando 14y ago
awesome, great way to spike out real time behavior in minutes.
robotmay 14y ago
Looks neat. I actually would have made use of this a couple of weeks ago, but I'll keep it in mind if we rewrite that section of the app (as the current solution isn't quite as elegant).
hemancuso 14y ago
Looks neat, but I am curious why you would pick such an overused name for the project. Perhaps call it PartialSync, or something you could google?
- chrismccord 14y ago
  I struggled with the naming to be honest, but settled on something short and sweet that sounded nice to me. Googling hopefully won't be a problem when coupled with a copule modifiers, ie "sync realtime partials"
benradler 14y ago
Me gusta. Can this potentially replace a client-side MVC framework like backbone.js or ember.js entirely or are there limitations?
- chrismccord 14y ago
  Sync is an alternative to Ember/Backbone, but not a replacement. If you're trying to replicate desktop software in the browser for instance, a heavy client-side framework is the way to go; however, for certain use cases for web applications with lots of "richness" but not trying to replicate desktop level interactivity, think Basecamp, Reddit, Facebook, Twitter, the Sync approach could definitely hold its own against these types of apps. I've greatly enjoyed building Backbone apps, and I look forward to playing with Ember, but not every web application needs to be rendered client-side against a JSON api. Sync also allows you to wire up your own javascript, so you could even use backbone models submitting over JSON and render your realtime views with Sync on the server. I'm excited to see how far we can take this approach.
  - benradler 14y ago
    thanks for the info chris, I will be following the project closely. I think I will try and implement it in one of my instagram-API driven web apps as a test.
    - chrismccord 14y ago
      No problem. Let me know how it goes
andyl 14y ago
OMG this is great - should be a standard part of rails.
Jarred 14y ago
This is awesome! The next time I need functionality similar to what a client-side MVC framework provides, I'll give this a try first.
habosa 14y ago
Wow this really should become part of core Rails. This is definitely real time done the "rails way". I prefer Rails to anything else I've tried but my ideas increasingly revolve around real-time, so I either settle for a framework I like less or Rails + jQuery nonsense. This will be my new go to.
marcamillion 14y ago
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?
- chrismccord 14y ago
  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
  - marcamillion 14y ago
    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.
hifier 14y ago
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?
- wilg 14y ago
  If I understand right, the whole point of Sync is to avoid having to do this.
  - hifier 14y ago
    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.
acjohnson55 14y ago
Does anybody know of anything like this for Django? I'm very much interested in better integration between client-side and server-side code. I'm really not sold on the client-side MVC paradigm, and I think this sounds like an awesome alternative.
tikhon 14y ago
Wow. I'm really impressed. Great work, Chris.

143 points by chrismccord 14y ago

TallboyOne 14y ago

Very cool, I like

killion 14y ago

Great! This will come in handy for new projects. Unfortunately we had to create the same thing for our existing stuff.

joshcrowder 14y ago

This is brilliant, looking forward to using this. Is this in use anywhere?

chrismccord 14y ago
I just pushed out the official release this weekend and don't have any apps yet running in production. My goal is to have people start building out apps and support any uncovered use cases that crop up. Having said that, there's no reason this can't be run in production and I plan on deploying a couple example apps so people can play around.
- tortilla 14y ago
  This looks perfect for a current project with a quite a bit of jQuery and partials. I may just redo using Sync. Do you have any recommendations for using on Heroku? Should I just use Pusher? Also does this work with Rails 4?
  - chrismccord 14y ago
    Faye will gladly run on Heroku with a foreman process, but I think Pusher is a tough choice to beat to get you up and running quickly. Sync does indeed support Rails 4. In fact, the demo app in the screencast is a Rails 4 app :)
    - scoot 14y ago
      So either Pusher or Faye are required, and Pusher is a commercial service, whilst Faye requires a dyno to run on Heroku? Have I got that right? TBH I'm not familiar with either Pusher or Faye, so just trying to grok the dependancies for Sync.
      - chrismccord 14y ago
        That's correct. If on Heroku, Faye would run in it's own dyno process, while Pusher is a commercial product. Sync requires a pubsub server to talk to, so either is a must. I suggest prototyping out with the Pusher free plan if you just want to throw something up to experiment with.

livando 14y ago

awesome, great way to spike out real time behavior in minutes.

robotmay 14y ago

Looks neat. I actually would have made use of this a couple of weeks ago, but I'll keep it in mind if we rewrite that section of the app (as the current solution isn't quite as elegant).

hemancuso 14y ago

Looks neat, but I am curious why you would pick such an overused name for the project. Perhaps call it PartialSync, or something you could google?

chrismccord 14y ago
I struggled with the naming to be honest, but settled on something short and sweet that sounded nice to me. Googling hopefully won't be a problem when coupled with a copule modifiers, ie "sync realtime partials"

benradler 14y ago

Me gusta. Can this potentially replace a client-side MVC framework like backbone.js or ember.js entirely or are there limitations?

chrismccord 14y ago
Sync is an alternative to Ember/Backbone, but not a replacement. If you're trying to replicate desktop software in the browser for instance, a heavy client-side framework is the way to go; however, for certain use cases for web applications with lots of "richness" but not trying to replicate desktop level interactivity, think Basecamp, Reddit, Facebook, Twitter, the Sync approach could definitely hold its own against these types of apps. I've greatly enjoyed building Backbone apps, and I look forward to playing with Ember, but not every web application needs to be rendered client-side against a JSON api. Sync also allows you to wire up your own javascript, so you could even use backbone models submitting over JSON and render your realtime views with Sync on the server. I'm excited to see how far we can take this approach.
- benradler 14y ago
  thanks for the info chris, I will be following the project closely. I think I will try and implement it in one of my instagram-API driven web apps as a test.
  - chrismccord 14y ago
    No problem. Let me know how it goes

andyl 14y ago

OMG this is great - should be a standard part of rails.

Jarred 14y ago

This is awesome! The next time I need functionality similar to what a client-side MVC framework provides, I'll give this a try first.

habosa 14y ago

Wow this really should become part of core Rails. This is definitely real time done the "rails way". I prefer Rails to anything else I've tried but my ideas increasingly revolve around real-time, so I either settle for a framework I like less or Rails + jQuery nonsense. This will be my new go to.

marcamillion 14y ago

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?

chrismccord 14y ago
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
- marcamillion 14y ago
  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.

hifier 14y ago

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?

wilg 14y ago
If I understand right, the whole point of Sync is to avoid having to do this.
- hifier 14y ago
  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.

acjohnson55 14y ago

Does anybody know of anything like this for Django? I'm very much interested in better integration between client-side and server-side code. I'm really not sold on the client-side MVC paradigm, and I think this sounds like an awesome alternative.

tikhon 14y ago

Wow. I'm really impressed. Great work, Chris.