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)

Advantages

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

Disadvantages

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

Summary

• 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

It all comes back to the question

Who are we targeting?