Kaplan Flashcards - Developing an Architecture for Mobile Devices
Kaplan Test Prep
|MCAT® Flashcards for iOS|
|MCAT® Flashcards - Web Version|
Over the last years we have designed, implemented, and deployed a distributed API system for managing structured data for Kaplan. The Flashcards API is designed to reliably scale to different sources of contents and thousands of machines. The Flashcards API has achieved several goals: wide applicability, scalability, high performance, and high availability. The API is used mainly by two Kaplan pilot projects, Flashcards Mobile and Flashcards Web, but is extended to custom authoring tools like the Flashcards Content Manager. The API clusters used by these products span a multiple range of configurations, that servers JSON to handle mobile native applications and browser based clients requests.
The Flashcards API provides a transparent interface to multiple content repositories performing content conversion, versioning, in-memory cache implementation. It provides a simple data model that supports dynamic control over data layout and format, and allows clients to reason about the locality properties of the data represented in the underlying storage. Data is indexed using users metadata, clients can control dynamically how to present it to the user.
The Flashcards architecture was created with coordinating a set of constraints that attempts to minimize latency and network communication while at the same time maximizing the independence and scalability of components. The Representational State Transfer (REST) fits very well once its became a consolidated style developed to accomplish all these points.
|First Stage: A slice of an example database that stores questions and answers. The application receives multiple HTTP requests, it reads the content from a stand-alone database and return serialized JSON responses, asynchronously.|
In a first stage we settled on this minimalistic model after examining a specific use-case, handle requests to different types of mobile platforms and browsers using a unified protocol.
We removed almost all business logics from the server, placing constraints on connector semantics. Important points moves from the server to the client like:
Most of times, clients utilize fluid layouts and customized components to present a better user experience. Aside the page rendering, a solid communication protocol allows native Android, iOS applications to exchange data with the server.
2. SessionsAvoiding sessions leads to a more scalage and usable architecture. We are keeping the clients state on the client.
3. CachingREST enables the caching and reuse of interactions. The server sets a group of HTTP Cache-Control directives. That is, it delegates the responsibility of caching to specialized systems like the browser or forward proxy.
This post makes part of a detailed group of implementations. I'll show how all components fit together and share more details on what's coming next. Stay tuned.