What is MongoDB? How does it work? How is it different than a standard relational database? How does it fit into a modern web app? This week, the panel gets the answers to these questions and more when they talk to Joe Karlsson, Software Engineer and Developer Advocate at MongoDB.

Follow JavaScript Jabber on Twitter > @JSJabber

Special Guest: Joe Karlsson.

I just am scared shoving blue gack in between my keys. I mean, you could just stop at shoving blue gack in between my, and I think whatever it is that comes next is appropriate.

 

STEVE_EDWARDS: Hello everybody and welcome to another episode of JavaScript Jabber. I am your host today, Steve Edwards. And joining me on our panel is Amy Knight. 

AIMEE_KNIGHT: Hey, hey, hey from Nashville. 

STEVE_EDWARDS: AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo, sunny pleasant Grove. Woohoo. 

STEVE_EDWARDS: Yeah. Here in Portland, it's rainy and cold. It was great through Sunday and then everything get the fan. And our victim, excuse me, guest today is- 

AJ_O’NEAL: Victim is appropriate. 

STEVE_EDWARDS: Yes. He's returning for more punishment. And this is Joe Carlson from MongoDB. Yay, Joe, how are you? 

JOE_KARLSSON: Yoo-hoo, yeah, Yoo-hoo from Minneapolis, Minnesota. It sounds like Minneapolis is the warmest city out of all y'alls, which is kind of surprising, but I'm so glad to be back. I'm shocked I wasn't permanently banned from this program. So thanks for having me back here. 

AJ_O’NEAL: Make people feel that way. But it's actually the shocker that I am not permanently banned from this program. 

JOE_KARLSSON: That's good. 

STEVE_EDWARDS: Hey, we may get into a great street fight today. 

 

We'll see how that goes. If you're a front-end developer looking for remote work, then I recommend G2i a React and React Native focused hiring platform that will connect you directly with their clients that need your skill set. What makes G2I a unique hiring experience is that they spend the time marketing you to their clients of your choice. G2I is a team of engineers that technically vets you upfront. If you pass their vetting, their clients have agreed to skip their initial interview process, saving you time and energy getting your next gig. They take care of all the hard work for you so you can get focused on development. To join G2I, go to g2i.co and apply.

 

STEVE_EDWARDS: Last time Joe was here, which was a few weeks ago, I lose track, they all run together. After a while, we were talking about IoT, the internet of things. But this time we wanted to talk about MongoDB, which is Joe's specialty because he works for MongoDB. 

JOE_KARLSSON: Yeah, 

STEVE_EDWARDS: it turns out you learned a little bit about the tool from working at that company. Amazing how that works. 

JOE_KARLSSON: Yes. 

STEVE_EDWARDS: So why don't you give us a little bit intro again and your role at MongoDB and yeah, I'd write into what you're gonna talk about.

JOE_KARLSSON: Yeah, absolutely. So, um, obviously I'm a, I wouldn't be here if I wasn't a JavaScript node fan. I've been programming, using it for forever. I love it. And I love teaching about it too, but I've been working at MongoDB now for about a year-ish. I'm not too long, but I've been a technical lead on some of the largest e-commerce sites in the world and kind of manage those and massive scalability issues with those too. I do developer advocacy at MongoDB. And which means I just get to like teach people about databases or help them wherever they're at, right? Like, so. Just kind of talking, hanging out, working on cool projects. Like last week I was talking about my IoT kitty litter box, which I got paid to build, which I'm still, blows my mind that that's a job that someone can do. I have a hard time explaining that to my parents sometimes, what I'm doing. Anyway, that's my job, work for MongoDB. I just get to talk about cool stuff I'm building. 

STEVE_EDWARDS: All right, so you have a talk from SQL to NoSQL a gentle introduction for developers. So we're just going to use that as a framework for today. 

JOE_KARLSSON: Yeah. 

STEVE_EDWARDS: So why don't you start out and start walking through, and then we'll follow and discuss as things arise. 

JOE_KARLSSON: Yeah. So I guess for people tuning in today, I want this to be a discussion for people who are... Or this is going to be helpful for people who are just starting out with MongoDB. And a lot of people who have been building databases have probably like...Obviously, you've probably heard of MongoDB, and if you've been building them, you've probably been using SQL. So we're going to be focusing on what MongoDB works like and looks like and how to use it compared to an SQL database. I also want to be talking about some advantages and disadvantages of using MongoDB compared to SQL, and I want to be talking about... This is probably the most important part, but what are the biggest mistakes I see developers making when they come from an SQL background to no SQL? Because I see a lot of people just trying to do like a copy pasta, like rows, columns, and tables, and try to just jam that into a MongoDB database, which usually doesn't work that well. It may work fine for a little bit, but it doesn't scale well. So I'd love to like talk about what those are. So everyone joining into, even if you've been using MongoDB for a while, I'm hoping you'll still get some new stuff out of it because you probably, you may have been using things incorrectly and I hope that can start pointing you in the right direction. 

AJ_O’NEAL: This, this is where I'm going to get the correction. I'm going to be like, but blah, blah, blah. And you're going to be like, cause you've been using Mongo like an idiot. 

JOE_KARLSSON: Yeah, it's your fault. No, no, no. I don't like it. It's totally natural. Right? Like, it's not natural. 

AJ_O’NEAL: None of this is natural. 

AIMEE_KNIGHT: I do almost feel like it would be good to start off with. Like maybe AJ can go over like the pain points that a lot of people raise up. And then you could work on dispelling those pain points because for whatever reason... 

JOE_KARLSSON: Like what everyone's experience level is in this podcast with MongoDB and SQL. 

AIMEE_KNIGHT: I have not used it in production, but used it. That's what we used when I did the bootcamp way back when like six years ago. 

JOE_KARLSSON: Love it. Yeah. I come from a pretty heavy SQL database. You know, my SQL Drupal, that kind of experience I've used Oracle, SQL server, you know, over the years, various versions of a standard SQL database. I did mention to you, just for learning purposes, I took Mongo's free class on Mongo for Node developers a few years ago, so I got a little familiarity. Now, I have worked with quite a lot with Apache Solar, which is the same. It's more of a key value store that you can put JSON in, I guess, as one of the options. 

STEVE_EDWARDS: NoSQL, I love that. 

JOE_KARLSSON: I worked a little bit with Form.io, the guy we had on last week, Travis Tidwell, a little bit, but that's pretty transparent. You know, I'd say 99% of my experience is SQL. Love it. Yep. I think that's super common too. And what about you, AJ.? 

AJ_O’NEAL: So I, I've spanned the spectrum a little bit, obviously because of my age, I started with SQL because quote unquote, no SQL did not exist for a few more years. 

JOE_KARLSSON: Yep. 

AJ_O’NEAL: I, I thought the no SQL thing was just super cool when I think, I think there was a presentation on it in a Python meeting back in. I don't know, 2008, 2009, maybe 2010, but like right in that timeframe when it was the big buzzword that was like, you know, it was the blockchain of its day. Right. Totally. And it's a web scale. Yeah. That's when that like the, is it web scale website came out and stuff like that. Yep. Hilariously. Isn't that the site where no matter what you put in, it says yes, except if you put in Mongo and says no.

JOE_KARLSSON: I do not know, 

