This document discusses supporting stateful and stateless clients when maintaining application state across multiple clients using a stateless protocol. It describes Mendeley's mission to transform academic research through reference management tools, social networking features, and an open platform. The document also discusses different types of application state, challenges with supporting offline clients, using PATCH requests instead of PUT to minimize bandwidth and prevent race conditions when updating data, synchronizing only differences between clients and servers, and allowing clients to store arbitrary data associated with resources.

1. Supporting Stateful and
Stateless Clients
Joyce Stack
!
@MendeleyStack
Maintaining application state on multiple clients using a stateless protocol is difficult.

2. Our Vision
• Our mission is to transform the world of academic
research….
• by delivering social collaboration tools
• forming virtual communities and
• driving innovation via our open platform
We wish to support industry and accelerate the progress of science with:
• Reference management tools
• Social network - thousands of professional research groups
• Provides access to our extensive catalogue & document statistics.
• These article level metrics can help researchers understand their scientific impact better of papers and how their papers are cited e.g. leads to
funding or coveted positions in faculties

3. What do we mean by state?
• Application state
• client-side state e.g. iOS and Android clients
• Resource state
• server-side state e.g. online web library
Application state:
• Unrealistic to have some clients be able to round trip to the server all the time.
!
Resource state:
• We have other online clients that change state frequently.

4. Offline is hard
Supporting offline is a major requirement from our users (discuss researchers)
!
We have cases of long offline periods (day, weeks, months and even seen years)
Application state drifts from server state due to multiple mutating clients so this leads to distributed state.

5. PATCH over PUT
{
"title": "Mutate iOS"
}
If-Unmodified-Since: Thu, 04 Sep 2014 13:43:01 GMT
{
"title": "Mutate JS"
}
• Resources have large representations
• Using a PUT is cumbersome and uses bandwidth
• Seldom going to change ALL metadata about a document.
• Prevent clients from making changes that has been changed by someone else since retrieving it by using preconditions
• Minimize race conditions

6. Sync only differences
• modified_since & deleted_since filtering
!
GET /documents?modified_since=2014-04-24T16:38:02Z
GET /documents?deleted_since=2014-04-24T16:38:02Z
!
200 OK
[
.. documents
]
We have a large collection of resources which don’t change all too frequently.
Clients shouldn’t have to send full JSON bodies over the wire just to stay up to date with latest changes, especially mobile.
Google’s Neil Fraser published a paper in 2009 about Differential Synchronisation.
Implementing real-time multi-user synchronisation systems is difficult and even harder to explain.
We know, we tried. So we needed something simpler.

7. Arbitrary client data
Folders:
!
{
"client_data": "{"sync_files":"notset"}",
}
!
!
Profiles:
{
"client_data": "{"sync_files": true,
"sync_publications": false}”
}
Allow clients to set an arbitrary blob of data in a field associated with a resource.
Tactical approach - settings associated with a particular resource, required by one client.
Avoiding clients having two back ends.
May roll it out to all other clients in the future.
!

8. Questions?
!
@MendeleyStack