Add Full Text Search to Your Couchbase Data

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON: Hello, everyone. And welcome to another episode of Learn with Jason! Today on the show we have Laurent, you have a French name and I'm -- I apologize for everyone in French that had to hear me do that. Thanks for joining the show. Do you want to give us a bit of a background and who you are.

LAURENT: Yes, my name is Laurent Doguin. That's the French pronunciation. Sometimes I get -- good stuff. And I'm the developer at Couchbase, a NoSQL database vender. What is a NoSQL data baste vendor in 2023? Nobody knows. Every database does NoSQL and no database does NoSQL. It was something we had 10 years ago. We are still a database, we are distributed, we have full text search. We have all the cool things that people expect from a database in 2023. And we also have a cloud offering called cloud.couchbase.com. And it got acquired. Now I can talk about all the stuff. Before joining Couchbase, I am a boomerang. I began at a content managements platform which has all sorts of problems to search for documents. And it's always been kind of a -- a problem. And a thing to address for me. So, I have been in that space for quite a while and then I moved to Couchbase. Couchbase, 2014, it was the early time of Couchbase. At the time Couchbase was in its infancy. It is the child of Membase and CouchDB. You might not know them. M em base was the memcache. It's distributed. And then CouchDB was this weird REST JSON database that popped up before Mongoose in 2006 or seven. And Damien started CouchDB. It before Couchbase, it was full REST and JSON. That was impressive. Who would have thought? That was before Node.

JASON: Right.

LAURENT: And so, Couchbase is the merger of those two product, those two companies which gives you at the beginning a distributed, in-memory, persisted key value JSON database. And at the time you had to write your own indexes by creating map reduce function which was super-scary. Because at the time, it was produced by Hadoop. It was scary and it was big data and all this stuff. And no one wants to write that. So, everybody else, as a NoSQL database from the future, we added SQL. And how Couchbase is distributed in memory SQL, also full text, also dialectics. And also things we can talk about later, but it's a full feature database. We call it a data platform.

JASON: Yeah. This is a question I had. It seems in times past there were these big debates whether you wanted to go with a NoSQL or a SQL DAST database. There were talks about the relational database, you get these upsides and down sides, and a document store, these upsides and these down sides. The more I've watched the space evolve, they've all sort of grown together into like data platforms. So, can you talk a little bit about that? Like is -- is there still a big tradeoff to be made if you go with something that's like traditionally NoSQL versus something that's traditionally SQL? Or are they kind of the same now?

LAURENT: That's interesting what you said. I think if you are in old products, the old product, you end up being a platform, whether you're a database or not. Every product in this space, they all catch up to each other and they all propose the same set of features because they all go about -- or the same markets. So, if you go to the same markets, you understand features. And everybody is sort of leveled down into, well, now we are a platform. Which we are. And most people are. Does it matter now? Yes, I think it still matters. I think there's... it depends on your use case, of course.

JASON: Sure.

LAURENT: The something that's been built 40 years ago. Something that's been built 40 years ago. It can support a lot of features, a lot of cool stuff, a lot of fluff. It's still the same architecture. And I feel like if you were the evolution of something that started 40 years ago, there's no thing you can do when you are -- unless you rewrite everything and start from scratch. Which some people do. And sometimes it happens. Sometimes it doesn't. It's pieces-by-pieces. I feel like it's still interesting to choose a more modern database because you get a more modern actor that will allow you to scale to satisfy the needs of a more modern architecture. It's not to say that postgres doesn't scale. Postgres does scale. Maybe not as much as Couchbase, because Couchbase is made for that. You can add a whole lot of stuff around that and make it scale. It's sort of become your problem now to make an old product behave like a new product in a way.

JASON: I get what you're saying. So, you know, the tradeoff is like on one hand, you get the -- the benefit of like postgres has been here for 40 years. It's been used for literally every use case you can imagine and it's really been put through its paces. But that means it comes with all of the guarding and like all of the architectural like layers and all of the past decisions that have carried forward that make tech like that a little harder to flex and use and bend to your will when there are new cases that are like, you know, if you come to today, there are things we're building on the web today that we wouldn't even conceive of 10 years ago. Let alone 40 years ago.

LAURENT: What was Bill Gates say something what was the number of memory that was enough? I think he said something like 512 kilobytes of memory.

JASON: Yeah, something magically low.

LAURENT: Yeah.

JASON: Like that doesn't even cover my JavaScript bundle. But yeah. So, okay, I think I follow what you're saying. And you said something that was interesting. You said that postgres will scale, but Couchbase will scale better because it's built for that. So, I just kind of want to dig into that a little bit more because I feel like everybody says we scale. And so, I'm always curious, like, what were the things that we're focused on that make Couchbase scale?

LAURENT: It's mostly architectural decision. So, if we were in the realm of data, the software first, the way you start things is completely -- it's the other way around. The way you query things is completely dependent of the way you store things. And we know that because we are programmers and we've done link and list and we've done HashMap and we've done all the structure. And we know that if you know the idea, HashMap is going to create, it's better to get there directly from HashMap then through a fore loop, and then there's every bit that have fore loop and see if the IDs equal whatever element you get. That's the basic programming example. It's also true to the level of the databases that extract that. And so, the way you store things, completely designed on the way you're going to query them.

JASON: Right.

LAURENT: Every database is started as a key value store. Postgres was a key value store years ago, it was called ingress and they've added some stuff on top that have. And so, most databases have mostly one storing engine, Couchbase has four right now or five.

JASON: Okay.

LAURENT: The way we architected the platform, it's kind of four or five databases in one. In a traditional -- in a modern architecture you could have a NoSQL database like Mongo. you could have a cache like Redis, and you could have Kafka and you could have hydration for all the things together to make sure they stay updated. With Couchbase, it's sort of the same thing, but it's the same architecture. Instead of Kafka, we have DCB, the database protocol, the data node, the document store. It updates the index and query node for NoSQL. It updates the index and full text. The eventing which is our own trigger or design function as we call them. So, we sorts of build it from scratch to be able to add new workload as we go. As the product evolves. So, that's one bit, and then the other bit is we have a architecture. Most databases have been built towards a flow model, you write on the leader, and then the leader is synchronized, replicated to the followers and you only send read to the followers. Which means you cannot really scale the writing path. You need to scale the writing path and to add another leader. And how do you do when you have two leaders in? What do you do?

JASON: Right. This is the classic challenge that I think makes people fear databases. Is when you -- you start thinking about, like, okay, well, sure, we can replicate read. But when you think about write. Okay, but now we're gonna get synchronization issues. And what if we have simultaneous writes on like two different, you know, lead databases on the -- on opposite sides of the globe, how do those merge? And then your brain starts to melt out of your ears and you start to weep. You go, you know what? Maybe we don't need a database either. Maybe this was a bad idea and we shouldn't do anything else.

LAURENT: That's the idea. That's the beauty about this transformation. If somebody is going to do that on the shelf for you instead of you building and thinking about it. That's what the cloud thinks as well. People have refracted all that brain melting into nicely-put solutions.

