Making Direct Messages Reliable and Fast • Hacker News Board

Re: Making Direct Messages Reliable and Fast

#11

Post by sambal » Sat, Jun 15, 2019, 10:15 AM UTC

dmitriid wrote: post #10

mxstbr wrote: post #5

If anybody else needs this kind of system, most GraphQL clients (at least in the JavaScript ecosystem) handle all of this out of the box or can be extended to work this way with minimal effort. They have a client-side cache for the whole app that you can optimistically update, all network requests run through that, it handles rolling the updates back when responses come in, etc. Examples in the JS ecosystem that I am…

> If anybody else needs this kind of system, most GraphQL clients Well, the client is probably the easiest and the most boring piece of the puzzle. What you do in the backend matters.

What’s done in the backend matters slightly less in the thread of an article entirely concerned with the client.

https://cdn-images-1.medium.com/max/2400/1*ttu76ysGchnhH3CyT...

Re: Making Direct Messages Reliable and Fast

#12

Post by invasionofsmall » Sat, Jun 15, 2019, 10:19 AM UTC

bluesign wrote: post #8

If the order of requests are retained, does it mean that if ‘mark thread as read’ request somehow fails on server side, all other requests will wait for it to be send until it gets success from server?

In my experience it is reasonable to wait in the sense that it's basically a middle layer where all the requests pass through. Also, if, as an example, there is a missing connection, you don't allow people to keep doing things. We did it on our app but you can see the same on FB app where you see a "lost connection" alert.

Re: Making Direct Messages Reliable and Fast

#13

Post by bjackman » Sat, Jun 15, 2019, 10:57 AM UTC

bluesign wrote: post #8

If the order of requests are retained, does it mean that if ‘mark thread as read’ request somehow fails on server side, all other requests will wait for it to be send until it gets success from server?

Yeah I wondered if instead of maintaining a global ordering of all requests, it wouldn't be better to just require timestamps in requests that will need to be ordered. Then you only need partial orderings, which you can resolve when marging the optimistic state, only among those requests that actually need to be ordered, and requests don't need to block each other.

Edit: although now I think about it, if you go that route you effectively have to do the same timestamp ordering resolution on the server too.. so probably more complicated than just keeping a global ordering!

Re: Making Direct Messages Reliable and Fast

#14

Post by mistahenry » Sat, Jun 15, 2019, 11:25 AM UTC

raverbashing wrote: post #6

Even while being a part of the industry, it is amazing how much technology it takes for things to work seamlessly, and also how many gotchas there are in the way

It’s also rough when building new applications. Instagram/Facebook level UX are the expectation from the layperson.

For instance, if you add photo upload to your app, people will complain if it doesn’t support multi-photo upload, varying sizes, and client side photo filters.

The bar is set very high. It’s taken me a whole year to build a website + app combo in my spare time that has all the expected bells and whistles on top of the app’s regular functionality (social login, site tours, optimistic states, skeleton loading, push notifications, global type agnostic search, etc). MVP took two months but every time I showed to people, the reaction was always “why isn’t it autosuggesting content? Where is the explore page? Why can’t I login with my Facebook, why aren’t you saving drafts while I create posts in case my computer crashes, etc).

It really is a ton of effort to turn a simple idea into reality

Re: Making Direct Messages Reliable and Fast

#15

Post by dnlgl » Sat, Jun 15, 2019, 12:03 PM UTC

matlin wrote: post #4

This seems a lot like an eventually-consistent database. I think you could accomplish something similar with something like CouchDB or Firebase that provide conflict resolution between local and server state automatically. I'm wondering what the advantage is here?

My strong guess is that they have just reinvented a client component of an eventually consistent data store, and in this context the blogpost is actually embarrassing for them. I wonder if they will notice further problems and reinvent causal consistency and vector clocks next.

Re: Making Direct Messages Reliable and Fast

#16

Post by axxl » Sat, Jun 15, 2019, 12:09 PM UTC

bluesign wrote: post #8

