Thursday, February 7, 2013

A Distributed RESTful Architecture

Kaplan Flashcards - Developing an Architecture for Mobile Devices

Daniel Negri
Kaplan Test Prep


MCAT® Flashcards for iOS
Flashcards is a system, designed for mobile devices, that allows students to play with questions and answers. The application is based on scores of how many questions, represented as cards, the student is able to tag as "Known", "Unknown" or "Unsure" in a deck. Many projects at Kaplan stores data in different types of databases, including Relational Models, NoSQL or even plain XML files. The content is composed by exams like MCAT, LSAT, GRE, and students profiles. These applications place very different demands on storage, both in therms of content type, authoring, and presentation layout. In this article we start to describe the simple model provided by the RESTful Flashcards API architecture, which gives clients dynamic control over consuming data, presenting different layouts and formats. I describe the design and implementations of the architecture created to accomplish cross-platform mobile Flashcards clients.




MCAT® Flashcards - Web Version

Introduction


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.

Architecture Characteristics


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:

1. Page Rendering

That is, the logic to generate dynamically web pages or views, like JavaServer Pages (JSP), was moved from the server to the client. Today, with the advance of HTML5 and Javascript engines, it became very efficient render pages inside the client.

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. Sessions

Avoiding sessions leads to a more scalage and usable architecture. We are keeping the clients state on the client.

3. Caching

REST 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.

Summary


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.

Monday, February 6, 2012

Startup - mkCRM - First Stage

A Open Source CRM for Mary Kay Consultants

At my first startup I created one open source social CRM software for Mary Kay consultants. Available online for free and inspired by SalesForce, Teambox, Spree. Supported by the open source community as well as the sale of our commercial products.

The Site




The Application





The Mobile Version

mkCRM Mobile is an HTML5 app platform that allows you get access to CRM APIs by multiple platforms like iOS, Android, Windows Mobile, Blackberry, and Symbian (we have plans to port for webOS and Bada too). I will put some pictures soon.


References

Link: http://www.mkcrm.com.br/
Source-code: https://github.com/danielnegri/mkcrm-rails 


Internet Banking


Improvements

SicoobNet Pessoal is a fantastic Internet Banking environment for desktop, and mobile users. But it has some areas for improvement. In this post, I’ll explore some improvements to how responsiveness and monitoring is integrated into the workflow and how Internet Banking could provide specialized interfaces for multiple platform system and frameworks.

Desktop version




Mobile version




Tablet Version




Credit Card Monitoring

Realtime Credit Card Monitoring System

As another example, I’ve taken the Credit Card Monitoring  and mocked up what it would look like with the SRTB - Receptor of Banking Transaction System. Simply adjusting the styling of your controls can have a considerable impact on complexity.

The CDO - Online Credit Card System

Credit Card Monitoring System



Banking Monitoring System

Realtime Transaction Monitoring


Sicoob Monitoring Platform was released a couple years ago with a significant number of user interface changes. It’s always interesting to look at the direction that’s taken with the monitoring UI because it’s often used as a testing bed for future iterations of the Sicoob Platform user interface. I thought it would be fun to spend a weekend thinking about the Monitoring visual design and giving it a minor refresh.

The Monitoring Online System




The Consolidated Data System Analysis 




Interface complexity is an issue every engineer wrestles with when designing a reasonably sophisticated application. A complex interface can reduce user effectiveness, increase the learning curve of the application, and cause users to feel intimidated and overwhelmed.

I’ve spent the past year redesigning a particularly complex application with my primary focus being on reducing complexity.