Evernote Tech Blog | The Care and Feeding of Elephants
When we started to plan the Evernote service in 2007, we knew that we would need to support both "thin" clients (like web browsers) and "thick" synchronizing clients on the day that we launched. This forced us us to think about remote protocols and client APIs before we built any web GUI, rather than waiting a few months to staple an API onto an existing web service.
Our application forced certain requirements onto this API, including:
- Cross-platform. When we launched in February '08, we had production code using server-side Java, client-side Win32 (and WinMobile) C++, and client-side Obj-C Cocoa.
- Binary efficient. Clients synchronize structured Notes that may contain hundreds of embedded images totaling tens of megabytes. We wanted an API that would transmit a 15MB note using ~15MB of bandwidth.
- Forward/backward compatibility. Once someone has installed version 1.1 of our client on their laptop, we don't want to force them to upgrade the local software every time we extend our data model.
- Native bindings. We didn't want to write a bunch of parsing/marshaling code on every client. This is time consuming and error-prone, and tends to make #3 unlikely in practice.
- Standard-y and/or open-source. All things being equal, we didn't want to lock our service API into a single commercial ORB product for the usual reasons.
- Not gigantic. I'd prefer not to deploy a 1MB runtime with 200 classes on every mobile client.
Read full article from Evernote Tech Blog | The Care and Feeding of Elephants
No comments:
Post a Comment