Meteor vs. stack behind trello

[tenzan]

For the task that trello does, do you think Meteor would do better or not?

http://blog.fogcreek.com/the-trello-tech-stack/

PS: Please feel free to edit the question.

[serkandurusoy]

I doubt they are still using the exact same stack or exact same set up, but that was around the time when meteor was also being born, out of the need to make it very easy for developers to set up a very similar stack.

Throw in redis (there are atmosphere packages for that) on meteor and you’ll basically have set up the “same” stack. There of course are a lot of implementation differences.

Trello’s stack perhaps benefits from being barebones in the scaling area.

Meteor also scales well, we don’t currently have a production example with few million users and billions of documents on the db, so it is hard to make a comparison just yet.

[robfallows]

barebones

Strangely, very nearly relevant. Trello use backbone for their front-end. Barebone would have been funnier though

[shock]

I think it would be easier to prototype in Meteor, as to test various principles and patterns.
But for production it is hard to answer as there is not so many projects which can provide us with info how Meteor handle thousands of connections etc.

[tenzan]

barebones

Did you mean backbone ?

Also from the link above:

we can store a card’s data in a single document in the database and still have the ability to query into (and index) subfields of the document.

So, they didn’t split nested fields into a separate collections, while having them realtime…

[robfallows]

@tenzan

So, they didn’t split nested fields into a separate collections, while having them realtime…

Well, that’s a design decision they made. You can make the same decision for your project, or not. As long as you can deliver the results you want to your users in an agreed time, it only affects how you code your application.

[tenzan]

When it's about many-to-many relations in DB

mongodb supports 1:n relations which is nested (embedded) document. Unfortunately, that's one area where Meteor limits you. Meteor's livedata package diffs collection changes on the topmost fields of a document, therefore if you embed another document, the changes to those documents will not be equipped with fine grained reactivity. Furthermore, any change to any embedded document will invalidate the parent collection's computations. Therefore, in Meteor world, you do 1:n relationships with …

as per the answer in the link above, in case of Meteor I’ll have to split into a separate collection…

[tenzan]

doubt they are still using the exact same stack or exact same set up

I’ll try to find out

[shock]

If we are talking about default live pub/sub of data without composite publications or how was the package name.

[tenzan]

Sorry, I did’t get what you mean as I’m new to Meteor.

What do you mean?

[serkandurusoy]

@tenzan

I did not mean backbone by saying barebones but, yeah @robfallows’ pun is quite in place

Regarding subdocuments, Meteor’s DDP server’s livedata package makes some sacrifices to increase overall reactivity performance and one of them is not tracking subdocuments.

But if you were to mimic that, you could by writing your own diffing function, or tap into observechanges on the server side and publish manually. It would be really troublesome though and would be much easier to just separate the collection.

[hwillson]

Just posting this here because I love stackshare.io - http://stackshare.io/trello/trello

This is just a rehash of the original Trello stack blog post (so as mentioned it’s quite likely out of date), but the details are laid out nicely.

[tenzan]

because I love stackshare.io

Thanks, I didn’t know about this site.

[skini26]

This is a clone made with Meteor : https://github.com/libreboard/libreboard

[tenzan]

This is a clone made with Meteor : https://github.com/libreboard/libreboard

I noticed, that libreboard doesn’t look and feel as flexible as trello and it’s very slow.
Did you notice that?

Not sure if this a Meteor problem or its hosting…

[babrahams]

I found the opposite. I thought it was really snappy.

[tenzan]

I found the opposite. I thought it was really snappy.

Really?!

Ping from Japan:

$ ping libreboard.com
PING libreboard.com (107.22.210.133): 56 data bytes
64 bytes from 107.22.210.133: icmp_seq=0 ttl=34 time=175.477 ms
64 bytes from 107.22.210.133: icmp_seq=1 ttl=34 time=175.251 ms
64 bytes from 107.22.210.133: icmp_seq=2 ttl=34 time=175.150 ms

$ ping trello.com
PING trello.com (192.230.65.4): 56 data bytes
64 bytes from 192.230.65.4: icmp_seq=0 ttl=54 time=119.943 ms
64 bytes from 192.230.65.4: icmp_seq=1 ttl=54 time=118.244 ms
64 bytes from 192.230.65.4: icmp_seq=2 ttl=54 time=118.176 ms
64 bytes from 192.230.65.4: icmp_seq=3 ttl=54 time=118.158 ms

But, in general, for some reason, I didn’t feel it’s better than the Trello.
Just my personal impression…

[babrahams]

From Beijing:

$ ping libreboard.com
PING libreboard.com (107.22.210.133): 56 data bytes
64 bytes from 107.22.210.133: icmp_seq=0 ttl=40 time=252.261 ms
64 bytes from 107.22.210.133: icmp_seq=1 ttl=40 time=251.587 ms
64 bytes from 107.22.210.133: icmp_seq=2 ttl=40 time=248.455 ms
64 bytes from 107.22.210.133: icmp_seq=3 ttl=40 time=248.803 ms

$ ping trello.com
PING trello.com (192.230.64.4): 56 data bytes
64 bytes from 192.230.64.4: icmp_seq=0 ttl=51 time=277.277 ms
64 bytes from 192.230.64.4: icmp_seq=1 ttl=51 time=277.746 ms
64 bytes from 192.230.64.4: icmp_seq=2 ttl=51 time=278.576 ms
64 bytes from 192.230.64.4: icmp_seq=3 ttl=51 time=277.386 ms

Haha… anything under 600ms feels snappy behind the Great Firewall …

[tenzan]

Truly, I give thumbs up to Trello’s look-and-feel.

[serkandurusoy]

it’s very slow.

Well you are referring to ping times and that’s not a software stack related issue. Such comparison would only make true sense if made on the same servers/isp.