JASON: Yeah. I mean, I -- I was talking about this with a different database provider. That it just feels like in the last -- I don't know -- few years or maybe 5 years or so, there's been this renewed interest in like making databases accessible to people who would never describe themselves as data baste architects. I feel like the DX has been improving steadily for years and years and years. And then all of a sudden it was like, everything went cloud, everything went self-serve. You suddenly had this like automated replication. We'll handle all of this for you. All you have to do is push this button. And that's felt kind of like a Renaissance for a lot of folks. You wouldn't be able to call yourself a full stack Dev before, but with all these cloud offerings, you don't need to be a full stack Dev, you need to operate with the APIs of the products.

LAURENT: You don't need to know how to use the database. You don't know how to use the servers. I call that DPS, but that's what we hide all the stuff and you just pull objects.

JASON: Yes.

LAURENT: That's cool. And you create the objects. That's more than database as a service. We are thinking about this as well. Couchbase, it might be for the future. But people are always looking for the next level of abstraction. And they're probably lazy, I wanted stuff to be abstracted for me. Right now I think the hardest part to abstract is data modelling. Most of you have to do data modelling. NoSQL was this promise that it's -- who cares, you can just store JSON and be done with it and hope everything is going to be fine. But the reality is, again, data modelling is sort of tied to how you store things. Which is again how you query things. There's one bit that people can't extract yet. I'm hoping AI can help with that. That's one of the funny things about AI. I think it's more suited for well-bounded domain, like data modelling instead of generating boilerplate code. Because there's so many ways to write code. There's very few ways to model data and do SQL.

JASON: Oh, interesting.

LAURENT: It's going to be interesting. There's this thing about three -- first, second, third, fourth, and fifth generation languages, programming languages. The first was basically Assembly. Always zero and one, the second was Assembly, and the third was C++, et cetera. The fourth was something more common. You have SQL, you have bash, you can have stuff like that. And the fifth was programming with constraints with UX. You express a problem, you express a condition. And the thing is solving everything by using the condition in the problem. So, you don't have to write code. It's just a -- it's like prologue. Make sure you get all of those languages from the future that are more suited for AI. And so, if you think of third generation language. So, Java, JavaScript, what you're going to be generating is more code. More code that you don't necessarily, you know, know. And that's more code that you have to maintain and you didn't even write what the thing -- like, that's bad. And could that code actually have been a dependency? Probably. Now, if you think about SQL, the SQL is gonna be generated. It's probably in your domain, it's probably something you would have written maybe the same way. Of course, there's always some crazy DPS gonna define the query differently to optimize it better. And that's a whole different job.

JASON: Sure.

LAURENT: So, I feel that's interesting. I think I have more hopes in the side of things around SQL than around Java or JavaScript. Which was a very long digression. What were we talking about?

JASON: Well, we were talking about, you know, the value of how we're kind of modernizing databases. We're seeing the developer experience come closer and closer to where you don't have to be a specialist to stand up. And you were saying the data modelling is really one of the big -- the last remaining challenges of that developer experience.

LAURENT: Yeah.

JASON: But so let's talk a little bit about, you know, Couchbase in particular. It's a name I've heard for a long time. It is a, you know, it's one of the ones that I've heard brought up like you hear it get brought up along Mongo, Couchbase, you know, and on. As like the NoSQL stores. And it seems like it's kind of evolved even further from there. One of the things we wanted to talk about today was full text search. And so, full text is one of those things that is I think deceptively simple-seeming. Where, you know, when I -- when I look at a pile of data and I think to myself, well, I should just -- if I type a word in, I can just look and see if that word is in the database. And that's easy! Easypeasy! And then you start to actually think about the level of complexity involved in doing that with tens of thousands, hundreds of thousands of entries. Or if you've got, you know, fields all across the database that all need to be searched. Like I'm thinking of say a product database. I have the products themselves, the description, we have tags, titles. Make we have image descriptions we want to search. Maybe we want to also include the reviews. And for all of those things to be searched would be horrendously slow on a site that was in the thousands of products because it's just so many things. If you do it the way that I, you know, that my -- my developer brain would typically reach for which is we'll just get everything there. Put it in an array and then loop through it until you find things that match.

LAURENT: Yes, yep.

JASON: Full text is a way of making this not so painful to do.

LAURENT: it's stored and queried differently.

JASON: Right. Is it something that's just built into Couchbase? do I get it for free? or do you have to think ahead and your data modelling includes that.

LAURENT: You get it for free. It's scaling architecture. When you start Couchbase one of the thing that stores data, the SQL service, that's the indexing. You have the query service -- the query service actually allows you to query the index -- found the index from the full text version which is now a service. Then we have the eventing service. And it's probably going to be more in the future. And the beauty of this is that you can put as much service as you want on one node or as none. You can have nodes that only have data service and some that only have index and query. And you can probably put more CPU on the query node and more RAM on the index node because that's kind of the work they do. And then enable full text search which you get for free and probably add a whole bunch of RAM to make that fast and a whole bunch of CPU because it is quite consuming.

JASON: Yes.

LAURENT: And each time you create a new document or get a new document from the data service, the CPU protocol is gonna update magically the full text service or the value of the full text service if you have different nodes. So, you do get that for free. You do get the -- if you think about how you would do it naturally. You would have your Kafka that goes and your Elastic, something that's pulled on Kafka or Vercel or whatever. You have your thing that moves data around. And you need to maintain that. Or you don't use a streaming thing. And then in your code, each time you update something, you make sure that you also update the full text index that's in a database. Which kind of sucks. But you would have to do that. And you would probably do that for the full cache as well. It's cache-based and you just use one database and it's automated.

JASON: And you just illustrated why this stuff falls apart for a lot of developers. If I'm building a website and I know enough to build a database and then I try to add full text search. Then I'm suddenly -- I'm starting to realize, oh, my god, I have to manage a Kafka queue. I don't want to do that. I don't want to think about that ever. So, I think this is one of those I thinks where there's this initial instinct that is, you know what? This is fine. I'll just roll my own. But as soon as you get into more advanced use cases, it quickly becomes a mountain of work to make this stuff to function the way you want it to function. To me, that's the power of where these database services like Couchbase have come. I can use Couchbase, I can get full text search. And never in my life do I need to be aware that RabbitMQ exists.

LAURENT: Yes. Because you don't want to. Because maintaining a cluster is...

JASON: It's -- I mean, it's -- if that's your job, excellent. If you're a web Dev and you just want full text search, the last thing you ever want to do is be thinking about an event queue.

LAURENT: Yes, yes.

JASON: So, I think this is the things that really magical to me is that stuff that I would have immediately run away screaming from 10 years ago is suddenly something that I can just do. I can just decide that I'm going to build this feature into a web app. And all I have to do is grab the data platform that gives me the feature that I want. Instead of having to think about how I'm gonna wire up all these really complicated backend services to give me the functionality that I want.

LAURENT: Right. You don't have to figure out enough to code it and you don't want to maintain it. No one wants to maintain something more than they should.

