Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How We Make Trello

blog.fogcreek.com

Post reply on HN
Print view View original

111–120 of 120 posts

Re: How We Make Trello

#111

Post by Cthulhu_ »

thedufer wrote: post #62
copergi wrote: post #58

Earlier quoted context omitted.

>In my opinion if there's one thing a reader should take away from this it should be that Single Page Apps and separation of server and client are The. Best. Thing. Ever Those are two orthogonal things. All my sites have a complete separation of presentation from code and access a nice API to get data. Including the ones that are purely HTML and have no javascript at all. Single page apps are good for things that are…

Not completely orthogonal. The way Trello is set up, client and server releases are completely unrelated and don't have to know about each other. The web app is almost as separate from the server as the iOS/Android apps, which isn't really possible if you're rendering html in the server. That said, I agree that making something into a single page app just to get this separation isn't going to be useful.

I dunno, if you've got a good API, server-side HTML rendering is just another client, just like client-side rendering would be.

The trap a lot of developers fall into is going around the existing API for server-side applications though, thinking they'll get more performance by (for example) going directly to the persistence layer. That's how most server-side apps are written, actually; api and front-end tightly coupled.

Re: How We Make Trello

#112

Post by hamidpalo »

bib971 wrote: post #92
bobbygrace wrote: post #20

Earlier quoted context omitted.

I hope Doug writes a more technical post about the multi-client build/release process. We have unit tests for the whole API and very few automated tests for the front-end. Client builds are stored in S3. We use mongoDB and will do backfills if necessary (pretty rare). Rolling back the client is just pointing the stable branch to another build.

Bobby, you said every app is a client of the API. I notice Trello.com consumes API from https://trello.com/1/xx while an OAuth client (from one of your Jsfiddle examples) consumes from https://api.trello.com/1/xx?key=xx&token=xx . I suppose the former just passes through to the later? If so, does the former needs to pass over the key and token (I suppose you can generate on the fly based on auth cookie)? I'm trying t…

Trello dev here.

The web client (trello.com) has a cookie that has the auth information. The actual code executed for both examples is identical.

Re: How We Make Trello

#113

Post by hamidpalo »

13hours wrote: post #109
upops wrote: post #25

Earlier quoted context omitted.

On the Trello Android team we have a similar workflow to the web client and server developers. We merge in to a shared development branch when we have a complete feature or bugfix. With git's --no-ff this allows us to see when a new feature was implemented, and when bugs pop up we have a clear list of intersections where they could have been introduced. Our workflow is roughly based on an excellent post by Vincent Dr…

I'd love to hear more about the Android team's CI tools. What do you build with? What do you test with? If you can build some kind of SaaS Android CI system, you'd probably make heaps of cash. Android CI is just enough of a pain to do yourself that people would pay for a one click type solution.

Another Trello Android dev here.

We use gradle for building. The actual app is split into two, trello-app and trello-lib. Anything that can be done w/o Android like SQLite caching, API calls, etc., is done in trello-lib which is a plain Java library. It makes the dev cycle much faster since you can write a unit test and run it in a second.

We don't have CI setup yet. For the server we use something custom but will most likely be moving to Buildbot and with that we'll also setup Android CI.

Re: How We Make Trello

#114

Post by hamidpalo »

steveklabnik wrote: post #50
thedufer wrote: post #34

Earlier quoted context omitted.

To add to what bobby said, changes to the API are far more likely to be additions rather than actual behavior changes (except for bug fixes, which of course all clients handle fine). This makes it easy; old clients just ignore new routes/arguments.

Thank you for this. I hope more people come to understand this more nuanced understanding of change. Please talk about it more!

Another Trello dev here.

Basically, we have many clients that are consuming the API, including our mobile apps. We never change the published interface so that if you're getting some board fields that will always work. This means that we don't change the types of fields (for example string vs object) or the names of fields since that changes the published service contract.

What we do instead is add more fields. A very good example of this is emoji. We added emoji support a while back and instead of changing the "text" fields to be objects or embedding HTML (gah) into them we added another field called "textData" that has the extra info.