AJ_O’NEAL: but there's a website that's something, it's a parody site that's something like, is it web scale? And you can just type in gibberish and it'll say something like, it's basically like a magic eight ball. It always gives positive answers unless you type in Mongo and then it says absolutely not, not ready or something like that. So it's some sort of troll site. I think it's isitwebscale.com. Hopefully that's not a dirty site. 

JOE_KARLSSON: Hopefully cross your fingers. Well, I want to say- 

AJ_O’NEAL: Well, because they get bought up. They get bought up and then they get turned into dirty sites. You have to let it expire. Just put ads on it. I don't know. That's hilarious. 

JOE_KARLSSON: Well, I want to say too, like your, everyone's experience here, I think is pretty common, right? Like Amy's, you're just coming out of a bootcamp. I think teaching MongoDB is a super common database out of bootcamp. And a lot of times what I'm seeing too is people like learned it a couple of years ago and they haven't really touched it since. I do want to, I want to touch on some of the upcoming changes or changes that have gone on that you probably don't even know about, so that's awesome. And then.

AIMEE_KNIGHT: Oh, I should say too. And I did play a little bit with Stitch, which is pretty cool. 

JOE_KARLSSON: Yes, absolutely. Yeah, yeah, yeah. Yeah, super excited about that too. I know that no one knows about that one either, which is great. And then Steve, AJ, your stuff too is like super common too, right? Just coming from an SQL background. 

AJ_O’NEAL: And I use CouchDB and I use just plain JSON files all the frigging time. 

JOE_KARLSSON: Yes. 

AJ_O’NEAL: And I used, what's that thing that's not BerkeleyDB, but it's Google's thing that's basically BerkeleyDB. 

JOE_KARLSSON: Dynamo? 

AJ_O’NEAL: What?

JOE_KARLSSON: No, AWS to Dynamo. Nevermind. 

AJ_O’NEAL: No, the, the, the little one, the one that's like in Chrome and a bunch of other SQLite. No, not SQLite. Although I'm a big fan of SQLite, love SQLite, love Postgres. The two most advanced databases on the market would totally opposite as a spectrum. No, the level DB level DB. The one that everybody's building, like their little embedded databases on top of that, you know, where SQLite is not the right tool for the job or is difficult to compile or whatever.

JOE_KARLSSON: Totally. Yeah, that makes total sense. Yeah. No, those are great. Those are awesome. So I think those are like totally great. So it sounds like we're all over the map on it too. It sounds like everyone's got a little bit experience with it. Obviously everyone's heard of it. But it sounds like people haven't really touched it maybe for a couple of years or kind of like haven't been paying attention to it, which I think is again super common too. But yeah, I don't know. Should we jump in? What do we, what should we talk about first? We could talk about maybe we could talk about some updates on it or we could talk about. 

AJ_O’NEAL: I think we should highlight a little bit what the job of a database is. 

JOE_KARLSSON: Oh, that's a great place to start. 

AJ_O’NEAL: Well, because, because so with the whole NoSQL movement that's, you know, was back in that timeframe, it was, it was really misleading because it was posed as you're either Pro SQL or you're NoSQL. 

JOE_KARLSSON: Right. 

AJ_O’NEAL: And really, this is a broad spectrum. You've got key value stores, you've got index binary JSON, which I think is what Mongo is. 

JOE_KARLSSON: Yep. 

AJ_O’NEAL: You've got Hybrid databases, like basically every SQL database that people use, meaning Postgres and MariaDB slash MySQL, are hybrid databases that have NoSQL as well as SQL. And then you've got document databases like what was CouchDB, I don't know if it's still called CouchDB. But each one of these things serves a different purpose. So I think maybe an overview, if you would journey that.

JOE_KARLSSON: Totally. Yeah, that's a great one. 

AJ_O’NEAL: What's going on in this space and why? Why are there six different kinds of databases? 

JOE_KARLSSON: Mm-hmm. Well, I think, I mean, MongoDB came about, right? Because it was trying to solve problems that with like scalability and working with the data directly. Yeah, I guess we can give a quick overview of like, because you touched on key value stores, which are basically just like an example that would be, oh my gosh, I'm blanking on it. What's the example? 

AJ_O’NEAL: LevelDB, 

JOE_KARLSSON: LevelDB. Love it, level. Yeah, so that's just accessing key value pairs, but like accessing deeply nested data. You can do, but it's more challenging. It's not natively going to do that. Also key value stores, generally speaking are more in memory, in memory type databases too. So if the server gets shut off or whatever, that data gets lost, but it's for really quick retrievals. 

AJ_O’NEAL: Um, that'd be, that'd be your Redis. Well, no, Redis has backup as well. 

JOE_KARLSSON: Yes. That's actually what I was thinking of too. 

AJ_O’NEAL: Memcached, Memcached I think is key value, but you've got things like, uh, Berkeley DB and LevelDB. Berkeley DB was the basis of MySQL for like until MySQL five or six or something.

JOE_KARLSSON: So, yes, I guess I don't know much about the history of that one too. I'm still learning. There's like so many databases out there, but I mean, the thing is too, like, I think we can all agree that like storing data is like one of the most essential parts of any business and like persistent data and every application is using it. And we're seeing a massive increase in the amount of data that we're saving. And who's working with that and what the purposes of that data being persisted are. And I think that we're seeing like massive specialization in those databases with that huge increase in. Just data needs from businesses. And I think it's important to like having the flexibility based on the needs of your application, what kind of database you need and like how to tune it based on your application. And I agree, it's totally overwhelming. It's confusing. I work for MongoDB and there's a lot of people are working in that document database space right now. And it's hard to even tell what the differences between those are, right? Just specifically. 

AJ_O’NEAL: document databases are one where I think they are a very niche. Like document and key value, I think are kind of on the niche ends of either you're going to have to build a lot of stuff or you literally want to exclude a lot of stuff on purpose. And I feel like Mongo and say Postgres, we're kind of in a similar space with like different approaches. One is like the schema ish approach. Mongo is schema ish. And then Postgres is a combination of schema full and schema less. Cause you can have schema list binary. Well, they even now have schema ish and then you can use JSON stores. 

JOE_KARLSSON: How funny. I didn't realize that. It's going to be flexible. People may not know this too, but I think when people think of MongoDB, they think schema-less, but we've called it flexible schema. You can define how much control you want to have over your schema on your database. For example, with RDBMS, typically, every column has to have a defined schema and rules surrounding that. With MongoDB, you can have and enforce those rules as much or as little as you want. Some columns are like...You're making a form, like everyone needs to have a first name, last name, and an address, but a credit card number is optional or whatever, whatever else you want to be saving, right? So you can be more flexible with that schema. 

AJ_O’NEAL: I’m going to argue that you have the same flexibility with SQL database, but the SQL heads that come out of the pedagogy of the 1960s, it's kind of part of the religion of SQL that you should never have an untyped type.

JOE_KARLSSON: Yes, 

AJ_O’NEAL: it's certainly you have the flexibility, but I think you get a lot of angry old neckbeards in the community that when you choose to use a SQL database in a schema ish fashion, they would yell at you. And I think that's mostly gone away. Like, because now, you know, Postgres, you can have the hard schema, but you can also have schema ish with, with the JSON H store. I don't know if that's the right name of it. 