JASON: Right. And I repeat this a lot. I think the goal for anybody who is building should be spending as much time as possible building the unique value that you have. And as little time as possible maintaining the boiler plate functionality that allows that to exist. If you can push a button and get a platform that allows you use your data. That's so much better than maintaining your own data service so that you can create whatever is your unique idea. That maintenance takes you away from building the thing that you actually want to build. So, with that being said, I want to make sure we have plenty of time to build. I'm gonna flip us over into starting soon mode here. Which requires me to move a couple things around and get over here. Okay. Good. Let's do it. All right. So, first and foremost, this episode, like every episode, is being live captioned. We've got Amanda here from White Coat Captioning. Thank you so much, Amanda. And that is made possible through the support of our sponsors, Netlify and Vets Who Code. And also thanks to Couchbase for making this episode possible. We are talking to Laurent today. And you can go and do a follow on Twitter. And we're talking about --

LAURENT: Twitter, Mastodon, Bluesky, everywhere all the time.

JASON: All the things. Yes. Go find on your favorite text-based microblogging platform.

LAURENT: I'm not on Thread yet. I should have a go on Thread.

JASON: Oh, yeah, threads. Yeah. I don't know. It's amazing that we somehow made Mark Zuckerberg into the good guy again.

LAURENT: Yeah, I bet on Mark in the Mark versus Elon fight. I am betting on Mark.

JASON: I mean, I -- yes. I hope that fight doesn't happen at all. But if it doesn't happen, I really hope that Mark Zuckerberg just humiliates him. Anyways... So, we're talking about Couchbase today. So, I dropped a link in the chat. We are -- I think this is -- this is like where I'm at for a starting point. So, if I want to give this a try, what's the first thing that I should do here?

LAURENT: So, if you want to try and learn a cloud.couchbase.com. That's our Couchbase data. Again, this way, query, blah, blah, blah. If you look at on the -- you can provision a trial, which you can do now. Which is a good thing. It's gonna set up your own cluster so you can decide where you want to host it, which region. As deployed now.

JASON: This is cool that you have all the big three clouds available.

LAURENT: The big three. It used to be the big four in fresh middle, now we have three clouds. I come from a smaller cloud company in France. It was much smaller. It's actually -- people should give it a try. I don't think we'll ever integrate into cappella. But maybe one day. It will be nice. So, you have Couchbase 7.1.5, and the trial cluster. And deploying. You can see in the status bits over there. Trial, it's just one node. It's just one Docker container that we're setting up for you that's fully prepared. The minimum cluster that we advise people to do is free node cluster. I know it's a little bit big. But that's the kind of customer we usually have. And we are working on a way to make that start much easier. Which should be coming at the end of the year if everything works. And you should not have to start a three-machine cluster and pay for a three-machine cluster when you begin a new product. And right now you have a 30-day trial and then a free upgrade. We know that. Still, give it a try on the cloud. There's one cool thing called the playground which is the icon you see at the top right. Right by the search bar and as soon as your cluster is deployed, we would be able to actually some -- maybe some Node, maybe some SQL. Depends on what you wanted. For beginners, your cluster is -- let's do that. SDK for beginners or SQL. Whatever you want.

JASON: Okay. Let's do -- let's do SDKs.

LAURENT: All right. So, it's gonna start your tutorial. And it's gonna tell you... at some point... when it's finished loading. Something. So, Node is selected by default which is cool for us today and by default, they are selecting bucket and a scope. The way you store stuff in relational table is basically schema, table, column. Which maps to bucket, scope, and collection with Couchbase. So, now we've pre-imported the travel sample. You get the inventory collection. You can already run some JavaScript code through that trial cluster.

JASON: Oh, this is cool. So, it -- because I selected my database, it's able to run this code with the credentials.

LAURENT: Yeah. I actually -- yeah. It works.

JASON: That's cool. Okay.

LAURENT: That's nice.

JASON: So, there's more to this code down here. We have the bucket, we're getting the airline. And then we are going to get all of the travel sample -- or we're gonna get --

LAURENT: Just one airline, yeah.

JASON: Okay.

LAURENT: And the content of the airline, you can see airline has a type, it has a name, it has a bunch of things, it has a call sign. So, that's a way to learn Couchbase, the SDK, by going through the simple data directly through that. You don't have to preload anything or start anything. It's just -- it's a good experience to start things with.

JASON: Yeah. Absolutely. And I think that, you know, that is one of the things that's really, you know, just kind of daunting is like, okay, well, I want to learn this. But before I learn it, I have to get sample data up somewhere so that I can query it and I need the sample data to be like interesting enough that there are things to do other than like a simple get query. And that takes so long. Like there's so much effort involved in getting good sample data. So, having a dataset ready to go that I can just go and hit is a really nice -- a nice like quality of life improvement for somebody like me who just wants to learn fast.

LAURENT: So, you get the code side of things. There's a bunch of steps in the tutorial. And if you select SDK for beginner, you can select SQL plusplus. That is the SQL that Couchbase used. It's made to be friendly with JSON. Because in traditional SQL, you mostly have SQL type like string. There are no arrays -- you can have arrays, but there are objects with more fields in there and you can have objects of arrays, you can have arrays of object, you can have arrays of arrays. You get the idea. You can traverse all the fields of your JSON document easily full SQL without any weird syntax. It's like a native SQL for JSON version of SQL which is quite cool.

JASON: Yeah. This is -- I mean, this is really cool. So, I -- from my days of writing SQL, I recognize the syntax. But this is letting me like dive into the JSON object that's stored in the document.

LAURENT: Yes.

JASON: That's super-cool. I love that. Okay.

LAURENT: And you still get the draw and you still get the traditional stuff. You also get transaction. And a bunch of keywords. The nest and unnest keyword which are a way to push in an array or flatten an array. Let's say you have an array of IDs and you do a nest array of IDs. Then you can join on the element of that array which is quite cool as well.

JASON: Yeah. Really, really cool. Awesome. Okay. So, this is -- like this is great. I love these tutorials. This is a great way to dive in and learn more. It looks like it goes pretty deep here too where it's gonna show you all of the major pieces. And let's see what's in the SDKs. Same kind of thing. Covers all of the bits. So, did we have -- did you want to spend more time in here or do you want to jump into some --

LAURENT: We can probably jump into code.

JASON: Okay. So, you sent me this repo a little bit earlier. Should I start here?

LAURENT: Yes. You can start here. It's the -- you can clone that. It's our Next.js tutorial. It works with Vercel. Who just announced a Vercel integration recently. So, you should be able to do everything magically from that repo. I think if you can probably fork it as well.

JASON: Okay. So, I'm going to head up here. And I will --

LAURENT: You probably want to fork it first and then clone that. Right.

JASON: The CLI makes -- I think. I don't know. Did I just do this wrong? GitHub repo, fork. And... oh. Oh. Right. Because I'm not in the thing. It's called tutorial...

LAURENT: It's called Next.js Quickstart.

JASON: Oh, Next.js Quickstart. Okay. Now I can... okay. So, would I like to add a remote? Yes. Double check... get remote. We have origin is my fork. And upstream is the Couchbase examples.

