Supporting Stateful and Stateless Clients

Joyce Stack !

@MendeleyStack

Maintaining application state on multiple clients using a stateless protocol is difficult.

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

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.

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.

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

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.

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

!@MendeleyStack

Questions?