JOE_KARLSSON: Yeah, I know what you mean though. 

AJ_O’NEAL: But I know, so I think you get flexibility in both, but it's more marketable in something like Mongo because it doesn't have a tradition of neckbeards screaming at you for, you know, whether it's- 

JOE_KARLSSON: These are the rules and you're, get out of here if you don't follow the rules. My apologies to the neckbeards. We love you neckbeards. Please be kind to us, okay? Can I give a specific example too of when flexibility is important? So I talked last time about my IoT Katie litter box, right? I think IoT is a great example of when a flexible schema is actually a great use case. So for example, I was prototyping out my box and I added a new sensor to determine when the door was open or not for maintenance mode. And I was able to easily update my time series schema with that new data. So I didn't really care about my old time series data. Like it's old data anyways. Great. Who cares? I could have optionally gone through and like, knowledged out or whatever, but whatever time series data expires, gets old quickly. And that was a good use case for having a flexible schema on the sensor data. 

AJ_O’NEAL: I'll hand it to you. Like unless you made it a JSON store field, you would not, your database would not like you suddenly changing all of the columns. 

JOE_KARLSSON: Oh, totally. Yeah, exactly. And, but, and it's, so I was able to like build it faster and stuff, I do that. But like, yeah. And coming from a, like that legacy RDBMS or relational database management system or SQL databases, much easier to update and fix. And it didn't end up being a big deal. Even if I deploy that to production, you could work with the product team. You could argue that that wasn't something that you need to persist long-term. 

AJ_O’NEAL: So it sounds like you do put, like you said, well, the old data, I don't care about it. So you're saying, well, because the front end isn't going to request this data, I can just update stuff in the data model basically is broken. Like it would cause a serious critical failure, like try catch, throw error, explode. But you're just saying, well, I don't care about the old data. So I don't need to invest the time to make it fault-tolerant against looking at data that I know personally, I'm not going to look at again. 

JOE_KARLSSON: Totally. And again, you could totally run a migration if that's important, but for like the use case, I just have a dashboard that shows the last seven days of data. And for my unique application, that's totally fine. That's acceptable. Yep. Absolutely. So it depends. I think the point is like this all boils down to it's like with, with our SQL, you have like the rules you have to follow, right? Which are like well as a research and establishing great, but they're pretty inflexible. And you can get as flexible or inflexible as you possibly want with SQL, or no SQL, excuse me. And particularly with MongoDB, based on the unique needs of your application. The other point I think it's really important too, and I would love to come back again and talk about this in greater detail, but it's a data modeling, right? With like a traditional SQL database, we typically, there's normalization, right? We can normalize, we typically normalize in the third form. And what that basically means is 

AJ_O’NEAL: Joe, what does normalize mean? 

JOE_KARLSSON: Yes, exactly. Um, so normalization basically means we're splitting up data into separate tables. And, and we're doing that so we don't have to repeat data. If you had to like put the same data in the same table, we have to have repeated data and that would cause more data and we have to do more updates, more chances for full tolerance. 

AJ_O’NEAL: So I'm going to give people an example of this. If you think about a spreadsheet that you have in Google docs or heaven forbid Microsoft office a contact list, the city is going to be repeated 100 times. The state is going to be repeated 100 times. Some of the other information that's in that spreadsheet is going to be repeated. Normalization is you say, well, I'm going to create another spreadsheet where the ID of the state is 1 through 50, the ID of the city is 1 through 50,000, and I'm just going to link in that number to the original spreadsheet. That's essentially what normalization is. And this solves the problem that Joe's talking about, the redundancy issue, we don't want to store excess data or heaven forbid, this is the, I think the real problem is, when you go to update data, needing all of the previous historical records to be updated to, you fix a spelling mistake on a city, you need to go update it everywhere that you ever referenced a copy of that city. Whereas if it's normalized, you update it in one place, the ID stays the same. The other problem is cyclical data. But if you can't JSON.stringify an object, it takes a little bit of thinking to figure out how you'd put it into a SQL database sometimes. 

JOE_KARLSSON: Oh, totally. Absolutely. I totally agree. And I want to say that too, I get asked this all the time when I talk about MongoDB with normalization because the number one thing I see devs coming from SQL to NoSQL, particularly MongoDB, is they want to model their data like they would when they normalize it with an SQL database. But even still like the big reason that people always give is like, we're repeating on that data. Like normalization isn't even an anti pattern anymore with SQL databases. Like you see people normalizing in SQL anyways, and that are denormalizing by doing a recall. 

AJ_O’NEAL: And it comes down to a trade-offs and benefits. Like how much application do you want? How much application logic do you want to have control over the data? And for example, migration, cause sometimes it's easier to write a migration in JavaScript than it is in SQL. 

JOE_KARLSSON: Absolutely. And the biggest thing is performance because joins are really expensive. 

AJ_O’NEAL: Oh yeah, for sure. 

JOE_KARLSSON: And it's normalizing. 

STEVE_EDWARDS: Ding, ding, ding, ding, ding. Yeah. That's exactly what I was thinking. That's always the most expensive thing is, is the joins. 

JOE_KARLSSON: So if you have a really slow database, one of the biggest things you can do is obviously index, but if index isn't working, you normalize or denormalize the data. So you're just repeating it in there to get super fast performance. You don't have to worry about joins anymore, but that's a benefit you get out of the box with MongoDB. If you're not, if you're designing your schema by embedding the data in there instead of doing expensive joins. I always see people wanting to set up their tables in MongoDB with separate tables like they would normalize in a traditional SQL database, and I'm not taking advantage of the embedding you get with MongoDB. 

STEVE_EDWARDS: Yeah, I think, I mean, that's something I've wrestled with in the past, whether, you know, I was working on a site that used Apache Solar as our data store. So again, it's not apples to apples, but it's similar. 

JOE_KARLSSON: Totally.

STEVE_EDWARDS: Okay, so basically what you're saying is I have to update this whole record if one part of that record changes where it was SQL, I could just update the small part that needed to be updated. So that seems to be a sort of trade off. So what's the benefit for having the document database as you have it now, where you have to update an entire record? Do you lose some of that advantage or is there, how do you address that? 

JOE_KARLSSON: You could potentially be updating multiple documents with MongoDB through denormalizing it and keeping it all on the same table. But that's still, that's a good code smell for a MongoDB document-based database. Yeah, and it depends. You're going to hear me say this a lot today, but it depends on the needs of your application. I think there's no one-size-fits-all, but it depends on what you're doing. For example, maybe you are a read-heavy application and it makes sense to just embed everything in a single document so you don't have to do those joins. You just do a single read on a single document and get all that stuff out. Or sometimes MongoDB has a 16 megabyte per document limit. So maybe you have too much data that's over 16 megabytes. Then you actually need to actually split that up into separate tables. That's a good reason to start splitting that data up into multiple documents. But it depends. 

AJ_O’NEAL: Quality crap though, I mean, if you've got 16 megabytes, how can that be performant? Because if it's got a scan, table scans, how do table scans work in something like Mongo?

JOE_KARLSSON: Yeah, I'm not exactly sure the technical details. Um, I can get the information about that though, but table scans should be avoided at all costs. 