LAURENT: Correct.

JASON: And it's good that it defaulted to my personal. Because remember, Vercel will not let you use organizations without a credit card. The Learn with Jason org, not welcome on Vercel.

LAURENT: All right. So, what do you want to do? You want to open that? VS code? You want to open that? Vercel?

JASON: Yes. Let me open it here first. We will have this new file. All right. And so, we're looking at -- make this just a tad bigger. Nope. That's smaller. So, we've got a -- what looks like a pretty standard-looking API. So, the -- an index page. We've got a user page. And some utils --

LAURENT: Store --

JASON: Which I will look into later.

LAURENT: Yeah. You can see some profiles.

JASON: Nice.

LAURENT: If you look at mock_data.json. It will give the mock data file. We will see what's going to be imported. First name, last name, email. That's all we're going to import.

JASON: Okay.

LAURENT: Maybe look at package.json. And package.json is going to show you when it's happening.

JASON: Let's see...

LAURENT: Go up and look at the build command. It's being executed by Vercel. It's doing a bunch of thing which I can explain quickly. It's running strip SDK, the next build. And then load sample data, no env. So, strip -- you know what the strip command does? It's... I don't know how to explain that. You know how Vercel uses function and the functions are of a limited size --

JASON: Oh.

LAURENT: What maybe with the Node.js given Couchbase, comes up with the SDK which is a big fat binary that Vercel identified online because it's too big. What we do with the strip command is run strip minus, minus strip, minus debug. It's going to remove a whole bunch of unneeded things and make it more serverless friendly.

JASON: Got it. Got it, got it.

LAURENT: Next build and then the load data that we just showed. And then the build index as well. Which is going to run basically all the index we want for our app to work nicely.

JASON: Got it. Okay. And so, these two work. There are util folders for these. So, to load sample data --

LAURENT: Yes.

JASON: We are pulling in Couchbase.

LAURENT: Connecting to Couchbase. We get a bucket. A bucket is like a schema and database. From that we get the collection. We actually create that collection. It's called profile. Which is what you see here. Created profile collection. And from there, we load the data and we send the data to Couchbase.

JASON: Nice. Cool. Nice and straightforward. Makes sense to me. And the -- the other one was build indexes. And oh, look at that. That's even --

LAURENT: You should see everything is in indexes. You see two comment, create primary index on bucket, and then create primary index on default bucket, default something. What is default something?

JASON: Default profile.

LAURENT: These are namespace. When you do from something, we call that a namespace. And the namespace is bucket.scope.collections. In that case, it's your bucket, dot the default, and the profile was just created.

JASON: Got it.

LAURENT: And host the collection on the actual bucket. The primary index on the bucket is basically let's do a full scan every time there's not an index. A full scan for those who don't know, when you have a full index, read the whole file and look for exactly what that person is looking for, which is not ideal.

JASON: Right. A little bit of setup code here. Nothing too overwhelming. Looks like a few dozen lines of code. Mostly console logging, it looks like and that gives us a -- what I assume is a functioning app. So, I'm going to probably need to find all of my -- my bits here.

LAURENT: I mean, that's up to you. We can do a full local experience and do a Docker run Couchbase and run everything locally first.

JASON: Yeah. Why don't we do that first.

LAURENT: Yeah, it's probably better.

JASON: I need Docker.

LAURENT: If you -- we have an official image. And to rid me of that official image, they give you the nice command line that you wanted to run the exact right comment. The reason I always go to there is that Couchbase being this thing with multiple services, we have multiple ports and so, I always struggle to remember all the ports that needs to be open. So, yeah. If you get to the official image, down a little bit. You should see the Docker run example somewhere. There it is.

JASON: Okay.

LAURENT: You can probably just run that, I think. And that's gonna set up your local Docker Couchbase container.

JASON: Okay. Let me make sure... I don't -- have been enough time for FPS Docker. I think this is gonna just work. Let's -- let's see if it's gonna force me to log in. But we'll try.

LAURENT: It's a -- it should work. But it's stack writed. If somebody says it should, then it doesn't.

JASON: Famous last words.

LAURENT: Yes.

JASON: All right. So, let's try this out. And so, we're doing a Docker run. And then a lot of ports...

LAURENT: Using a whole bunch of ports.

JASON: And we end up at Couchbase. So, let's run it. Unable to find it locally. So, it's downloading the image now.

LAURENT: If you want in the meantime, what we can do is install the Couchbase plugin on VSCode. We have it for VSCode, it connects to any running Couchbase instance. And you can browse the different buckets. You can create new collection, you can edit document in place. You can do a whole bunch of things. Couchbase. Couchbase Lite, it's a different thing. We have a mobile database which is called Couchbase Lite.

JASON: Okay.

LAURENT: It allows you to embed in your mobile application that will go to the SQL database. One of the nice things that we have had as well.

JASON: Okay. So, this is... done. I think.

LAURENT: Yes. It should say "Running" somewhere. Probably.

JASON: It doesn't say -- it looks like it just downloaded. Maybe I'll run it again. Well, let's look at --

LAURENT: Yeah. You just wait to try. Go to port 8091. It's localhost 8091. It worked!

JASON: Hey!

LAURENT: So, you can start a new cluster or join an existing one. We don't have one, so, let's start a new cluster.

JASON: Okay. And so, we give this a cluster name and it was gonna be --

LAURENT: usually I call that Docker local. Because I do a whole lot of things with this. And then Illustrator.

JASON: Leave that... and then we'll do...

LAURENT: Password, password.

JASON: Oh, you just want to use like the...

LAURENT: I mean, it's your machine. In theory, no one can get there?

JASON: Okay. So, then...

LAURENT: Connect -- it's the enterprise version so you have to accept the term. There is a community edition as well.

JASON: Got it.

LAURENT: And then go to configure disk and memory. Those are the services that I told you about. Don't need to enable node-to-node encryption because you only have one node. And Docker -- that's good. And then you have data, query, index, search, analytics, eventing and backup. We Dent probably don't need analytics and eventing. You can un-tick those.

JASON: Don't need eventing either?

LAURENT: No, I don't think we'll use that today.

JASON: Okay. So, query is standard like read access to the database. I want to look up entry number -- or with the ID10.

LAURENT: It's SQL. So, that's a good question, actually. You don't only do SQL. We are a key value store at heart. And if the value is JSON, then you can query the JSON using SQL through that query node. But basically --

JASON: Right.

LAURENT: Coming from Membase, the value up to 20 megabytes can be anything.

JASON: Got it. Okay. Great.

LAURENT: And then --

JASON: Index is kind of saying, like, yeah, I want you to take the User email field and build an index on that so that we can look those up very quickly. And then search is the full text like hey, we're gonna get random queries and we don't know what they're gonna be. But we need to search the entirety of the data to pull that back.

LAURENT: Yes.

JASON: Depending on which of these you need, you can turn them on or off. I like this. Because I haven't seen the ability to toggle on these things to save space or save processing power. So, this is nice. I like this. Okay.

