How does this help with offline-first applications? They can run offline for several weeks without seeing any internet. A cache doesn’t help here. The app will be closed and restarted during that period. We need persistence.
The client uses the same graphql queries supported by dgraph. How do you think will we be able to use pagination, filtering and all the other dgraph stuff on non-graph databases? We decided for dgraph because its “schema-first” and easy to use. Our complete code is build around the fact that the dgraph schema is the single source of truth. Using any other database than dgraph would require:
- to implement a translation layer dgraph-style-graphql-queries ↔ SQL (incl. pagination, filtering, @cascade etc pp) this is a complete nightmare because it basically means to re-implement dgraph from scratch
or - use two different react apps that use different APIs a complete nightmare because it will mean double the frontend-dev work and lead to unmaintainable code
Sorry, this is nowhere close to a solution. I’d be honestly happy if it was though.
Why would we need windows licences when we build windows apps? We’re not using windows server.
Well, what does this mean now? What will change? Does it only affect new features? Isn’t the core of dgraph still cross-plattform and therefore new features will also be available? Will only bugs be fixed? Will they not? We’re happy to dedicate a portion of our development to windows dgrap to keep it running and write PRs. But we need clarity here.
This discussion is currently only held between us so maybe someone else from the team or community can also give their opionion? @chewxy @amaster507 maybe?
I’ll also open a new discussion about how offline-first apps should use dgraph - maybe we can channel our efforts and find a solution to this.