imslavko

I've heard about RethinkDB for the first time in 2013[1] and at the time it was described as "MongoDB with joins and auto-sharding".

I also heard that one of the initial "killer-features" of RethinkDB was supposed to be a stored history, just like a big persistent data structure (in my understanding, similar to Datomic). In the video[2] a lot of time was spent describing the benefits of an append-only structure.

[1]: https://www.youtube.com/watch?v=H9G1dCMTWps [2]: https://www.youtube.com/watch?v=uDHc3lkr3Ns

As the sibling comment said, you do the same way you scale anything else: add more servers that replicate the same data. As it becomes to large, shard your publications depending on type. Meteor's livequery works better serving a lot of similar subscriptions, so at some point you can have multiple server types each taking care of one scope.

The point the article is trying to make is that their application has so little server-side business logic, they can avoid it all together and not write any server-side code.

Meteor, despite its ease of syncing subsets of data to users, gives you full control to execute RPCs and run custom logic, talk to other backends, send emails, etc.

I am not a heavy iPad/tablet user. Scrolling through the list made me think the author might benefit from a laptop/tablet hybrid as a lot of apps are for automation/desktop environment that laptop OS already provides.

Can node-tar untar .tar.xz? This is what Meteor uses to parse tarballs.

https://github.com/npm/node-tar

I think a lot of career paths on the site are showing the ultimate goal, and then a "path" to it, the career ladder.

The concept of subscriptions is completely separate from the router you use. At some point you would need to define who can subscribe to what documents, in any system with private data. It is called ACL.

I think it explicitly says that it uses the same idea as Meteor's:

> Rather than writing database queries in the backend and exposing API endpoints to the frontend, these solutions allow the frontend to directly access the data layer (secured by a permission system) using the same query API that backend services have access to.

I've built a RethinkDB-Meteor integration using ReQLite and Meteor's stack: (https://github.com/Slava/meteor-rethinkdb).

I see that your TODOs list has "Optimistic UI updates", I worked in this direction and figured there are multiple things blocking such architecture in RethinkDB:

- https://github.com/rethinkdb/rethinkdb/issues/4307

- https://github.com/rethinkdb/rethinkdb/issues/2727

Something you might want to consider when you decide to implement it.

My mother uses her Dell laptop with an Ubuntu installed on it. It is usually great to maintain from my part, as all she uses is Chromium and the files explorer. I just update the software sometimes.

But something that started happening in the latest versions of Chromium is driving me nuts. Every time I talk to my mother in my native language in front of the laptop, the "Ok, Google" functionality activates and starts the search of the "parsed" English sentence in Google.

I tried to disable it but failed to find how.

Vim also has a similar optimization: when a file changes, Vim only runs syntax highlighter on a visible part of the text + some buffer in both directions.

I looked at the source code and it seems that it mostly glues socket.io with Redis/Memcached. What did I miss? How exactly is it more scalable than anything else?

The front-page looks really cool.

A common pattern is to indicate when the data is persisted on the server but still show a predictive update first. Take chat systems as an example: Whatsapp will show your message you just posted immediately but then it will indicate its persistence by showing you two checkmarks on your message.

Meteor's architecture allows you to have slightly different models in the "predictive" mode and "persisted" mode.

More beginner-friendly articles about Latency Compensation are available on the blog of Discover Meteor: https://www.discovermeteor.com/encyclopedia (the top section)

Can you please explain what dev.ssa branch is implementing and how is it going to change the performance of the compiler?

Hello, I worked at a RethinkDB integration for Meteor (https://github.com/Slava/meteor-rethinkdb) for a week as my "hack" project.

I must say, there seems to be a lot of work to be done, before we can call this implementation "stable" for kind of quality bar Minimongo (https://github.com/meteor/meteor/tree/devel/packages/minimon...) has in Meteor. It is not uncommon to see Reqlite queries to fail because of simple bugs.

Not to say that the library is hopeless, Neumino did a lot of grunt work that makes it easy to test and contribute. See this thread where we discuss the missing functionality: https://github.com/neumino/reqlite/issues/3

(I work at Meteor).

There have been some discussions with Asana (asana.com) teams who are building their new data store with a DDP API published for their clients.

This is great! I didn't doubt that Firebase will roll out features to paginate and sort data. I also don't doubt that Firebase will implement filtering in the future. Great work.

Meteor's security model allows app developer to validate any operation or RPC going through, based on the arguments or userId (by writing JS code). Also, the published set is controlled by publications, allowing to publish only filtered out data with specific fields.

Unlike Firebase, Meteor actually allows you to send "first top 20 guest posts from November" as an example. The filtering can happen on the server, before sending the data and the data model usually fits into a sets of documents in set of collections. In Firebase, everything is part of a big subtree that is not filterable (the last time I checked).

Firebase is a good choice for keeping your real-time data. But knowing its limitations is as important as knowing its strengths.

I have two Quora answers on similar questions:

- http://www.quora.com/Which-startups-use-Meteor-in-production - http://www.quora.com/What-open-source-software-uses-Meteor-f...

No, Meteor's server-side architecture uses MongoDB's replication log that is analyzed to get updates.

Michel, I thought you were playing with this idea? ;)

We like Vue.js! It has a different scope and a design around POJO rewritten with es5 getters/setters.

Btw, Evan, the creator of Vue.js is working at Meteor now.

If you like this, Manacher's algo is very similar to z-string matching algo: http://codeforces.com/blog/entry/3107

Here is my implementation of an in-memory Redis based on JS objects that supports Lists, Strings and Hashes commands. This implementation is mostly used as an in-memory cache in the browser to sync state from the server in the Meteor framework:

https://github.com/meteor/miniredis

This is a nice little problem, I had fun solving it.

For those of us who are familiar with TopCoder, CodeForces or, perhaps, ACM ICPC, this should be daily bread and butter on prime numbers and data structures :)

Here is my solution if you are curious: https://gist.github.com/Slava/74276f5b7889a1d68a71 - computes the result in 400ms

Edit: hah, looking at the problems discussion board I took a very bruteforce approach, other people solved utilizing math, I used priority_queue for no particular reason :)

It is a great example of a bigger open-source Meteor apps in a wild along-side with Telescope (http://www.telesc.pe/) which is also well documented and is extensible.

They are different in purpose and features. If anything, Meteor would use Node-Webkit to assist building desktop apps, the same way Meteor is using Phonegap to build mobile apps.

WAMP came up on Meteor's mailing list some time ago. One would compare it with Meteor's own pub/sub and rpc protocol called DDP (https://www.meteor.com/ddp).

DDP has clients in Objective-C, Java, Python and some other major languages, too: http://www.meteorpedia.com/read/DDP_Clients

https://groups.google.com/forum/#!searchin/meteor-talk/wamp/...

I found it following this tweet:

https://twitter.com/Raynos/status/551243347994497024