Meteor 0.7.1: Oplog support for complex queries, Meteor developer accounts | Hacker News Reader

Meteor 0.7.1: Oplog support for complex queries, Meteor developer accounts

meteor.com

69 pointsdebergalis20 comments

Any python backend examples for Meteor yet?

Or maybe perl backend examples?

A backend for Meteor, fronted in another language doesn't exist. What I'll assume you're looking for is a bridge. Which Meteor.JS provides access to via the Distributed Data Protocol (DDP). There are clients for most languages, from javascript to ruby and etc. However, there are no servers operating the DDP outside of Meteor to the best of my knowledge. The DDP itself is kind of like REST over sockets on steroids.

https://github.com/meteor/meteor/blob/devel/packages/livedat...

https://github.com/search?q=meteor+ddp&ref=cmdform

> The DDP itself is kind of like REST over sockets on steroids.

Wait, could you help me grok that? The way I see DDP, it's more like "just" RPC + notifications. Where does the RESTfulness come from?

There is no restfulness inherent in Meteor. You're description of DDP is more accurate.

I worded it as an oversimplification, but it does offer the same service a REST endpoint would offer (CRUD docs), and more via subscriptions. REST in itself is just an RPC, what I'm trying to convey is that it offers the same, plus more over a socket.

Unless the Python Web community get rid of WSGI, this won't happen in any foreseeable future.

You can always build from scratch using Tornado or Gevent or something like http://brubeck.io

I have a simple rails app now I want to add realtime to it, it seems I have those options:

a. rails + node.js + reddis

b. 'rewrite' the rails app in meteor.js

c. rails + firebase

Any suggestions? Anyone uses meteor.js from a rails background?

meteor.js is really cool, but it is not ready for production, so it depends on how important your app is. Scaling it beyond a single server is actually not that simple.

Another factor to look at is how extensive the realtime functionality will be. If you just want to make a realtime dashboard for your app, using ajax with a partial to redraw a div every second (or do nothing if the ajax returns no change) is really simple compared to having to add the complexity of another service in a different language (remember that node.js will run on a different port and as a separate process from rails).

If your app is highly dependent on realtime, and you're not planning on launching to a wide audience in 6 months, sure, rewrite in meteor.

Sure it is -- people are using Meteor in production already, and on multiple servers. Oplog tailing is the big story there.

Try option C first and see how that works out for you. Seems like the least amount of work.

1. Rails + SSE (server sent events) - http://tenderlovemaking.com/2012/07/30/is-it-live.html

2. Rails + Pusher

Those are the best solutions, at hand that would work well with Rails.

I wouldn't advise smashing a Rails app and a Meteor app together unless you have a solid case to do so (like migrating).

Rails, aside, I'm happy to here oplog has landed. 1.0 feels imminent, the tension is growing, even here in Toronto. Stop waiting sheeple, Meteor is great as is, and it's only getting better.

I guess it all depends on how "deeply" realtime your app needs to be.

For example, if you just want to add chat between users I think you'd be well-served by Firebase for the chat. If you want to roll-your-own, there are a million Node.js chat tutorials.

However, if you'll be making important changes to "real" data, as in anything you're persisting with ActiveRecord, b is your best bet.

Try using https://github.com/chrismccord/sync (real-time Rails partials with Pusher or Faye).

Or rewriting the app in Meteor is also a good option. I used to be a Rails developer but I am currently making the switch to Meteor.

ruby has Event Machine , Celluloid ,... you dont need meteor or nodejs for realtime apps, really,they are as good as any javascript server solution.

Can Event Machine or Celluloid give me reactive updates from my database made by a different process or service (like some background task with message queue)? Or are you bringing those as alternatives to EventEmitter of node.js?

They are a low-level Event Reactor and Actor implementation, respectively. Sure, you can built that, if your database supports it.

My point is: neither Event Reactor nor Actor model implementation are sufficient to make your database realtime (push updates to the application server). And the amount of work that was put into MongoDB actually doing it correctly and reliably is very undervalued in this thread.

That's why there are so few "real-time" solutions built around databases (NoSQL or SQL): Meteor, Firebase, GoInstant.

Always keeping everything in memory and updating clients as soon as the server have gotten a write is a different story with different complexity and different scaling limits. (but it can be done more efficiently utilizing RAM servers like Redis; Redis has built-in notification interface).

If you already have a database and just need to send stuff to the page, you can set up Faye or Pushpin alongside your app without having to rewrite anything.

If you like SaaS realtime, in addition to Firebase there's also PubNub and Fanout.io.

What about tubesock with Rails 4? https://github.com/ngauthier/tubesock

Reply on news.ycombinator.com