LAURENT: I sometimes refer to categorize as the choice database. We have cursors when you install the node. And when we are coding we don't have to be consistent all the time. You don't need to be consistent all the time. Like if you're Twitter, if you don't have the latest version of your timeline, that's fine. If you are one of our customers, they do bookings. So, booking hotel rooms or plane tickets, you have to be consistent. They both use Couchbase.

JASON: Got it. Got it, got it. Okay. So, I've got -- I've got the database set up. It looks like we don't have a bucket. And if I am understanding correctly, the bucket is what will get created when we switch over to...

LAURENT: Actually, I don't know if you can create a bucket from there. You can create one from here or from the...

JASON: Does this one not create a --

LAURENT: No, it only create --

JASON: Only creates a collection. Okay. So, I need to create a bucket.

LAURENT: Yes. I think you have the value.

JASON: Okay.

LAURENT: It's add bucket.

JASON: All right. And then I will give it a name of let's see, we're just gonna call this probably sample.

LAURENT: Default.

JASON: Default. Okay. Default is easy.

LAURENT: Yeah, most people use default.

JASON: And then I'm assuming defaults are good here?

LAURENT: Yeah. Yeah, yeah.

JASON: Okay.

LAURENT: You don't have to use that much memory. Because, yes, Couchbase has an integrated memory cache. So, each time you do a get, there's a good chance it's in memory. It's going to be fast. Each time you do a key base evaluation, it's probably in memory. You don't have to do database, it's already there.

JASON: Cool.

LAURENT: You don't have to put all your data in there. It's less used algorithm. If the data hasn't been touched by anything, it's gonna get out of the memory and replace --

JASON: Nice. Do I want to mess with any of the settings?

LAURENT: Yes, there's one thing you want to mess with. Event setting at end, Ent setting. There is a flush button enable. We are developing -- so, flush allows you to flush the content of the bucket in one operation which is the equivalent of drop every document. It's --

JASON: Oh, gotcha.

LAURENT: That's where you're coding.

JASON: Yeah. In development, we want to be able to blow the database away, bring in our fresh sample data. Start over again so we can do all of our other destructive and other operations without worrying. That's nice. Okay. So, I'll add that bucket. And it is doing a thing.

LAURENT: And it's there. So, I guess now you can probably run your app locally. Providing that we fill that thing. I think you need an env.local. There's an env.local example. Exactly.

JASON: We named this administer, password.

LAURENT: Password.

JASON: And bucket was called.

LAURENT: The connection string is Couchbase: //your host. So, probably localhost.

JASON: 8091? Or?

LAURENT: No, just localhost.

JASON: Okay. Great.

LAURENT: When you are distributed, we use a server recall. So, behind one server recall to one address. It's a server recall so you actually have several nodes that you can connect to.

JASON: gotcha. Gotcha, gotcha. I'm going to open up package.json so we can see. Do I want this one? Or do I want the Dev default? Or something else?

LAURENT: I think it's in the -- it's probably in the README. I'm assuming you want the default. Let's see... you should have every -- oh. Actually, in the README it says: Set up and run the application. Clone the source code. And then it's gonna tell you about the variable which we just set up through the env local file. It did this bit. And then if it worked correctly, it should be able to run the DB with the local profile which is supposed to be able to see your database.

JASON: Okay. I just realized I never ran the npm install. So, I'm doing that real quick. And then I'm gonna npm run init, DB local.

LAURENT: And so, local is gonna use the file that we just created with everything.

JASON: Bucket with given name already exists. That is okay.

LAURENT: It's creating the indexes. Which is cool.

JASON: Success. More success.

LAURENT: All right!

JASON: Okay. So, that's good. And then we do want our data, right, so I'm gonna get the load sample data... and that did what we want. Perfect. Nice. I like the logging is helpful. Shows me that it worked. And we're not in Cappella yet. So...

LAURENT: I think that's fine. It created everything for you so you should be able to write your query. If you look at the Couchbase interface, you can see it went from zero to ten right there.

JASON: Oh, yeah. And we can go right into the documents.

LAURENT: If you clear it, it might complain about having an index. We'll see.

JASON: It's saying no results.

LAURENT: If you click on "Retrieve docs."

JASON: Yep. I'm doing something wrong.

LAURENT: So, yeah, you probably need an index somewhere. Key space is default, default. And then is there a collection? Yes, default, default and select the collection called -- so, that's the third -- the third menu. So, it's not really easy --

JASON: Ah, there it is.

LAURENT: Yeah.

JASON: Cool. Okay. So, we're in our default bucket and then we're looking at our profiles. And now we've got -- these are the pieces that we just -- this is how we see our database.

LAURENT: Yes, yes.

JASON: Okay. And now if I npm run Dev, we're running at localhost 3000. And we've got a whole setup. Nice. Okay. Oh, and you've got like editing and stuff in here too.

LAURENT: That's nice. So, that's the basic index that's used for Vercel. Let's play a little bit with it. I don't -- I never looked at how the search works in there.

JASON: Let's see if I just start doing the...

LAURENT: Oh, actually might be a client side search. Kind of interesting.

JASON: Oh, okay. Yeah. Let's take a look. So, we're doing a -- whoops. In here we've got our index. The index has fetch all profiles. And then it does look like it does us -- it does do a search, I think? And then...

LAURENT: So, you might be able to modify that.

JASON: Okay. So, somewhere down here there's gonna be our actual search inbox sidebar. And set search string. Okay. And so, here we have our input. So, the input is text. That does the handle search field which was back here. And we can go to the search -- or wait, where was it? Handle search field. Sets the search string. Okay. That makes sense. And then we set the search string up here. And that's in a use state. So, we can follow this around and see where it ends up. Yeah. Cool. Okay. So, basically, we are -- we are firing this off as a API call which is pretty dang cool. So, let's see... am I on? Let's go to fetch. And I'll do a type. And that is given me a 304. Oh, cool. So, it comes back cached. Let's try one of these. This was a new one. We hadn't typed that before. So, that fired off. We're running locally so this is gonna be screaming fast. This is like a network request. We're doing a I believe a full text -- this is the full text search here.

LAURENT: That's -- that's -- no. It should be --

JASON: Oh, it's not.

LAURENT: It should be coming from the Next.js code.

JASON: Oh, because it's API user! Oh, right! We're using an API route.

LAURENT: Yeah.

JASON: And so, then we get --

LAURENT: That -- to look at -- as opposed -- there could be a Couchbasing somewhere.

JASON: Yeah, Couchbase, connect to databases. Here we get our cluster and our profile collection. So, here we've got the ability to insert. Get. upsert, remove.

LAURENT: Dang, where's the search?

JASON: Um... put handler... query. Search. Oh, this looks -- this looks like it.

LAURENT: Yes.

JASON: We're doing a cluster query, in the a collection query, I got it.

LAURENT: It's not a search query, it's SQL query. It's interesting. It's just a basically like -- which it works in some fashion in some ways just like you would use postgres. Now it doesn't work with what is called fuzzy search. It's when you messed up one character.

