Where we are right now

  • User defines their own datasource (Postgres)
  • User defines a schema (including the queries and mutations)
  • Users are responsible for writing resolvers (via SQL statements)


  • Bring your own database (so long as it's Postgres)
  • Support for multiple Data Sources (later on)
  • Integrate with existing applications



  • UX for writing resolvers is awful - InMemory almost impossible.
  • User must figure out how to map schema to their database - New or Existing.
  • Injection is really hard to mitigate. Current examples are insecure.
  • Conflict resolution and offline is very hard to solve because most solutions touch the data source - which we have no control over right now.

Where do we go next?

It all depends on who our target user is

Our Proposed Vision

  • Initial target - Community Users
  • Start with a Schema First approach with Auto Generated Resolvers with a goal of eventually supporting the 'bring your own data sources' concept.

Schema First - Main Disadvantage

  • Initially not as flexible
  • Will be tricky for users that already have data

Schema First - Advantages

  • Incredibly Simple. User defines their types and all CRUD resolvers are generated automatically.
  • Full control all the way down to the datasource layer.
  • Conflicts, Offline, Caching, Pagination are now much easier to solve.
  • Security Guarantees

Why - Strategic Decision

  • Initial Release is obviously going to be an MVP
  • What is the purpose of an MVP?
  • Schema first approach for MVP makes sense
    • It's focused and opinionated
    • It's easy to get started with
    • It's easy to demo and build content around
    • We can provide a roadmap which works towards a more flexible solution.


  • Wrap your existing data with a GraphQL API
  • It's pretty hard to use
  • It's has websockets so it's a sync service right? - Not really.
  • What about offline, conflicts and security?

Where we Are Right Now

Where we Could Be

  • More focused, end-to-end solution
  • Getting started would be very easy
  • Is an actual sync service
    • Offline
    • Conflicts
    • ... and more
  • Initially less flexible but we can work towards more advanced use cases

It all comes back to the question

Who are we targeting?

AeroGear Data Sync Proposed Vision

By Dara Hayes

AeroGear Data Sync Proposed Vision

  • 524

More from Dara Hayes