Upcoming Spikes for a Mobile Data Sync Service

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Upcoming Spikes for a Mobile Data Sync Service

David Martin
Hi all,

TLDR:
* Spikes around data sync will be starting in the coming weeks
* They will leverage GraphQL (mainly the work of the Apollo GraphQL [1] community).
* The spikes will attempt to answer questions mainly around
** offline capabilities on device
** how auth (Keycloak) will integate
** how re-useable and configurable a GraphQL server can be made.


Rationale:

There have been a number of discussions & investigations over the last few months about what is required for a Mobile Data Sync Service.
The FeedHenry Data Sync service has served us well, despite various shortcomings and issues over the years.
To help address the requirements below, we've decided to take a greenfield approach and build a new service & SDKs, which will have GraphQL as its backbone.

Some of the main requirements:
* easier to understand algorithm (fh sync has a sync loop on server & client, with independent frequencies)
* client & user auditing/tracing via remote logging (fh sync doesn't have this)
* requirement for realtime sync updates (fh sync uses polling)
* ability to define data schema & queries (fh sync doesn't care what you're syncing)
* better resiliency in cases where custom/developer code is executed (fh sync has potential for execution lock ups)
* abililty to query data beyond basic CRUDL (fh sync has listing, & reading by id)


Spikes & questions to answer:

1) Offline capabilities on Device
* What kind of offline querying is possible e.g. searching, when using the Apollo Client offline cache?
* How are mutations handled when offline?

2) How Auth (Keycloak) will integrate
* How can an auth/bearer token sent with graphql requests?
* How can the token be used by resolvers for authorisation checks?
* Can authorisation rules be configured/defined in a standard way by the developer, without having to write a custom resolver?

3) How re-usable and configurable a GraphQL server can be made
* What tools are available for defining a schema & queries?
* How could a developer map a schema to database (postgres?) tables & fields?
* How could a set of default (CRUDL) resolvers be generated (for postgres?) based on a defined schema?
* How to allow a developer configure custom resolvers, and how they'd get executed by the Data Sync Service (called over http? run in process?)


Thoughts, suggestions & questions welcome.
FYI, There have been some investigation & simple spikes already [2] [3]


--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (#aerogear)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev