Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    droganov
    @droganov
    yes, we’ll need to create virtual operations for joins somehow
    Nate Smith
    @nateps
    i just don't see the appeal
    graphQL is massively easier to implemetn when you are just doing one way communication in that format
    it is all about reading data from the DB and not writing to it
    ShareDB is a two way system
    so you'd have to define a two way transform and do it on the ops
    yeah, it is totally possible and i have thought about similar kinds of things before (there are some really nice advantages to being able to do join like things on the server instead of the client and getting more efficient filtering)
    but it requires some pretty deep support for doing some crazy projection stuff that does not seem worth it
    figuring out how to make sense of multiple versions of multiple docs combined into a single object, yada, yada
    it could be cool, but there are much more practical intermediate steps in that direction
    droganov
    @droganov
    I wish I knew shareDB API better :-)
    multimple versions could be done, as well as index events but it will be individual coding project, with a unique schema
    Nate Smith
    @nateps
    i think it makes more sense to stick with the current model of using the DB query language for now and make a really solid foundation before expanding scope in such a large way
    trust me it is not a simple thing
    i'd much sooner tackle rewriting projections so they are pragmatic to define per query
    right now that is hard because you have to define the projection on the server
    droganov
    @droganov
    By the way, I saw there is a third query argument, is it for projections?
    Nate Smith
    @nateps
    no
    you can't define projections per query
    projections can only be defined as a sort of virtual collection
    they are entirely namespaced, which is a limitation because of how ops need to isolated
    a better projections solution is a much more practical version of something like GraphQL
    droganov
    @droganov
    Yes with GraphQL you don’t need projections and technically you could request it within a query
    Nate Smith
    @nateps
    GraphQL is a solution with very different constraints. It is easy enough to implement when it is read only and last writer wins, but when you are doing OT it is massively more complicated to implement something that looks like that
    GraphQL is projections
    droganov
    @droganov
    Yes, but when I’m reading for roadmaps for realtime updates support, I don’t see synschronisation is mentioned there
    That’s how I came to this idea
    Nate Smith
    @nateps
    correct. OT is very hard. others are not likely to do it
    droganov
    @droganov
    It would be great to have them all: projections, joins, sync updates
    :-)
    Nate Smith
    @nateps
    more realistically, i'd like to have a useful and stable platform that makes great applications for users
    not going to jump on GraphQL just because it is hip
    it is not the most expedient solution to the problems
    droganov
    @droganov
    no-no, you need to finish OT indeed
    Nate Smith
    @nateps
    so we'll first improve projections in a way that is more pragmatic and iterate toward something that is as useful as graphql
    but it might not be quite as easy to use for developers
    the point is more to let people build great products for users than to make developers lives easier
    ShareDB lets you build stuff you literally cannot build in other systems
    so i'd like to double down on that
    if you'd like to get invovled, i'd recommend biting off something simpler and practical like building a DB or PubSub adapter
    lots of people would like to use ShareDB with different databases and redis is the only pubsub option at the moment
    droganov
    @droganov
    I’m thinking of making something simple like readonly graphql driver to learn API and figure out the problems
    and the to offer solutions and discuss them
    Nate Smith
    @nateps
    well it would be easier to do read only, but you'll still need to transform the ops
    feel free to give it a go, but honestly i don't think it is likely to be possible very easily
    droganov
    @droganov
    sure I don’t expect it to be easy :-)
    Nate Smith
    @nateps
    :-)
    droganov
    @droganov
    I like the prize
    Nate Smith
    @nateps
    i do think it would be cool
    just a warning that i personally think it would be very difficult
    droganov
    @droganov
    OK Nate thank you :-)
    I’ll pay more attention to plan B, and do some test project with GraphQL
    Nate Smith
    @nateps
    ok, good luck!