This is copy/pasted from an actual call for getting card actions:

        "textData": {
          "emoji": {
            "daft": "https://trello-emoji.s3.amazonaws.com/4f820a995a03e8e82d134ac4/ae846ca70bf7aa95dd3330b8fd1c70cb/art-daft-punk-steampunk-951631.gif"
          }
        },
        "text": "Custom emoji! :daft:"
This may not be sustainable in the long term and if it's not we'll version the API if we have to at that point. So far though, the API has proven itself to be very well designed and adaptable (thanks to @d_lec)

Re: How We Make Trello

#115

Post by [deleted] »

smacktoward wrote: post #12
badman_ting wrote: post #4

It's almost comical how nobody at my company would ever take a project this seriously. Good for them, Trello is awesome.

Everything I've ever heard about Fog Creek indicates that they take their people seriously. Which probably makes them more likely to take their work at Fog Creek seriously. Funny how that works, huh? A lesson many, many other companies could profit from.

[deleted]

Re: How We Make Trello

#116

Post by DEADB17 »

thedufer wrote: post #86
DEADB17 wrote: post #71

Earlier quoted context omitted.

> which isn't really possible if you're rendering html in the server. You can have a front-end web server that is also a client of the API server and keep the separation as if it were any other API client. This is the approach I'm taking in my current project since I have to support some obsolete browsers, but more generally it lends itself to a cleaner decoupled architecture

That type of double-server architecture isn't one I'd considered. Very interesting.

It is, let me know if you want more info

Re: How We Make Trello

#117

Post by thedufer »

trustfundbaby wrote: post #98

What I'm interested in is the mechanics behind how they know were to send a user based on their channel (beta/stable/alpha). We wanted to do something like this, but we couldn't figure out how to route users to the right app server either using AWS ELBs or nginx proxying ... admittedly we didn't really spend a lot of time thinking about it though.

We do that decision-making inside the web servers. It only affects the client you get, so when someone requests a page we do a lookup on the logged-in member to decide which channel they get. API reqs don't care what channel you're on. No need for any fancy nginx proxying/etc.

Re: How We Make Trello

#118

Post by thedufer »

bib971 wrote: post #92
bobbygrace wrote: post #20

Earlier quoted context omitted.

I hope Doug writes a more technical post about the multi-client build/release process. We have unit tests for the whole API and very few automated tests for the front-end. Client builds are stored in S3. We use mongoDB and will do backfills if necessary (pretty rare). Rolling back the client is just pointing the stable branch to another build.

Bobby, you said every app is a client of the API. I notice Trello.com consumes API from https://trello.com/1/xx while an OAuth client (from one of your Jsfiddle examples) consumes from https://api.trello.com/1/xx?key=xx&token=xx . I suppose the former just passes through to the later? If so, does the former needs to pass over the key and token (I suppose you can generate on the fly based on auth cookie)? I'm trying t…

api.trello.com is just a CNAME to trello.com, in case that difference was confusing you. The authentication part is taken care of differently depending on the kind of tokens we get (the web client uses a cookie) but we turn that data into a standard authentication object and the rest of the route uses the same code regardless of request type.

Re: How We Make Trello

#120

Post by bib971 »

thedufer wrote: post #118
bib971 wrote: post #92

Earlier quoted context omitted.

Bobby, you said every app is a client of the API. I notice Trello.com consumes API from https://trello.com/1/xx while an OAuth client (from one of your Jsfiddle examples) consumes from https://api.trello.com/1/xx?key=xx&token=xx . I suppose the former just passes through to the later? If so, does the former needs to pass over the key and token (I suppose you can generate on the fly based on auth cookie)? I'm trying t…

api.trello.com is just a CNAME to trello.com, in case that difference was confusing you. The authentication part is taken care of differently depending on the kind of tokens we get (the web client uses a cookie) but we turn that data into a standard authentication object and the rest of the route uses the same code regardless of request type.

Got you. This is very helpful, thank you!
Post reply on HN