JASON: Right.

LAURENT: If you are looking for my name Laurent, and replace the A with another letter, and you have fuzzy search to one. It should pop up. But it won't pop up with like -- one thing that search can allow you to do is allow fuzzy search. It can allow you to do a lot of things. But it would allow you to do fuzzy search. What it would do is allow it to do fuzzy search on a dedicated search engine like Elastic or something else.

JASON: Right.

LAURENT: And we have a razor back. It's not the document, it's the idea of the document most of the time. The way it works in the full text index is when you store things in a SQL database, the field called name is just the name in there. So, it's basically the ID in the field. And the way it works with full text is it's the other way around. The key is actually the word that's been indexed. And the value is the idea of the document. So, let's say you've indexed a whole lot of document that have a description and the description there's lots of words. Every single one of those descriptions are gonna have an entry in the table. And so, if the description is, this is something cool and this is something better, there's gonna be a line that says something with two values because we had something in the description. Which is the two ID of the document corresponding to the description. It's gonna be one value for cool and one value for better. And we don't care about init, most of the time we use something called an analyzer. If it's English or French or whatever, you can choose language, it's going to remove all the words that are common.

JASON: Right, right.

LAURENT: Okay. That's quickly in a nutshell how a full text can work. So, you will store everything the other way around to query them the other way around.

JASON: And that makes sense. Yeah. In my -- and so, the challenge with that is that it in a lot of cases, this is two separate services. You've got your database, and then you've also got your full text service. And so, you as the developer end up with this sort of complicated problem where you run queries against the full text. But then you have to like resolve the full text results into actual data once you get back your results. Because as you said, you just get the ID of the document. And that can be really -- like, again, it's just -- it's another thing I don't want to really have to think about.

LAURENT: Yeah. And you would add another thing to that problem which is if you have a permission table. If you have permission in several documents. You need to check against the permission table that all the results you had from the full text engine are actually okay for the use of the request to see. Because they might not have the right to see that. Because the permission table is outside of the search engine. And that sucks because then you need to do a manual one or something like that.

JASON: Yeah, yeah. it just gets very complicated in a big hurry. And so, this is built into Couchbase is where I assume this is leading. Where all of these things are being done for you --

LAURENT: Yeah.

JASON: And I just get to say, show me everything that has the word "Cool" even if I misspell it.

LAURENT: We can fix that. Go in the interface of Couchbase and try some query straight into Couchbase. It's going to be faster for us to play with full text.

JASON: All right.

LAURENT: The first thing is create that full text index. So, if you go to search, you should have a quick index on the top right. Quick index is amazing because it's an assistant to create a full text index. So, index name, profiles. Key space, that's your collection called profile which is already selected. And now if you click on firstname, you have something on the right that's telling you, what am I gonna do with an index? You want to click on including search results. You want to click on support phrase matching. Maybe on support for Elasticsearch. We are not going to talk about sorting and facetting today because it's probably not the right time. But that's interesting too. And then you click on add.

JASON: Oh. I got ahead of myself. Includes in search results, phrase match, field agnostic, add.

LAURENT: So, that's the first name. We can do the same with the last name and the email. And it's gonna be -- it's gonna create a global field that's gonna work for a type. And it's also gonna work with fuzzy search which is that cool thing that allows you to make a mistake when you search on something. You creates --

JASON: Ah, I just broke it, didn't I?

LAURENT: Yeah.

JASON: Okay. Do it again.

LAURENT: That's create index field. It's -- yeah. It's a thing -- you can create those programmatically if you want to. It's basically, this is a JSON definition and you can form your cluster object in JavaScript. You asked for the full text index manager. That's gonna allow you to insert an index like this.

JASON: Nice.

LAURENT: So, create index at the bottom. And so, you should see that it's processing your index. Processed, zero, ten. All right! So, you have stuff in your index. If you go to search, type whatever name we had, it should come back on the search this index. Yeah.

JASON: Search this index...

LAURENT: Yeah. So, here -- on that field, the fuzzy search is not enabled yet. So, you need to type the exact name. Or first name.

JASON: Okay. Somebody -- oh. There was a name. It was -- crap. I'm gonna look out here. Because there was -- Armina.

LAURENT: Names.

JASON: There!

LAURENT: And it should show up at some point. Okay. Cool. So, it works. Somewhat. Let's try to -- so, that's just default text index. It's not integrated to our SQL. So, you could very well do just like you usually do. Which is query that search index and then map this. Or because we have this cool thing called the flex index, you could use that search index straight through SQL which is amazing. So, if you go to query, we could start writing that query. By doing SQL.

JASON: Okay. So, I'm going to select... let's see... what are my -- my field names here? Do I -- so, when I'm in a doc, do I get like profile.email? Or can I go straight to email?

LAURENT: So, it depends on your context.

JASON: Okay.

LAURENT: If you do profile add email... from default, I think it works. From back tick, I think, is what we use for namespaces.

JASON: Like that?

LAURENT: Yeah. And you don't need the underscore. The underscore is the scope. Here you need to first say the bucket. So, no underscore.

JASON: Okay and if I run this, is this gonna give me all of my emails?

LAURENT: Probably. Just try that. And it's probably gonna scream at something. Let's see...

JASON: Let's see. It doesn't scream, but I didn't query properly.

LAURENT: So, if you remove profile and just email, it should still work. Because I don't think you have much document in there.

JASON: Let's see... I am missing something -- is it -- should it be profile?

LAURENT: So, default, dot underscore default dot profile. Full namespace.

JASON: Default, profile...

LAURENT: It was a good start. Yeah. And I see --

JASON: Key space, not found.

LAURENT: You need the back tick on each of those elements. Which is a pain. I understand that. But you need to have default, full back tick, underscore --

JASON: Oh, I understand. Okay. Got it. Okay.

LAURENT: Add those to... to get all those emails, now if you click on -- if you add select role, email, it's gonna do something even nicer. Which is if you select role email, you should have just email. You shouldn't have even the...

JASON: Wait. I screwed this up.

LAURENT: Oh, it was an A, sorry. Sorry.

JASON: Yeah, this is just like a full -- just a list.

LAURENT: Which is cool. Because it's sort of allowing you to shape the JSON that you want.

JASON: Yeah...

LAURENT: Okay. So, what are we going to do now? How much time do we have? 25 minutes. Not long.

JASON: Yeah, we've got like 15, 20 minutes.

LAURENT: Yeah. Let me... I think what you can do right now is Google Couchbase SQL search. And it's gonna give you all the information you need to call the search from a SQL query. There's actually a function called search that you can call straight up in there. I think it's the search function. So, it's this fifth -- one, two, three, four, five. I think it's probably the five one -- fifth one.

JASON: Oh, nice. So, we've got... helpers here. And so, the identifier...

LAURENT: So, yeah.

JASON: All right. Where is my -- where is my example? So, we would select where search. Okay. So, I can come back --

LAURENT: So, let me --

JASON: Over here. Search. And then we would say... and this doesn't work if you go straight to profile. Let me just... nope. So, here... and...

