 web application then. If you can talk to your database directly from the client instead of using REST or something to go through an API server, you just update your database and then it magically syncs. Do you see any parallels between things like Relay or Falcor or GraphQL? Like, these new paradigms that try and get around some of the pain points in building client-side applications and managing data. NOLAN: So, I think GraphQL and Relay are really interesting. I think they have a very different approach to PouchDB's. Theirs is more based on the idea I believe of having lots and lots of data on the server and then just lightly caching some of that on the client. The strategy that PouchDB employs is actually, it's more similar to projects like Hoodie, if you're familiar with that, which actually Hoodie is in fact merging with PouchDB. And so, they're slowly re-writing their engine to use PouchDB which is, it's been really fun to work with them. They're a really cool, cool team. JAMISON: I think my question wasn't clear enough. It's more… it's not, “Is it like Relay?” It's, “Is it trying to solve the same problem that Relay is trying to solve?” That you don't want to have to change an API server every time you need to change the data you need on your client. Whereas with, it seems like with Pouch, if you need different you just have it there already in the database. CHUCK: I think one thing that might clarify this a little bit is that CouchDB is from what I understand, a document database. It stores in JSON, or at least communicates in JSON. So, that being said, with Falcor and GraphQL you can have any arrangement of your data on the backend, where this is much simpler. And it's not necessarily… you can think about it more as connecting to something like MongoDB where you're going to get a document back instead of getting formatted data back from GraphQL or Falcor. NOLAN: Yeah, I know. Sorry, I think I understand your question a little bit better now, if I can try to provide [chuckles] a slightly better answer. JAMISON: Sure, sure. NOLAN: I think you're right that all of these projects are in the same family, in the same vein of saying, “Hey, we spend enough time writing custom REST servers that are different every time, for every single app that we write. And we always get it wrong and we always mess it up.” And it's always hard to do Ajax, right? How do you handle failed requests? How do you handle not re-syncing the entire database every time when all you need to do is just sync a little bit to get up-to-date with where you left off the last time that you stopped syncing? And all of these libraries solve that in different ways. PouchDB's model is as I was saying closer to Hoodie, which is in this Offline First movement, which I provided a link to that. But if you don't know about Offline First, definitely go to OfflineFirst.org, I believe it is, and read the little manifesto. It's really interesting. The idea is that you prefer the local store because the local store is fast and it is reliable and it's right there. And if you go offline or if you have intermittent connectivity or if you have bad connectivity, then it's totally cool, because you just sync in the background and then changes will come in when they come in. But you primarily interact with the local store, which is fast and it's right there. AJ: So, I just wanted to clarify. Because earlier you said this is an AP database, not a CP database. And I know you're referencing CAP theorem, which is that you have consistency, meaning that the data is always accurate all the time; availability meaning that the data is always accessible all the time; and partition-tolerant, meaning that the data can be in multiple place all the time. And you have to choose two of the three. So, if you wanted to clarify what do you mean that it's an AP database and why is that better or worse or different than a CP database? NOLAN: Yeah, that's a good question. You're right. I should take a step back and actually explain then. So, the CAP theorem as you said, yeah basically says that you have these three properties of distributed databases, whether they are consistent, available, or partition-tolerant. And the theorem says that you can only ever have two of them. And this doesn't mean that databases that choose a certain two and not another two are better or worse than other ones. They just have trade-offs and they are better in certain scenarios than other ones. So, I mentioned that MongoDB is a CP database. There are also some CA databases. Like, I believe Postgres qualifies as a CA database. But CouchDB and PouchDB are more similar to React and Cassandra in that they are AP databases. AJ: AP is also the eventual consistent model, right? NOLAN: Yes, exactly. It doesn't mean, yeah. So, when it says that it's not consistent, that doesn't mean that it just tells you whatever and you can't [chuckles], you can't trust it at all. Just totally unreliable. It means that… AJ: It means that an hour after your order on Amazon you get a notification saying, “Actually, that's out of stock. Sorry, buy something else for your niece for Christmas.” NOLAN: [Laughs] Yes, that is a negative example of eventual consistency, absolutely. But I think actually… JAMISON: But, at least you could place that order. NOLAN: That is true, yeah. JAMISON: [Chuckles] NOLAN: I think, I think another… CHUCK: Well, and the other thing is that for consistency, there are usually mechanisms put around the different trade-offs. So, if you have an AP database, a lot of times they require a certain level of consistency when they make the request. In other words, they'll ask more than one server or they'll ask all the servers and get a consensus. Or they'll force some kind of update when they do the request. I know Cassandra all of those things and React does several of them as well. And so, it really just depends. Just because you're saying availability and partition-tolerance are the guarantees of the system, it doesn't mean that there aren't other mechanisms built around consistency. And so, just keep in mind that yeah, that can happen if you're only asking one server and you're okay getting old data back. In other words, in this case it's inventory data. But in a lot of cases you'll actually wind up making some kind of constraint on consistency. It's just that it's not the focus of the trade-offs in that particular database. NOLAN: Yeah, well said. These categories are definitely fluid. And there's some wiggle room between them. I think another good way of thinking about how CouchDB works at least is that its replication model is very similar to Git. So, Git is decentralized and Git works very, very well offline. And CouchDB has a very similar model where you can sync the changes but then if there are merge conflicts you resolve the merge conflicts. And if you don't feel like resolving them right now, you can resolve them later and continue working locally and do whatever branching and forking locally that you want to do. AJ: So, can you give me an example of that? Because when I think of ignoring merge conflicts in a database that has user data, I need an example to understand where is it appropriate to ignore it and where is it like, you must resolve it right away. NOLAN: Sure. So, CouchDB by default doesn't have any built-in conflict resolution strategy. It basically lets you do whatever you want with the built-in default being that it will choose a winner that is arbitrary but agreed upon by all the nodes. So, that's a lot to take in. [Chuckles] So, let me actually try to provide a more concrete example. So, let's say that you're building a collaborative document editor or something, like a wiki. And let's say you want it to work offline. So, let's say that I'm modifying the same document as my friend Joe. And I whip out my mobile phone and I start making a modification to this wiki page. And then I hop onto the subway. And anyone who lives in New York knows that as soon as you go down to the subway, you have zero bars and you're lucky if you get any internet connectivity at all while you're riding the subway. So alright, I go on the subway. My changes have not been pushed yet. I was editing one version of the document. And then Joe simultaneously, he's on his desktop. He's got a super reliable fast connection. He starts editing the same old version of the document as me and he starts writing this long, series of rambling paragraphs or whatever. What you don't want, is you don't want that when he hits save, he pushes it to the server, what you don't want is that when I step off the subway, I whip out my phone, and the change that I was going to push gets pushed and it overwrites whatever he was doing. And so, what CouchDB and PouchDB will do is that they will recognize that the same version, the same revision of a document was modified by two different users. And it will actually just replicate those conflicts everywhere. So, in