AJ_O’NEAL: Well, obviously, always. But, but when you have so much data, like table scans, it seems like the more data you have in a table, the more likely you are to need to table scan and, and the obvious question needs to be, well, what's a table scan? Table scan is when you have to do something where you can't easily index. You can't find something by an index. So for example, if we want to look up the city and state, I don't need to check every single row of the table. Like, does it match P? Does it match P? Oh, it matches P. Does it match PL? Okay, does it match PLE? Does it match PLEA? 

JOE_KARLSSON: Can I give a real world example of this? 

AJ_O’NEAL: Yeah, go ahead. 

JOE_KARLSSON: So that'd be equivalent to using like, looking up a resource in a book. So index is like just looking up the table context and finding the page number for what you're looking for. Right? It's just page 64 takes a second, right? Table scan is like, I have to read every single page in that book in order to find that resource that I'm looking for. 

AJ_O’NEAL: Excellent, much better example. Thanks. 

STEVE_EDWARDS: So in other words, you're indexing on the fly instead of indexing behind the scenes and building an index. You're basically having to go through an indexing process all the time instead of building the index behind the scenes and then just querying the index. 

JOE_KARLSSON: Yeah, absolutely. This is super cool. We just came out with this too. MongoDB in our Atlas, we have a schema advisor or index advisor. So if we start seeing that you're making queries a lot on this thing, we'll like, hey,dude, you should probably start indexing those things that you're using it all the time. But yeah, and it depends. And just like with SQL though, your indexes should be based on the needs of your application. What do you, because too many indexes will actually slow down. Is it? 

AJ_O’NEAL: It does that. And particularly indexes slow down writes. 

JOE_KARLSSON: Yes. 

AJ_O’NEAL: It's kind of like you go to 10X trade off in either direction. Your writes are 10 times slower, your reads are 10 times faster, or maybe a hundred times faster. 

JOE_KARLSSON: Yes. 

AJ_O’NEAL: Well, your reads are almost infinitely faster, but your writes are not infinitely slower, but significantly slower. And you're also, you're taking up more space on that. 

JOE_KARLSSON: Absolutely. Yep. Cause it's got, it'd be living in memory. If we had to like store all that somewhere, right? But yeah, and indexes too, it slows down because you are, every time you make a right, you have to re-update your index as well as the record you're updating. So it's like more things you have to update, which slows down the right performance. That depends. Like if you're a site like Twitter, where one person's writing one tweet and then 30 million people are reading that single tweet, you obviously want to be, 

AJ_O’NEAL: and they don't have an edit button. 

JOE_KARLSSON: Exactly. Yeah.

JOE_KARLSSON: So the rights, like there is no expense of additional rights because there is no edit. 

JOE_KARLSSON: Exactly. Yep. 

AJ_O’NEAL: Which is something you can implement in lots of different types of databases is, you know, doing log oriented writing rather than, I mean, editing a database is just a bad idea. Don't ever edit a row. I don't know how you feel about that in Mongo, but like you lose your security trail, you lose... You talk about like a mutability with your records. Yeah, mutability of records is like, if you can avoid it, I'd say don't allow someone to ever do an update. Just write a new record. Yeah. Write a new record with the same quasi ID and then select by which record is most recent. 

JOE_KARLSSON: Oh, totally. Like you can obviously update MongoDB records, but I love that though. If you want to build a mutability into your database, that's not a problem, right? You just versioning or, right.

AJ_O’NEAL: Does Mongo have any sort of like built-in versioning? That's something that I haven't seen in SQL databases, I don't think. 

JOE_KARLSSON: No, but that would be a schema design. So you could, there's a design pattern, just like mark the version number as a separate field in your document. So you could totally do versioning within with metadata on each document. Okay. Is it depends. It depends like out of the box now, but you could easily program something that using a schema design. 

 

Right now, many of you are stuck at home, but eventually everything will open up. All right, listeners, let me ask you a question. Wouldn't you rather work from home instead of a cubicle or a noisy open office? Need to negotiate with your team and convince them to let you do it? Well, I have the perfect book for you. It's by my friend, Will Gantt. It's called Remote Work, Get a Job or Make a Career Working from Home. He's a proven author, software developer, and professional consultant. With over 20 years of experience in a variety of roles, and now he wants to share his trade secrets with you. In Remote Work, you'll discover how to save more time, money, and mental energy each year how working remotely can give you and your company a competitive edge in the market, managing your physical health, mental health, career goals and relationships. You'll also get the ultimate list of tools and resources to help you transition into working remotely and much more. This is the perfect time to test out if working remotely is for you. And if you enjoy the freedom of working anywhere you want, then you can pick up your copy of remote work on Amazon today or click the link below in the description. 

STEVE_EDWARDS: So when it comes to overriding, does, it's been a while since I've worked with this, so I can't remember, but does it work that if like every record has a key ID value that uniquely identifies that record. 

JOE_KARLSSON: That's right. 

STEVE_EDWARDS: If you send the ID, it overrides the record. If you don't send an idea, it generates a new one. Or is that sort of have to build in yourself? 

JOE_KARLSSON: It depends. So like you can do a up cert. Up cert will do a insert if it doesn't exist or a update if it finds it. You can do inserts that will just do that or updates. It depends. 

STEVE_EDWARDS: You specify the unique key for your record as compared to something that Mimeo generates behind the scenes for you? 

JOE_KARLSSON: Yeah. So that's one do updates based on anything. By default, we recommend ID to enforce uniqueness. It's gonna really help to make sure you're not blowing up other things. For example, you have 30 million people named Joe on there and decide to do, you know, change every field that has the Joe. You could potentially be modifying data you intend to update. Yeah, that's by default, we index that field, so it's really easy to make changes if you're querying based on IDs, but you can easily add additional indexes based on your application. 

STEVE_EDWARDS: Sure, okay.

JOE_KARLSSON: Yeah, and I recommend to people, I see a lot of people too, trying to change the default ID, which is typically an anti-pattern. I would avoid changing that, like, because I want to make it my unique username. Like, cool, awesome. But you're, you, and this happens with RGB messes too, like using custom foreign keys is like kind of, it's a risky move. You want to make sure that you're linking based on uniqueness and using the out-of-the-box IDs. It's a really great way to do that. 

STEVE_EDWARDS: Yeah, you don't want to mess with the default. I would, I think in SQL, like an auto increment type field or some sort of ID.

JOE_KARLSSON: Totally. 

STEVE_EDWARDS: Yeah. You wouldn't want to screw with those. Really have to 

AJ_O’NEAL: auto increment is a bad idea in today's. 

JOE_KARLSSON: For everyone. Yes. 

AJ_O’NEAL: It really is like UUIDs are, I mean, I don't know if my SQL is up to speed, but Postgres very, very easy to have auto insert UUIDs. 

JOE_KARLSSON: Yeah. 

STEVE_EDWARDS: And those are generated by the database. 

AJ_O’NEAL: Yeah. So it's. Yeah, you can get it generated by database. Of course you can create your application layer, but you just import the like crypto module and then you do crypto dot uu what select crypto dot uuid just like debug it, you know, to see it manually in the console. And then you add something like a, you know, default uuid uuid dot generate something I, I, you know, don't quote me on that. I'm saying it wrong, but it's, it's fairly simple like that. You just say the default field is generate uuid. Right, right calls that function if the field is empty. 

JOE_KARLSSON: Yeah. 

AJ_O’NEAL: Because you cannot horizontally scale with an auto incrementing integer. 

JOE_KARLSSON: Totally. 

AJ_O’NEAL: And you would completely bust your application as soon as you need to go on more than one node. 

JOE_KARLSSON: People do not think about that when they scale up, right? You have two separate sharded nodes who are doing auto increment. They could start doing the same number. What if you delete one and edit one? Like it becomes a mess way faster than people think. It will be. In the sense of their human brains but it doesn't make sense for computers to do it. 

AJ_O’NEAL: It doesn't matter what database you're using. It doesn't matter if you're using SQLite. Do not use auto increment. Use UUID. 

JOE_KARLSSON: Yeah. I love that. Totally. Everyone. When you say that louder for the people in the back. Yeah. 

AJ_O’NEAL: So do not use auto increment. You will hate your life and your past self will vex you. 

JOE_KARLSSON: Exactly. 

AJ_O’NEAL: Use UUID. 

JOE_KARLSSON: I love that. No, I totally agree. I totally agree. The other thing too, I think people don't know much about, and especially for newbies coming to New Eskio is scalability. So we touch a little bit on horizontal scaling. I'd love to talk a little bit more about vertical and horizontal scaling. 

AJ_O’NEAL: Do we need Amy to ask what horizontal and vertical mean? Her internet's broken. I'll channel her spirit. Okay. You channel her spirit. 

STEVE_EDWARDS: We just scared her off. Oh no. 

JOE_KARLSSON: Hopefully she'll come back. But yeah. So what is horizontal and vertical scaling? I'm so glad you asked. Spirit of Amy. Wait, can I take a guess real quick? Yeah, please. Oh, that'd be great. 

STEVE_EDWARDS: Now, I believe the horizontal is adding more resources like either disk or sharding, I think is the term that Mongo uses. 

JOE_KARLSSON: Yep. You're getting that correct. So, yeah, it sounds close to another word that probably I'll mention on here. 

STEVE_EDWARDS: Yes, I won't mention that word. Sure, sure, sure. Basically, you're creating a larger base for your data reside, so that's why it's considered horizontal. 

JOE_KARLSSON: Yes. Wait, can you say it one more time? It has a, oh, one more time. 

STEVE_EDWARDS: I said it's...I'm thinking, I'm very visual. So I'm thinking in my head, if you're shouting, you're creating more disks for your data to reside in. So it's larger basis. How I think about it. Yes. Yeah. That's a good description for horizontal. Right. 

AJ_O’NEAL: Let's tweak that. Cause you said something that's ambiguous there. It's more disks. Yeah. More disks. Independent. Yes. Yeah. Yep. Yeah. And you more nodes. 

JOE_KARLSSON: Yeah. 

STEVE_EDWARDS: Yeah, exactly. More places, buildings, however you want to describe it, but it's a bigger area, surface area, to be able to store your data. Yep. 

AJ_O’NEAL: Not more resources on a box. 

STEVE_EDWARDS: Right, right, right, right. It's more boxes. 

JOE_KARLSSON: Yeah, exactly. I want to talk about like a specific example. So say I'm running a traditional RDBMS or SQL database and I run out of space, like, uh-oh, my three terabyte hard drives running out of space, what do I do? So this is, again, not true for all RDBMSes, but for a lot of them, you have to vertically scale. And what that means is you stop writing traffic to that original server that's running out of space, you go and buy a bigger, like a five-terabyte hard drive, whatever. And then you have to go and move all that data to the larger database. And then you start redirecting traffic to that new one. So it's confusing. You could potentially lose data. There's maybe downtime. There's ways to mitigate this, but vertical means you have to go buy a physically larger database or larger server with more space on it, which is fine, right? But horizontal means if I run out of space on a MongoDB database, I just go and buy a separate disk, a small cheap one, and I just start routing traffic to that new one. There's no downtime. We start just querying and moving data around horizontally. You can buy as many small nodes as possible. You might know this too just instinctively, but hard drives are pretty... Data is cheap right now, but buying really, really big hard drives gets expensive quickly. It's much cheaper for us to actually buy many smaller hard drives than one huge one and doing that migration with the vertical scalability. 

STEVE_EDWARDS: So where does doing stuff like a master-slave come into play? 

JOE_KARLSSON: And I prefer to use leader-follower. 

STEVE_EDWARDS: Okay, leader follower. I wasn't sure what the correct term was anymore. 

JOE_KARLSSON: I know. No, it's got that leader-follower. 

AJ_O’NEAL: It's become politicized. 

STEVE_EDWARDS: Yes, very much so. But the idea is basically that you have one sort of lead disk that redirects reads to other disks. 

JOE_KARLSSON: Yes.

STEVE_EDWARDS: So that for load balancing purposes. 

JOE_KARLSSON: Oh, absolutely. So basically what happens is the sharded clusters, they kind of sit below, but there's like a leader MongoDB server that's taking in all the requests. And it's kind of figures out like, it knows where all the data is. Cause you shard on an index key. So it can quickly figure out where the data saved. For an example, I think a really cool use case for that is sharding based on geolocation data. So I have a G like a global database. I can save all my data for Australian users near a sharded cluster that it sits really close to Australia. So that data for them is super fast. And it can shard for Chinese markets and European, right? But that master server routes all the traffic requests to the correct sharded node. It's hard to describe. This is one of those things that's so easy to show a picture of and it makes sense. I'm trying to like tell the story of how it works, which is a little bit harder, but I hope that makes sense. The other thing too I wanna make a note of is like a lot of other document databases. Don't actually shard horizontally and make sure you're looking to make sure that database does that. I think just cause it's no SQL doesn't mean that has shard egg baked in. I always want to check that out. Cause otherwise you have like expensive scalability issues if you have to do vertical scaling and potentially Amy's back. Okay. 

AIMEE_KNIGHT: So restarted my modem. Good now. 

AJ_O’NEAL: It channeled your spirit while you were gone. 

AIMEE_KNIGHT: Oh no. 

AJ_O’NEAL:You asked very, very sharp questions. 

JOE_KARLSSON: We did. And you were good. Was your cat jumping on your computer again or is it something else? 

AIMEE_KNIGHT: Gosh, Alina's. I mean, we had the horrible storms last week and lost like all electricity and internet, so I don't know if it's left over from that, but it appears to be better now, knock on wood. 

JOE_KARLSSON: Oh, that's awesome. So we've said, is the horizontal is adding more boxes, disks, plural, bigger base and vertical is increasing basically the capacities of the boxes that you have. Yeah. And MongoDB are a lot of no SQL databases have no SQL database. And again, a lot of RDB messes do too, but traditionally they haven't. I think we're seeing more, I think across the market, seeing a lot of hybridization and seeing that kind of adopted by more databases. 

STEVE_EDWARDS: Yes, that would make sense. 

JOE_KARLSSON: I'd love to talk about ACID transactions too. That's the other thing that comes up a lot with MongoDB and RDBMS is. 

AJ_O’NEAL: You would like to talk about ACID wouldn't you? 

