Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Nate Smith
    @nateps
    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!
    droganov
    @droganov

    by the way, as you’re here a scaling question from derby chat

    if you have a situation when: many users subscribed to many queries (let’s say 10 users listen for 1 query) and fire many events. Like gitter chat for example.

    Is it true that it will be a On3 problem when we use racer?

    Let’s say we had a server with 1000 queries and 10K users, it got busy, we scaled, and now we have 2 busy servers with a 1000 queries and 5K users on each
    Nate Smith
    @nateps
    what is the scaling bottleneck is likely to vary by application and data model
    ShareDB has a number of optimizations at a number of levels of the stack to deal with scaling, so it really depends on a lot of things and how you use it
    no complex system has a simple big O notation breakdown unless you clearly define the scope of the problem or it is heavily dominated by a single long pole
    in some ways, ShareDB has better ways to deal with scaling than Meteor, for example, because it uses operations sent over pubsub channels that you can customize
    whereas meteor has to tail the full op log and consume it and you can end up with every server needing to process every message
    Nate Smith
    @nateps
    but both meteor and sharedb have a bunch of different optimizations around when to re-poll queries and when you can figure stuff out in memory vs going to the db when you can just check a single doc vs running the whole query again
    it just depends on a ton of stuff
    and to be honest, the limiting factor could be parsing JSON or the database or network or a lot of stuff
    you just have to test, measure, and improve
    droganov
    @droganov

    yep, I see there are different scenarios and updates are optimised. But is it possible to optimise situation when many users create many messages in different chat rooms? Do we need index events to do that?

    If it’s true that currently any single create op triggers all queries to poll, then in our worst scenario we might see a phisical limit of how many queries node can run in a given period of time, and if create ops fired faster than node is able to throttle them it’s gonna be a bottleneck.

    We can split node to several processes, but if there many users in a room, then we’ll have scaling problems.

    In a real world if we would work on the app like this gitter chat, would we use query subscriptions, or maybe it would be more efficient to use a chat room to store the array of latest message id’s and use those id’s to subscribe to messages without a query?

    kwafoawua
    @kwafoawua
    Hi, is someone on?
    kwafoawua
    @kwafoawua
    ._.
    Jonas Liljegren
    @aigan
    Are where a chat for ShareDB?
    Risto Novik
    @riston
    as I understood the old ShareJS users should move over to ShareDB?
    Jonas Liljegren
    @aigan
    ShareJS is for collab text editing. ShareDB is for json data.
    Nate Smith
    @nateps
    We can chat about both here
    ShareDB has a larger scope, but it is all in the same family and uses the same OT types