The Trello Tech Stack • Hacker News Board

Re: The Trello Tech Stack

#91

Post by roel_v » Fri, Jan 20, 2012, 3:25 PM UTC

strictfp wrote: post #83

" sending changes to Models down to browser clients". _Down_ to the client? He draws the stack with the client on top and the storage at the bottom, and then says 'down to the client'? I have a collegue who also does this. I never figured out why. Can anyone explain possoble reasoning behind this wording?

Because the client DOWNloads stuff, presumably. To me it makes perfect sense, servers send stuff 'down' to clients, regardless of a stack figure where stuff is arranged otherwise. Those two are orthogonal.

Re: The Trello Tech Stack

#92

Post by alexchamberlain » Fri, Jan 20, 2012, 3:33 PM UTC

meatmanek wrote: post #80

wavetossed wrote: post #79

Earlier quoted context omitted.

Yes!!! The development cycle of software like MongoDB, RabbitMQ and so on, is much faster than that of Debian or any other Linux distro. The Debian package is fine for dabbling or low volume use, but for any serious app, you MUST go direct to the developers and use their latest stable release. That is what they support best on their mailing lists, and that is where most bugs are already fixed. A lot of software devel…

> why would you use old obsolete releases of mission critical software? "If it ain't broke, don't fix it" Because it's mission critical, and you can't afford for it to break. Once you hit a certain complexity, upgrades almost always break something: APIs change. Undefined behavior changes. New bugs are introduced. A feature critical to your app starts performing worse. The above changes break something else you depen…

Equally APIs are backwards compatible, behaviour is defined, bugs are fixed, performance is improved and software becomes more compatible with other software.

Re: The Trello Tech Stack

#93

Post by gbog » Fri, Jan 20, 2012, 3:55 PM UTC

jonknee wrote: post #35

edw519 wrote: post #32

Use things that are going to work great in two years. This is one of those remarks that is obvious to someone who knows what it means but mysterious to someone who doesn't. So what does it really mean? - Don't use a technology that, no matter how good, is just too niche for widespread adoption? - Don't use a technology that we'll have trouble finding programmers to support? - Look for stuff that will take better adva…

I have a feeling that Javascript based NoSQL backed web development is going to be just fine in two years. Quite possibly the standard stack for a large percentage of projects.

I have the opposite feeling. I understand very well the reasons some are pushed away from relational data and data normalization, and set theory formalism. Some are need for change. Some are fears of over engineering. Some are because the trend is to Twitter-like blobs. A big reason is because doing things right is a pain in the...

And come the only valid reason, from my POV: We have to denormalize and avoid using the powers of relational data sometime because we do not know how to store (read and write) conveniently huge amounts of relational data; yet. Notice the "yet"? Well, I think it is a technical problem, that may not be so far to find its solution.

One example of a solution showing its nose recently: "Google plus with your world". It do strike me that the fact that any query I make to the closest Google server respond /instantly/ to any random word with a join on a very possibly monstruous matrix of all the likes of all my circled users.

I don't know how they do store this, where and how they denormalize, but in any case it seems to me to be just "relational data as usual".

So in two years, if there is a "bigreldata" software allowing to have a Postgres sitting happily on 1000 T of relational data with instant reads and writes, I would certainly use that with a layer of python glue on the server feeding a slim client than a blob datastore with NoSQL handcuffs and a fat client with 20 libs of third party Javascript code.

I may be wrong, however, and would love more insights on this.

Re: The Trello Tech Stack

#94

Post by davesims » Fri, Jan 20, 2012, 4:08 PM UTC

bigiain wrote: post #81

davesims wrote: post #65

Not to pick on him, because I think the overall received wisdom on new tech has shifted and morphed a great deal over the last few years, no doubt including Joel's...but I can't resist pointing out that, my how times have changed... http://www.joelonsoftware.com/items/2006/09/01.html In other words, it's nice to see Joel greenlight something like this, I'd say it's kind of a sign of the times in terms of the industry…

To Joel's credit, that was over 5 years ago - which is, like, 35 dog-years ago (which are even shorter than tech-years).

Agreed, completely, just pointing out, again, time's is different...

Re: The Trello Tech Stack

#95

Post by jonknee » Fri, Jan 20, 2012, 4:49 PM UTC

gbog wrote: post #93

jonknee wrote: post #35

Earlier quoted context omitted.

I have a feeling that Javascript based NoSQL backed web development is going to be just fine in two years. Quite possibly the standard stack for a large percentage of projects.

I have the opposite feeling. I understand very well the reasons some are pushed away from relational data and data normalization, and set theory formalism. Some are need for change. Some are fears of over engineering. Some are because the trend is to Twitter-like blobs. A big reason is because doing things right is a pain in the... And come the only valid reason, from my POV: We have to denormalize and avoid using th…

Google is not using a RDBMS to get Google Plus content on SERPs. What makes you think they are? It works just like the rest of Google on their leading edge kit: bigtable, GFS, etc. Amazon is able to personalize their site for each customer quite a bit more than Google is and relies on similarly horizontally scalable architecture.

Google talked a little about how personalized search works in a paper about BigTable, it's worth a review:

http://static.googleusercontent.com/external_content/untrust...

> Personalized Search stores each user's data in Bigtable. Each user has a unique userid and is assigned a row named by that userid. All user actions are stored in a table. A separate column family is reserved for each type of action (for example, there is a column family that stores all web queries). Each data element uses as its Bigtable timestamp the time at which the corresponding user action occurred. Personalized Search generates user profiles using a MapReduce over Bigtable. These user profiles are used to personalize live search results.

Regardless, even in your scenario with the perfect RDBMS, the future web stack wouldn't change much. You still have the same issues with blocking and different languages for client and server. As a developer myself, it doesn't matter at all to me if my call to a method is backed by a relational, document or key/value database. It's all an abstraction somewhere. It just needs to come back quickly and be easy to scale up.

The big change we're seeing is the client becoming primarily JS driven and the server more or less relegated to sending/receiving JSON. It's a much richer experience, but a pain when the toolsets on either end are completely different.

Re: The Trello Tech Stack

#96

Post by mnutt » Fri, Jan 20, 2012, 8:45 PM UTC

meatmanek wrote: post #80

wavetossed wrote: post #79

Earlier quoted context omitted.

Yes!!! The development cycle of software like MongoDB, RabbitMQ and so on, is much faster than that of Debian or any other Linux distro. The Debian package is fine for dabbling or low volume use, but for any serious app, you MUST go direct to the developers and use their latest stable release. That is what they support best on their mailing lists, and that is where most bugs are already fixed. A lot of software devel…

> why would you use old obsolete releases of mission critical software? "If it ain't broke, don't fix it" Because it's mission critical, and you can't afford for it to break. Once you hit a certain complexity, upgrades almost always break something: APIs change. Undefined behavior changes. New bugs are introduced. A feature critical to your app starts performing worse. The above changes break something else you depen…

Yes, especially with a database you can't just pull in new updates and expect them to work. It involves reading the release notes and doing a lot of testing. (much of it is automated)