If the order of requests are retained, does it mean that if ‘mark thread as read’ request somehow fails on server side, all other requests will wait for it to be send until it gets success from server?

We did something very similar to this and our solution was to have 2 classes of requests, those that require global ordering (creation of posts etc) and those that don’t. These second classes of requests can contain dependencies to each other to have a local ordering but don’t block any other requests.

Re: Making Direct Messages Reliable and Fast

#17

Post by spunker540 » Sat, Jun 15, 2019, 12:47 PM UTC

mistahenry wrote: post #14

raverbashing wrote: post #6

Even while being a part of the industry, it is amazing how much technology it takes for things to work seamlessly, and also how many gotchas there are in the way

It’s also rough when building new applications. Instagram/Facebook level UX are the expectation from the layperson. For instance, if you add photo upload to your app, people will complain if it doesn’t support multi-photo upload, varying sizes, and client side photo filters. The bar is set very high. It’s taken me a whole year to build a website + app combo in my spare time that has all the expected bells and whistle…

It’s really hard to build consumer-facing products solo these days!

I recently “gave up” on building my own site and just pay for a Shopify site now (only an option if you’re in e-commerce) and I’ve been blown away by how easy and high quality it is, and $30/month is honestly way cheaper than the time it’d take me to create and maintain a similar site. There are plenty of alternatives to Shopify that are competitive too I understand.

Perhaps it is worth your while to explore outsourcing so that your own time is not the limiting factor!

Re: Making Direct Messages Reliable and Fast

#18

Post by noir_lord » Sat, Jun 15, 2019, 2:57 PM UTC

spunker540 wrote: post #17

mistahenry wrote: post #14

Earlier quoted context omitted.

It’s also rough when building new applications. Instagram/Facebook level UX are the expectation from the layperson. For instance, if you add photo upload to your app, people will complain if it doesn’t support multi-photo upload, varying sizes, and client side photo filters. The bar is set very high. It’s taken me a whole year to build a website + app combo in my spare time that has all the expected bells and whistle…

It’s really hard to build consumer-facing products solo these days! I recently “gave up” on building my own site and just pay for a Shopify site now (only an option if you’re in e-commerce) and I’ve been blown away by how easy and high quality it is, and $30/month is honestly way cheaper than the time it’d take me to create and maintain a similar site. There are plenty of alternatives to Shopify that are competitive…

It possibly takes more effort than it should do to do many of these things, in a way the very difficulty of building these things serves to re-enforce the requirement to have large teams.

In a way the fractured nature of the web serves the big organizations with the resources to build things that are 'clean' experiences across every platform.

While I doubt it was by design it certainly benefits them now.

Re: Making Direct Messages Reliable and Fast

#19

Post by xhgdvjky » Sat, Jun 15, 2019, 4:55 PM UTC

bjackman wrote: post #13

bluesign wrote: post #8

If the order of requests are retained, does it mean that if ‘mark thread as read’ request somehow fails on server side, all other requests will wait for it to be send until it gets success from server?

Yeah I wondered if instead of maintaining a global ordering of all requests, it wouldn't be better to just require timestamps in requests that will need to be ordered. Then you only need partial orderings, which you can resolve when marging the optimistic state, only among those requests that actually need to be ordered, and requests don't need to block each other. Edit: although now I think about it, if you go that…

timestamps are rarely the answer

Re: Making Direct Messages Reliable and Fast

#20

Post by xhgdvjky » Sat, Jun 15, 2019, 4:57 PM UTC

mistahenry wrote: post #14

raverbashing wrote: post #6

Even while being a part of the industry, it is amazing how much technology it takes for things to work seamlessly, and also how many gotchas there are in the way

It’s also rough when building new applications. Instagram/Facebook level UX are the expectation from the layperson. For instance, if you add photo upload to your app, people will complain if it doesn’t support multi-photo upload, varying sizes, and client side photo filters. The bar is set very high. It’s taken me a whole year to build a website + app combo in my spare time that has all the expected bells and whistle…

this is why using a popular framework is critical even if it is flawed. there is support for so much stuff you just need to install