JOE_KARLSSON: Is anyone wanna drop some ACID? I'm kidding. But ACID transactions, so it's atomicity, consistency, isolation, and durability. It's an acronym, right? And every single RDBMS is, well, not every, but a lot of traditional legacy SQL databases are ACID compliant. And that basically means that whenever, if I put a thing in the database and it's gonna either fail and roll it back, so like nothing happened, or it will succeed. And I can guarantee you to get that success. That's the TLDR of an ACID compliant database. I think that this actually is a common misconception though that MongoDB is not asset compliant. And that's actually not true. We actually have, we now support asset transactions on sharded clusters. So you can do massive global asset transactions on a sharded MongoDB database. That means if, and you could do that for multiple things, right? Like by default, each document is asset transaction like out of the box, but you can now specify like, I want to do this update, a delete, two queries, another update and delete and that whole thing that whole transaction needs to succeed. And if it doesn't, it'll roll everything back for you. 

AJ_O’NEAL: So I think there's a distinction for me and for everyone in the world, I guess, not just me, otherwise it wouldn't be worth talking about. Between a transaction, well, I don't know. What I think of as an asset transaction is almost now a dirty word. Again, it's like one of those things from the neckbeards of the 60s. We don't need asset transactions. Those are bad. We need eventual consistency. And I don't see how...How can you call something an asset transaction if it works across multiple, I guess if you don't work across multiple rows, if you don't have joins and you just shove everything in one row, then you can have asset transactions because you don't have multiple tables to consult. So every all of the data that's necessary for a lookup exists on the node at which it's being looked up guaranteed. Is that? 

AIMEE_KNIGHT: This is the same question I had like a while ago, like by nature of where we're at now, this argument is kind of a little bit invalid, which is what AJ is saying, just by nature of us building distributed systems. 

JOE_KARLSSON: Totally. Yeah. And it may not necessarily be on the same node. With MongoDB, it could be across. The data could be saved on multiple nodes, potentially. 

AJ_O’NEAL: Well, saved on multiple nodes, but for ACID to work, there has to be a single source of truth. There has to be not just a leader, but a master. Because it has to not just be saying come follow me. It has to be saying do as I say or die. 

JOE_KARLSSON: Oh, totally. Yeah, and I'm not exactly sure of the technical details that's implemented, but we're keeping track of those records and can undo that transaction on each and I guarantee that those are being undone across multiple nodes. The key too, I think is with databases, you have control over the amount. If you want eventual consistency or you want it guaranteed consistency, those transactions will come back after all of the replicated nodes have gotten that data updated, or if you only care about the leader for those replicated nodes or whatever, right? You can decide how much control we want over how that data is, like how guaranteed we are that data is persisted. Number one consideration there is performance. Obviously, if you need to make sure more things are being saved, that's going to take longer for that app or that transaction to actually, or that query or whatever to actually take place. It depends on your application. What do you need? What's important for your application? 

AJ_O’NEAL: Not acid. Yeah. I mean, like even a bank, right? Like, cause I think that, I think the example, the example, the canonical example for acid is like, well, you need your bank transactions to go through. Your bank doesn't use acid. Okay. Your bank makes sure that those transactions are lazy evaluated. They are eventually consistent. 

JOE_KARLSSON: Yeah. 

AIMEE_KNIGHT: Have we talked yet about like the cap theorem? Cause we're kind of talking about that too.

AJ_O’NEAL: Oh yeah, I guess that would be good to pull up as to why you have to either choose acid or eventual consistency. 

AIMEE_KNIGHT: Yeah. So that's kind of what I was like referring to and. 

JOE_KARLSSON: Cap theorem, Amy. 

AIMEE_KNIGHT: So cap theorem is you can, there's three things there's consistency, uh, availability and partition tolerance. And really, so you can only pick two, but I guess what I was saying earlier is nowadays you really, because of distributed systems, you're always going to pick, you're never going to pick one of them. But it was my understanding, MongoDB favors consistency and partition tolerance, right? So they would be like CP, because usually people just say it's CP, AP, or CA. 

JOE_KARLSSON: By default it does, but you can totally tune it to be whatever one you want. So yeah, so technically yes, but you can do it, you still have flexibility over. 

AIMEE_KNIGHT: So like a lot of times, like choosing a database is not necessarily even always about like, do I want SQL or NoSQL? You'd want to figure out which database favors like the parts of this cap theorem that you're looking to hit. And some databases are faster on read, some databases are faster on writes. 

JOE_KARLSSON: Right. So yeah, in the example, right, of banks, you obviously want those to be consistent. If I give you $100, I want to make sure that that's true, right? For everybody. But for someone like Twitter having that consistency is not that important. If you see a tweet listed above another tweet and another user sees that in different order, not a big deal, right? Like as long as you see that eventually, it's probably fine. So they're favoring speed as opposed to like perfect consistency across all users because it really doesn't matter for them. The data is moving so quickly through the system. 

AIMEE_KNIGHT: Yeah, and it's just like nowadays, like we have to have partition tolerance. 

JOE_KARLSSON: Absolutely, yeah. And that's a good point. I mean, like obviously with like sharding with MongoDB, it's...Yeah, partitioning is like the core tenant of what you could do with ModGoDB. 

AIMEE_KNIGHT: So I actually like, I was studying a little bit of this a while back before my most recent job, cause I just wanted to like brush up on all this stuff in the interview process, but so the other databases that I have written down here that are CP meaning they favor consistency and partition tolerance would be, uh, memcache and HBase. And then the ones that favor AP availability and partition tolerance, Cassandra couch, react, is it, is it RIA reoc? I don't know how to pronounce that. 

JOE_KARLSSON: I don't either. Or just say it out loud. I just read it on Hector news. 

AIMEE_KNIGHT: And then do I have anything for, I don't have anything for consistency and availability because like I said, nowadays that's just not really a thing because we need partition tolerance. We can be building distributed systems. 

JOE_KARLSSON: Totally. Yeah. That's like, it's basically essential for any modern web application to be able to partition. Yep. Yeah, that's interesting. That's a great list. I love that. 

STEVE_EDWARDS: Joe, I'm throwing this question. I don't think we've addressed this too much, but obviously you've mentioned that you always want to use the right tool for your needs. So where are use cases? What are the best use cases for MongoDB that you've seen or that you're aware of versus what cases would MongoDB not be a good fit?

JOE_KARLSSON: I may be biased here, but honestly, like MongoDB is a good general-purpose database these days. And I think it's because it has like strong defaults and you have the, you can be as flexible or inflexible as you want. Yeah. So like being able to enforce schemas. Great. If that's like a need for you, cool. If you need those ASS transactions, great. Like go for it. If you need to scale up, cool. It's like a great use case. I think some of the use cases I see get used a lot. And again, this is..It can be used for a lot of things, but I see it a lot for, I would see IOT, which you talked about last time I was on, e-commerce sites. It's really huge. Gaming. We see a lot of people in gaming using it. You see it for just like quick data. Sometimes I just need projects. I don't really care about scalability. I just want to get data in and I want to get that data out without having to think about it much. You can do that too. All right. Yeah. It's a... Yeah. Those are the big verticals we see. I mean, we're seeing tons of banks using us though, government agencies using us lots of different people are using MongoDB for a bunch of different out like use cases these days, especially with the updates we made recently. 