LAURENT: So, instead of doing this, what you can do is from profile asp --

JASON: Oh!

LAURENT: You can add an alias to the namespace. So, instead of freelancer typing the whole thing, you can just use that alias in the function. So, if you use asp, and use it directly on the search. Which is nicer, right?

JASON: Email --

LAURENT: Yeah.

JASON: Or even p.first name.

LAURENT: P just works.

JASON: Oh, you don't have to add --

LAURENT: No, I want to know which namespace you are and then you can enter your query. The best thing for the simplest query that I like to use... let me... send it to you and be something that... from there you can add an object.

JASON: Like this?

LAURENT: I have a lag. Wait, there's probably some quote error -- some -- yes. And you probably want to have something that's actually close to the name.

JASON: Yeah. Let's do with the -- there was a I think a Christie -- I will spell that wrong. We still got it. So, I'm actually gonna do... first name... last name...

LAURENT: So, it's complaining about something, isn't it?

JASON: I think it's because I had a wrong. Yeah. I did raw --

LAURENT: Yeah.

JASON: I did raw and didn't format anything. Look at that. It works. I spelled Christie's name wrong, and we still got the result back.

LAURENT: Which is cool.

JASON: That's really cool. And it's like --

LAURENT: Now --

JASON: This is one of those great moments where things just like -- I don't even want to think about how hard that would be to do on my own. To get like misspelled words to return search results. Ah! Wonderful.

LAURENT: So, we could go ahead and replace that straight to the function that we saw during the code. Or we can play a little bit more and we can go maybe a little bit further on the query side of things.

JASON: Yeah.

LAURENT: And we can be nosey. Let's assume for the sake of the exercise that there is another collection called permission that holds a document with the list of IDs. And we're gonna match that list of IDs to whatever is returned. So, basically, it's about saying that only this persons are searchable. Let's do something like this. So, if you go to your VSCode. Let's open your Couchbase tab.

JASON: Couchbase...

LAURENT: Create connection. The plus on the upper side of things is gonna not do anything because something is wrong. So, let's not do that. What's going on? If you go to problems, it could be a --

JASON: There are --

LAURENT: The problem --

JASON: In many things that could be -- my -- we have a lot of extensions and things happening in this that may or may not be --

LAURENT: Is it VSCode or code you have?

JASON: Let's see...

LAURENT: Because I think it's Vercel that's complaining.

JASON: For Mac... all right. So, it was saying it was missing the -- it was missing a command. So, if I show Couchbase. It says VSCode Couchbase .create cluster connection not found.

LAURENT: That could be because of another problem. And I'm afraid it's about the Vercel dependency.

JASON: Ah. So, I need to... install this one?

LAURENT: If your Mac has chip, and Intel -- which one do you have?

JASON: Run this over in another window here.

LAURENT: Because, obviously, we try to be as safe as possible. So, we can't SSL to connect to anything remote. That means we're gonna use our local Docker container to do it. So, that's fine. But we still need to have that working, sadly. We don't have to do it this way. You can use the other stuff. I mean, that's sad, but...

JASON: Let's see. It's doing -- it's doing stuff.

LAURENT: So, what we're going to do is create a new collection called permission. And from there, have one document. And this document is gonna hold an array of IDs. And we can see that as a -- a completed permissions schema. And we are gonna see how it works.

JASON: Okay.

LAURENT: We can do it from here.

JASON: Just to make sure we don't run out of time. So, I wanted to do that in buckets default...

LAURENT: So, in buckets, yes. Default. And you should have scopes and collection on the top right. And from there, you should be able to add a collection. And let's call that permission. No time to the zero is the default. Because we were the cache, you can add the document. If you are storing user session, they will disappear automatically after the time we set up, for instance, which is nice. From there, you can -- you don't have a document. So, we can create one.

JASON: Okay.

LAURENT: Let's call it permission. And let's have maybe just an array?

JASON: Okay. Just an array? Like...

LAURENT: Of information. How can we...

JASON: Or like...

LAURENT: Oh, and a flag. And it's just an array and a flag. And a boolean flag. Let's call that enabled.

JASON: Okay. So, go with enabled?

LAURENT: Sorry. So, you have to have an object that's first a stop thing. A stop object.

JASON: Okay.

LAURENT: And then enable equals true or false. Whatever we want.

JASON: This is a flag. So, we'll say true. And then --

LAURENT: No, sorry. Yeah. Exactly.

JASON: Okay. So, IDs... and then we've got our array of IDs.

LAURENT: Right. Your array of IDs. ID of the document that already exists.

JASON: Is this gonna get autogenerated? Or should I just put in like a number?

LAURENT: So, you need to put an ID in there. You can do what you want.

JASON: Okay.

LAURENT: One works. So, let's go ahead and hit save. And we can probably copy it based on a couple of IDs from our profiles.

JASON: Okay. Do I have those available here for copying? I do. All right. So, I'm gonna just copy a handful of these... edit here. And I'm going to... add that. Let's go up. Like three or four. Okay. More...

LAURENT: Okay. So, that's good.

JASON: Okay. Oh. We've got three IDs saved in there. And we've got it set to enabled, true.

LAURENT: Right. So, let's go back to our query and let's do a join. Because joins are weird and fun. The idea here is that the document will also settle the permission of who is okay to be searched or not okay to be searched. True is okay to be searched. And the IDs in the array are -- I mean, you know, you can search, right? So, we're gonna need two things. We're gonna need a couple namespace. The first one is profile. That's gonna be what we're gonna join on. So, after from, you can -- right after the from you can hit enter. And we're gonna have something from -- we're gonna have something from the collection called permission.

JASON: Okay.

LAURENT: Right. The -- so, probably default, default profile. If you don't want to do all that stuff, there's a trick. If you go up right, there's a menu called context. And context allows you to place yourself into a context. Your contents of a bucket and a scope. This way you don't have to write default, default all the time which can be nice. You can just have profile and permission. From profile SP you can do permission as pe, for instance. And permission as pe. And nest. And nest is what we use to flatten an array. You can get pe, dot, the array of IDs that we had. Which I think was the array of IDs.

JASON: Yeah.

LAURENT: As users ID, for instance.

JASON: Okay.

LAURENT: And we're gonna join that on profile. Sp where -- sorry, sorry, sorry. Not where. On. Join on profile sp on.

JASON: Is it join or join on?

LAURENT: It's join profile sp on something.

JASON: On p.pid? Or was it ID?

LAURENT: Yeah. The pid equals user ID.

JASON: Okay.

LAURENT: And what this should do is do the join right. Put all of our objects on the same line. So, we should have access to the flag enable. When we do search equals something, we can add "And pe.enabled = true." That should probably work.

JASON: This should I think fail. No. First name -- oh. Because now we have multiple tables so I need to get those.

LAURENT: It's probably going to ask you to do a key space. So, if you go to advice, it's complaining that you don't have -- oh, wait. No. Not the right one. Permission -- so, maybe permission was not the name of the...

JASON: I need to reload this because we...

