56 // Sync

Metadata

• Author: Metamuse
• Full Title: 56 // Sync
• URL: https://www.airr.io/episode/627ceea4ac33d2000f9f653b

Highlights

Speaker 2: It is not physically possible to have acceptably fast software if you have to go anywhere beyond the local SSD certainly if you’re going to a data center in Virginia or whatever your totally hosed. So it was very important to incorporate this performance capability into muse. Speaker 0: Yeah, that article was eye Speaker 1: opening for me and that Speaker 0: you connected the research Speaker 2: around human factors, things that Speaker 0: looked at what level of latency Speaker 1: you needed for something to Speaker 2: feel snappy Speaker 1: and responsive Speaker 2: and then separately the speed of Speaker 1: light, which is how Speaker 0: sort of the maximum possible speed Speaker 2: that information can travel and if you add those together or Speaker 1: do very simple Speaker 2: arithmetic on that, you can instantly see it’s not about having a faster Speaker 1: network connection, you Speaker 2: literally cannot Speaker 0: make something that will Speaker 2: feel fast Speaker 1: in the way that we’re Speaker 2: talking about. If you have to make a network round trip.

Speaker 2: maintainable and so on than a traditional rest server. But a big difference between a traditional rest application and the music player is that there are two completely separate layers, what we call the network layer and the app layer. So the network layer is responsible for shuffling these binary blobs around the transactional data, the ephemeral data and the big binary assets and the server knows absolutely nothing about what’s inside of them by design, both, because we don’t want to have to re implement all of them use logic about boards and cards or whatever in the Speaker 0: server. And also because Speaker 2: we anticipate eventually end end encrypting this and at that point, of course the server can’t know anything about it, it’s not gonna be Speaker 1: possible. Speaker 2: So that’s the networking layer and then if you sort of unwrap that you get the (Time 0:40:18)review

Speaker 1: because it means Speaker 0: that a lot of bugs that Speaker 2: could otherwise easily Speaker 0: sneak in if Speaker 1: we were using kind Speaker 0: of a generic Jason Speaker 1: framework we’re going to find Speaker 0: out about Speaker 1: when we hit the please build muse button instead of the, I’m running news and I randomly hit a bug Speaker 0: and that Speaker 1: kind of Speaker 0: confidence early on in the build process Speaker 1: has been really important for us Speaker 0: as well to find Speaker 1: and fix issues before they even arise. Yeah, to my mind this is Speaker 2: the correct way to build network Speaker 1: clients, you have a schema Speaker 2: and it generates type safe code in whatever language Speaker 0: you want Speaker 2: to use. This Speaker 1: is enormous benefits to that Speaker 2: approach. I think we’re seeing it Speaker 1: with this amuse Speaker 2: and again, I think Speaker 1: more systems, Speaker 2: even more traditional B two B type systems are moving in this direction. By the way, everyone always made fun of (Time 0:42:44)review

Speaker 2: is more like a bag of time stamped attributes. We Speaker 0: have an entity and attributes Speaker 2: a value in a timestamp Speaker 0: and Speaker 2: from that it can be more Speaker 0: challenging to work with that model Speaker 2: but it’s Speaker 0: infinitely flexible. Speaker 2: You can sort of put whatever model you want on Speaker 0: top of that. And Speaker 2: it Speaker 0: works well for Speaker 2: creating a generic database system. You couldn’t have a Speaker 0: generic Speaker 2: postgres for example that could run any application. You need to first create tables that correspond to the actual application you’re trying to build. Whereas with Speaker 1: an atom Speaker 2: oriented database you basically have one huge table which is Speaker 1: Adams. So Speaker 2: it’s useful again for having this slower moving, more stable synchronization layer that handles moving data around that you build the application on top Speaker 0: of that moving quickly. Speaker 1: Yeah Speaker 0: and like we talked (Time 0:45:43)review