AIMEE_KNIGHT: Yes, I have another follow-up question too. So it's going to be the case, maybe somebody was on MongoDB back like five years ago and application grew and, and maybe they had like on-prem, like they actually like were managing stuff on-prem and they're wanting to migrate to the cloud now. So walk me through the different services you offer. What if I wanted to go into leverage Google and leverage GCP, but all of my data was living in MongoDB and obviously GCP offers different NoSQL solutions, but what if I wanted to stay with MongoDB? Then what do I do? 

JOE_KARLSSON: So people probably don't even really know this, but we have MongoDB has a database as a service cloud option. We call it Atlas. You should totally go check it out. Actually, I can leave with you guys a free code to get like $100. Joe K. 100, get $100 off their cloud option. We have a free tier, that'll be free forever. I've been using it forever. I've never gone over on the free tier, it's amazing. But the cool part about it is that Atlas, we're agnostic. So I think a lot of the database competitors who are doing document-based databases, you're like locked into that vendor. You can't change out, you can't move from everywhere, but MongoDB and Atlas in the cloud, we support GCP, Azure, and AWS. So you can host all of your data in whatever database service provider you're using. And there's a bunch of huge advantages to that too. Yeah, it's just awesome. And there's a bunch of other stuff in there that I'm not even touching on. The thing I'm most excited about is if you're hosting in the cloud, you get our most cutting-edge features. We just unveiled our scheme advisor, our performance advisor, we're looking for indexes. 

AJ_O’NEAL: When you say when you deploy to the cloud, you get our most cutting-edge features, to me that sounds scary. Because what I hear is, what I hear is you get our least stable. Version. I should say like, you have access. Can you clarify please? 

JOE_KARLSSON: Yeah, oh absolutely. I mean like, so obviously versioning, you're still like, do upgrades to versions. Like if you're running a production app, we're not going to upgrade you to a major version bump automatically. Um, but you will have access to do those upgrades before you get those on-prem, um, upgrades. Like we usually, we roll them out first, you can like test them out. So it's not like you're shoving down your throat. It's just like, here it's here. 

AJ_O’NEAL: So is it, is that a beta thing? Like I can opt into this beta or is that like? Cause I mean, I prefer it to go out to the open-source community and let other people deal with the problems for six months first. 

JOE_KARLSSON: Totally. Yeah, absolutely. I think it's a beta program. 

AJ_O’NEAL: I'm going to get crucified for that, but that's the way it is, right? As you know, as a business decision. 

JOE_KARLSSON: Oh, totally. Yeah, absolutely. I think we have a beta program. I'm actually not exactly sure that works, but it's an opt-in thing, right? You get to choose how, like you want to say the version number, like many versions go, cool, not a problem, right? Not a problem, but like we have a serverless option on top of our database, we have things you can access. We have a new GraphQL endpoint. Since MongoDB is a document-based database and we know the data types of each of those different fields, we generate a GraphQL schema and endpoint automatically based on your data. So you can do code operations with GraphQL. It's out of the box, you can just start querying it. Things like that are available only in the cloud right now. I think they're so cool. 

AJ_O’NEAL: Okay, so it's not just the latest features, it's the business. You get more enterprise features. 

JOE_KARLSSON: Yeah, and all those are free though too. Like we have charts and you can like do data visualization for free with your data, embed those in your applications. You can do a bunch of cool stuff with that too. Yeah, other than just serverless options, building an arrest API. A lot of times what I'm doing now, I just use our service and I just build a rest API in the cloud and I don't even need a server anymore. A lot of times my server is just doing basic operations of some data. So a lot of my applications, it's just easier to just have like a serverless interface to my database. And we do that super easily. 

STEVE_EDWARDS: And then from a GUI standpoint, I'm always big about database GUIs. I mean, I can do command line as well as I just like the GUI. So you have one called Compass, I believe is the... 

JOE_KARLSSON: Yep. Which is great for newbies. If you're new to databases, it's very visual. We kind of help you structure queries, that sort of thing. So yep, we have Compass. We still have our CLI. I'm still a CLI guy. I like scripting it. I like having access to that. Right. You can still access the Ripple. No problem. Right. And of course you can access it in the cloud too, through like the Atlas console or whatever. Right. You can just click around it and like make changes in the cloud through the browser, which again, very, very beginner user friendly, super easy for prototyping. It's kind of checking things out. 

STEVE_EDWARDS: Cool. All right. Anything else you want to cover that we have not yet discussed today?

JOE_KARLSSON: No, the only thing I'll say too is we touched a little bit on this again. I'm going to be, I'm just going to come back to your podcast again to talk more about data modeling. That's more like, this is my one-on-one type content, but I'd love to get more into like one or two content because the number one thing I see people making mistakes with this, like understanding data modeling for document-based database, which is kind of a, it's this whole other thing, right? There's no rules and it's kind of, it's. 

AJ_O’NEAL: Let's do it. 

JOE_KARLSSON: Yeah. 

AJ_O’NEAL: Let's do it. 

JOE_KARLSSON: Nope. That's it. That's it for today. I think.

STEVE_EDWARDS: Now, speaking of education, one more thing, and I've taken part in this before and you guys were talking about it, is the MongoDB University. So a few years ago, it's been, I was three or four years, I went through the course on MongoDB for Node developers. And I know there's a couple of different variations, but it was free. I thought it was a pretty cool class because it took a number of weeks and every week you had homework and an assignment, and then you had a final project at the end and you got a certification for what that was worth. But I thought it was is pretty neat, pretty detailed and there's forums you can ask questions and stuff. So anything else there you want to expand on that? 

JOE_KARLSSON: Yes. So the university.mongodb.com is incredible. It's totally free. I went through that training when I got started as an engineer. It's like our internal training for technical training. It's totally free and open to the public and it's super cool. We're making changes to it all the time. I just posted here, if you're new to MongoDB and you want to get started, you have an M001101, right? That's a great place to start if you're new to MongoDB and you want to learn more. And it's totally free. 

STEVE_EDWARDS: Yeah, you got classes on what basic cluster administration, aggregation, performance. 

JOE_KARLSSON: Yes. 

STEVE_EDWARDS: Java, JavaScript,.NET, Python. 

JOE_KARLSSON: Yep. Every, we can go as like, as beginner as, as deep as you want to go with it, we'll take you there. The internals of indexing and right, we can go through all that. And it's amazing. Good stuff. Yep. Thank you for bringing that. That's awesome. Yep, absolutely. We just launched our developer hub too. I'm going to pitch that really fast too. But if you're want to see like articles, projects, share stuff, learn about the community, but developer.mongodb.com is a great place to go to. Just launched it. And that's it. 

STEVE_EDWARDS: All right. Good deal. 

 

Hey folks, are you trying to figure out how to stay current with React Native? Maybe you heard the Chain React conference was canceled and you're a little bit sad about that. Well, I borrowed their dates and I'm doing an online conference. So if you want to come and learn from the best of the best from React Native, then come do it. We have people like Christopher Chedot from Facebook. He's gonna come and he's gonna talk to us and answer questions about the origins of React Native. We're also going to have Gantt Laborde from Infinite Red and several of the panelists and past panelists from React Native Radio. So come check it out at reactnativeremoteconf.com. That's reactnativeremoteconf.com.

STEVE_EDWARDS: With that, we will move on to picks. We'll go in alphabetical order by first name and go Amy. 