LAURENT: So, wait. Just for the record, the advice thing is cool because it just tells you what index to be. You can just be in that index, which is still nice. So, you can go ahead and create that index for you because we have -- what's it called? A query analyzer. A query...

JASON: Key space not found. Okay. I think I -- I'm gonna head back to the search -- to the buckets.

LAURENT: Yeah, let's see.

JASON: , documents. And we are in --

LAURENT: Oh. So, you created the permission in the default. And you don't have -- which is fine, we just need to replace --

JASON: Yeah, the search --

LAURENT: By default, yeah.

JASON: Okay. And so, we're going to --

LAURENT: By search --

JASON: Query, instead of permission, default.

LAURENT: Yes. And now it should just work. And now it's complaining about the index.

JASON: Join term.

LAURENT: You can follow the advice, create the index. I'm a lazy person so I like when people tell me what index to build. And I say, well, you should not do that in production. Which is true. Because sometimes it's a costly operation. But, you know, we are developing. So, we can do it and execute that.

JASON: Okay. And because Christie is not one of our enabled IDs, we won't be able to search that. So, let's try Saul. We get back -- Saul, everyone though here we would get three entries if we were getting everything. But because only Saul is in the -- the enabled, we only get that one back.

LAURENT: So, it's a good way to show that you can interpret full text search results. All the stuff that you usually have around directly into query. So, a natural way, instead of -- instead of I don't want to think about it. And you don't think about it either. Because we know that it's painful to go and fetch something somewhere. And map it. You can also roll out some other editor. So, it is fully integrated.

JASON: Yeah. Okay.

LAURENT: And so, that's not it. But that's pretty complicated to do most of the time.

JASON: I mean, this is -- like I feel like this is one of those good cases where we what -- what we are doing here is something that is like it looks pretty straightforward because this is all built-in. But if you were trying to do this where you had to get to Elasticsearch and like get to your permissions table and make the extra queries to get the extra data. And get it on the screen. It would immediately become one of those things, I'm gonna do everything I can to get out of this ticket.

LAURENT: Yeah. That would be bad. And I have been there in my first job. Yeah. I agree. And it's one of the coolest things with Couchbase is that is really is not just about the different services, it's about making them available together. And that's the good part.

JASON: Yes. So, this is great. I mean, this is -- like -- this feels like a very -- and, you know, I know very little about SQL. And I was still able to get this running. We were able to set up some databases, or some collections inside the database and get all that running. And so, to deploy this, we would get into the -- where is it? Somewhere in here. We would get signed in here. And then we would be able to just connect with our -- our -- in our databases, we have all of our connection strings and everything that we would need.

LAURENT: Yes, so that's actually pretty neat. You can select the credential and it's going to tell you exactly the code you need to write except the password. Which is nice. You don't have to -- maybe we can go and create a credential and see. There's a couple of things you need to do. You need to make your database available on the Internet and you need to create credentials.

JASON: Yeah, so we would just --

LAURENT: Username, password, some write, some permission on the buckets. You don't have to have permission on everything. You can decide if you want a read or writing on bucket scope basis.

JASON: Cool.

LAURENT: Because, of course, there's audit logs as well and all that stuff.

JASON: Nice.

LAURENT: And once you have that, you go to allowed IP addresses. And what allowed IP addresses allow you to do is allow you to take a look at which address would you make that thing available from? And right now it's your own address. I think it's your IP. And you can also make it available to anything by using zero dot zero dot zero. Which is not great for the way it works. And it's in the a demo, under the API, you have the query which will allow you to create a link between the database cluster and your local network in one of your biggest clouds. One of the big three.

JASON: Cool. So, this will be ready for, you know, effectively any -- any security team is gonna be happy if you choose this because it's got all of the things that, like, I don't know what these -- like I -- academically, I kind of understand why everybody cares about these things because I know that you don't want just unfettered access to your database and all that kind of stuff. But I don't really get how a lot of each of these things work. But I do know when you start trying to bring vendor tooling into your company. One of the first things to be asked, how not to get in trouble with data security and being in compliance with the relevant laws. Being able to point, here. This just works. That's going to help. Which is something that I do think is a consideration when you're choosing a tool. Especially if you're in a mature company. Right? Because a lot of times the new hot thing hasn't gotten around to adding some of this stuff yet. And so, as much as you might be this is gonna be great. Whether you take it to the security team, do they support all of these things the answer is gonna be, not yet!

LAURENT: We have the E-compliance, whatever the name is in the US and your country. We have a lot of certifications already that might be relevant to you. So, we are doing our work. We are trying to be as compliant with as much policies as possible.

JASON: Very cool. All right. So, with that, we are effectively out of time here. So, where should someone go if they want to go deeper and get started here?

LAURENT: So, cloud.couchbase.com, create an account and go on the playground. If you really don't want to create an account, go to Couchbase.live. It's going to one day be deprecated. But Couchbase.live is our initial playground.

JASON: I did something wrong. Couchbase.life?

LAURENT: Live.

JASON: Oh, live, sorry.

LAURENT: I was thinking it must have been deprecated before I thought it was. And it's pretty much the same thing that you saw, it's not integrated to Cappella. But you get a good peek at all the different SDKs that we provide, the solutions. You'll even get a peek on the mobile stuff as well. You can integrate with your inbox, you can run it on your own machine. So, it's a pretty cool way to get started. And, of course, with Cappella.

JASON: Very. There's the link to get your Cappella trial. Make sure grow and give Laurent a follow. And if you have any other questions, you can direct them to here, to -- is there any other -- any other good spot for folks who want to ask questions, discuss, or otherwise get involved with Couchbase?

LAURENT: We have a Discord channel. Community.couchbase.com you should see a whole bunch of things and a link to join us to our Discord. It's called the Hub. It's where we also have some ask me anything with some prominent Couchbase figures. There's a bunch of things you can do in there if you join the Hub or if you explore the Hub. There's a link to our Discord if you want to ask us questions. We have a forum on Couchbase.com if you don't like to -- the synchronous way of doing stuff on Discord, that works too. We try to be where you are. So, you know, if we're not there, just ping us where we are and we'll find you.

JASON: Awesome. All right, well, this episode, like every episode, has been live captioned, thank you so much to Amanda from White Coat Captioning for being here, made possible through the support of sponsors, Netlify, Vets Who Code, and thank you to Couchbase. We have an absolutely wonderful lineup coming. I will back to the regular streaming shenanigans coming. We have Fred to, and what's new in HTML and CSS, new browser APIs with Una. I've got episodes -- there's so much good stuff. I have been lazy. I'm not getting them up on the schedule. You can just add them with this button so you always know what's coming up. And you can also join the Discord if you want me to at here whenever I go live. Laurent, thank you for joining us today time. Any parting words before we send everyone to their next destination?

LAURENT: Thank you so much, it was a pleasure. I was happy to teach you more about Couchbase. And if you have in real life conferences, hope to see you. We'll see.

JASON: Thank you so much, y'all. We'll find somebody to raid and we will see you next time.

LAURENT: Cheers.