AIMEE_KNIGHT: Oh God, Sfinding, 

STEVE_EDWARDS: we'll switch over to AJ. AJ always has things to talk about. 

AJ_O’NEAL: Lexigraphical sort, if you didn't go alphabetical, but strict lexigraphical. 

STEVE_EDWARDS: Sorry, I couldn't do those calculations in my head. It said IJ.

AJ_O’NEAL: Yeah. Capital letters sort before. 

STEVE_EDWARDS: Oh, right. Okay. That's like in my defense in zoom here, you have your, your name and lowercase letters. 

AJ_O’NEAL: So, ah, well then, then I would sort actually after everyone. So I would go last. Okay. Anyway, so I've got a couple of on topic picks and then like a, not even a pick, just a, this happened. Fun. So, so first of all, I don't know if this is 100% true, but I talked before about the Ars Technica War Stories, and there's a game called Ultima Online that was one of the very first online games that was hugely successful and got lots of users. And they claim that they invented the term sharding because there was a wizard in the game and it had like emerald shards. And so when they had to split up the lands to support multiple sets of users. They called it sharding and then he didn't say like, and so we invented that term, but he said, he said, yeah, so, you know, lots of these people using databases these days, they don't know where the term sharding comes from. That's what it is. So anyway, interesting episode to watch. And I mean, always the ours technical war stories are just amazing. I think they, I don't even know if they do it anymore. I think I'm just catching up on what they did years ago, but I love those things so much crash bandicoot and Abe's odd world odd world Abe. I don't remember what it anyway, like they just go through a bunch of games that you've at least seen advertising for if not played and then tell the how it almost didn't work or the how it worked. But then was a, you know, failure commercially or whatever. Next. 

JOE_KARLSSON: Those are so good though. I just watched the crash bandicoot one. 

AJ_O’NEAL: Oh, it was incredible. I agree. Extended interview. The one that was like an hour instead of 10 minutes. 

JOE_KARLSSON: Yes. So good. 

AJ_O’NEAL: Yep. I mean, just amazing, freaking amazing. Yeah. I'm glad that you got to enjoy that too. The next thing. An oldie, a super oldie, way, way oldie, but a goodie. Your coffee shop doesn't use two phase commit and it kind of compares basically like Starbucks to Walmart. Like Starbucks, you've got, uh, you're, you're taking orders and people sit and they get callbacks. So this applies not just to databases, but also kind of the program programming paradigms, like the callback idea or the async await idea. And then, you know, versus the, you have lots of different registers, but each register finishes a task from beginning to completion while the customer is there and kind of compares and contrasts that, that idea is as it applies to data in a database. And then also some dude, Steve added me to the Twitter list-type script. So I'm just going to give you a slow Golf clap, Steve. Excellent troll. Okay. Excellent troll. Thank you, Steve. 

STEVE_EDWARDS: That wasn't me by the way. It was me. No, no, no. 

AJ_O’NEAL: No, and I just, it hurts a little. Okay, somebody who attacked me like that publicly or privately, because I don't know if lists are even public and I just got a private notification. To someone who attacked. 

STEVE_EDWARDS: I feel your pain. 

AJ_O’NEAL: I'm done. 

STEVE_EDWARDS: All right, Amy, you ready yet? I 

AIMEE_KNIGHT: am. So I'm going to go with something I starred on GitHub a couple of weeks ago. And if anybody kind of like follows me, I really like to deep dive into things because while abstraction is great for moving fast, I think it helps you to debug when issues arise if you kind of know what's going on under the hood. Yes. Love that. So. As I've been diving into Kubernetes, obviously, it is a great tool, but it abstracts away a heck of a lot. And so this is a deep dive of each step of your deployment, what's actually happening under the hood. So I will include a link for that and have a read. And then the other thing, it's been a while, but I am always looking for healthy different food. So in order to do my part in stimulating the economy, I've been trying to you know, maybe treat myself on some stuff because I'm not really eating out as much, you know, on things that because I am fortunate enough to have, you know, funds to do this kind of thing. All that to say I purchased some like healthy keto cereal from the cereal school is very expensive compared to regular cereal, but it's also pretty healthy. It has like 17, 16, 17 grams of protein, 100 calories, and I don't know how many carbs, but obviously it's keto. It doesn't have a lot of carbs. 

JOE_KARLSSON: Is it good though?

AIMEE_KNIGHT: It's very good. It's very expensive, but it's very good. So this is a treat for myself. So that's going to be my healthy pick. And that's it for me. 

STEVE_EDWARDS: Excellent, dude. Sorry, that was my Bill and Ted. Don't look there. And I think I'd mentioned in an earlier pick that they're doing another movie here, I think. They are, yeah. Who knows, I'll not be coming out though. Who knows how good it'll be, but it'll be a way to kill a couple hours at least. 

JOE_KARLSSON: Totally. 

STEVE_EDWARDS: So I'm going to go continue down the musical route that I've been going lately and go back to the 80s when I was in college. I know some of the purists are not going to like me this, but I'm going to go with Pink Floyd's Momentary Lapse of Reason album. For all the Pink Floyd purists that are screaming at me, that's not really Pink Floyd because it was the first album post Roger Waters. It's still an album that I or CD or MP3 collection, however you want to phrase it, that I listened to to this day, starts, finish every day, you know, starts out with learning to fly, got the dogs of war. The fourth song on the turning away is, to me is my favorite guitar solo of all time by David Gilmore. And it's just, there's a lot of longer guitar solos in this, but for whatever reason, this is one album I've really latched onto that start to finish, I'll listen to it on a regular basis. So doesn't have the Roger Waters in it, so it's maybe not, you know, real Pink Floyd to the purest, but it's still a fantastic album. Joe, your turn. What do you got for us? 

JOE_KARLSSON: Last and least, of course. 

AJ_O’NEAL: Oh, no, no, no, no. Not lexographically. 

JOE_KARLSSON: Oh, I forgot who I'm speaking with. Okay, so I've actually, I've been trying to not, I've been too stressed out and I haven't been able to read stuff. I've been trying to take a programming break and a social media break recently, but that basically means I've just been playing Animal Crossing New Horizons a lot recently, so a lot of that. But I do want to put a plug into MongoDB worlds coming up, which I'll be speaking at. I'm actually going to be running the Twitch stream. That's on June 9th, I think. We'll put a link on that though, but just go to mongodb.live and you should be able to see all the information on that. But I'll be on the Twitch stream, which is just twitch.tv slash mongodb. And yeah, come on, check that out. That's it. That's all I got. 

STEVE_EDWARDS: Alrighty. I believe that wraps up the show for today. So thanks to panelists. Thanks for Joe for coming on yet again. And it sounds like we will have Joe version three at some point in the near future. 

JOE_KARLSSON: Yes. Thanks for having me on. This has been so much. I always have a blast coming on here with all y'all. 

STEVE_EDWARDS: Oh yeah. We have a lot of fun. It's a hoot. It's a hoot. So thanks for coming again, Joe. And we will talk to everybody next time. 

AIMEE_KNIGHT: Bye. 

AJ_O’NEAL: Adios. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To deliver your content fast with Cashfly, visit C-A-C-H-E-F-L-Y dot com to learn more.