WEBVTT 1 00:00:05.200 --> 00:00:08.800 Hey, folks, welcome back to another episode of JavaScript Jabber. 2 00:00:09.039 --> 00:00:13.199 This week, on our panel, we have Steve Edwards. 3 00:00:12.080 --> 00:00:15.960 Yo yo yo, coming at you from away too warm Portland. 4 00:00:17.359 --> 00:00:20.920 I'm Charles Maxwood from Top End devs. Well, I'm too 5 00:00:20.960 --> 00:00:23.120 far west for that big cold storm. But it's still 6 00:00:23.160 --> 00:00:23.600 cold here. 7 00:00:24.480 --> 00:00:28.719 It's maybe too warm. Man. Our snowpack sucks. Yeah, been 8 00:00:28.800 --> 00:00:31.600 able to get any skiing is just awful. 9 00:00:31.839 --> 00:00:34.119 Yeah, same here. People are worried about water. I live 10 00:00:34.119 --> 00:00:37.159 in Utah. If you're not aware, we have a special 11 00:00:37.159 --> 00:00:41.799 guest though this week. That is Valeri Karpov. Do you 12 00:00:41.840 --> 00:00:44.039 want to introduce yourself. I know we've had you on before, 13 00:00:44.079 --> 00:00:45.399 but just remind people who you are. 14 00:00:46.000 --> 00:00:48.719 Yeah, Hi everyone. My name is Belle. I'm the maintainer 15 00:00:48.719 --> 00:00:52.320 of Mongers. I'm popular ODM for no JS and Mongo dB, 16 00:00:53.079 --> 00:00:56.159 and I do freelance web development. I'm based in Miami, Florida, 17 00:00:56.200 --> 00:00:59.280 which is much colder than expected. I had to turn 18 00:00:59.320 --> 00:01:01.520 on the heat for the first time. I'm telling Chuck, 19 00:01:02.000 --> 00:01:04.560 first time turning the seats. I moved to Miami about 20 00:01:04.560 --> 00:01:06.439 seven years ago. That's brutal. 21 00:01:06.599 --> 00:01:11.079 Yeah, I feel your pain. Yeah, my son's on a 22 00:01:11.120 --> 00:01:14.400 mission for the church. In South Carolina, and yeah, apparently 23 00:01:14.400 --> 00:01:16.680 people don't deal well with cold there either, so. 24 00:01:17.920 --> 00:01:20.840 No, not used to it. I mean, yeah, I have 25 00:01:21.040 --> 00:01:23.400 never seen Miami. I haven't seen Miami break into the 26 00:01:23.439 --> 00:01:25.920 thirties before since it's been a while. 27 00:01:26.680 --> 00:01:28.760 Yeah, I was accused of not teaching him how to 28 00:01:28.840 --> 00:01:32.599 drive on the ice, which I know isn't true. So anyway, 29 00:01:33.400 --> 00:01:37.920 let's dive in. Let's talk about Mongoose. I'm assuming that 30 00:01:37.959 --> 00:01:40.400 people have some idea of what it is, and I 31 00:01:40.560 --> 00:01:44.920 really want to get more into you know, features, functions, 32 00:01:45.159 --> 00:01:47.760 you know, it seems like a lot more adoption of AI. 33 00:01:47.920 --> 00:01:50.159 Where does it? Where does mongoos get us from there? 34 00:01:50.560 --> 00:01:53.200 But just kind of set the stage to get us going, 35 00:01:53.239 --> 00:01:56.040 like what is mongoose And at a high level what 36 00:01:56.079 --> 00:01:56.920 does it do for people? 37 00:01:57.879 --> 00:01:59.560 But a high level, it's like an O R M 38 00:01:59.840 --> 00:02:03.280 or O D M and no sql land or for 39 00:02:03.400 --> 00:02:06.120 no jas and malgaib so it provides you like the 40 00:02:06.280 --> 00:02:10.680 M and MBC or for working with mafugedd B. We 41 00:02:10.800 --> 00:02:15.159 recently released Mongoose nine, big breaking release, first major release 42 00:02:15.159 --> 00:02:17.520 that we've had in two years. Got a few a 43 00:02:17.520 --> 00:02:20.560 few cool new features there, and then we're also working 44 00:02:20.680 --> 00:02:24.280 on a mungo centric muggedy b gooy called Magus Studio 45 00:02:24.759 --> 00:02:27.039 that would like to take some time to talk about. 46 00:02:28.159 --> 00:02:30.719 And then yeah, there's something else that you want to 47 00:02:30.759 --> 00:02:34.719 talk about. We also are we've been working on a 48 00:02:35.120 --> 00:02:38.639 kind of a plug in with with the data Stacks team. 49 00:02:38.680 --> 00:02:41.719 I guess now they're IBM that what's mongoose talked to 50 00:02:41.919 --> 00:02:46.400 a patche Cassandra via Data Stacks data API. So those 51 00:02:46.439 --> 00:02:49.680 are kind of like three topics that I think we 52 00:02:49.719 --> 00:02:52.280 can discuss related to Magus that are a little bit 53 00:02:52.280 --> 00:02:54.400 of a little bit newer and a little bit less 54 00:02:55.280 --> 00:02:57.360 less of the standard mongoose stuff. If you want to 55 00:02:57.400 --> 00:03:00.400 talk about kind of high level what mongoose isn't one out, 56 00:03:00.439 --> 00:03:02.479 we can talk about that before we can talk about 57 00:03:02.520 --> 00:03:06.759 one of the three new things that are going on. 58 00:03:07.960 --> 00:03:11.319 Yeah, I think like O rms and you know, or 59 00:03:11.319 --> 00:03:13.840 in this case ODMs, which I'm assuming D stands for 60 00:03:13.919 --> 00:03:19.439 document instead of relation, are probably pretty well understood, and 61 00:03:19.479 --> 00:03:22.319 I'm assuming that you provide a lot of the standard 62 00:03:22.319 --> 00:03:26.479 features you see from other O rms or or like libraries. 63 00:03:27.000 --> 00:03:30.000 So let's let's dive into the new features and if 64 00:03:30.000 --> 00:03:31.919 people want to learn more they can go pick up. 65 00:03:32.120 --> 00:03:34.199 I think we've had you on before to talk about Mongoose, 66 00:03:34.240 --> 00:03:36.080 and so they can probably go find an older episode 67 00:03:36.159 --> 00:03:38.719 that gets into the fundamentals of what Mongoose is. 68 00:03:39.879 --> 00:03:42.639 Yeah. I think I've probably been on JavaScript Chad at 69 00:03:42.719 --> 00:03:46.520 least work times in the last twelve years, give or take. 70 00:03:47.039 --> 00:03:49.080 Yeah, we did views on View twice too. I was 71 00:03:49.120 --> 00:03:49.840 just looking that up. 72 00:03:50.039 --> 00:03:52.439 Yeah, yeah, I might need to do views on View 73 00:03:52.479 --> 00:03:55.520 again because Mama's Studio also built a view so that 74 00:03:55.560 --> 00:03:57.919 could be a fun Oh is it really? Oh cool? 75 00:03:58.120 --> 00:04:01.520 Yeah, I'm not doing that podcast anymore, but so we 76 00:04:01.520 --> 00:04:03.479 can talk about it here if you want to. This 77 00:04:03.560 --> 00:04:05.240 is where we try to squeeze in a little bit 78 00:04:05.280 --> 00:04:06.479 of view in job the script here. 79 00:04:07.360 --> 00:04:10.400 Okay, Yeah, that's something we can talk about too. Yeah. 80 00:04:10.879 --> 00:04:13.599 I pretty much all of my software developed in view 81 00:04:13.680 --> 00:04:18.240 these days, unless unless I'm working for a client that 82 00:04:18.279 --> 00:04:22.360 has a strong front end preference. I cool. 83 00:04:22.879 --> 00:04:25.040 So what's new and exciting in mongoos will now. 84 00:04:26.199 --> 00:04:31.040 So Mongsteine, it's less about kind of like flashy features 85 00:04:31.040 --> 00:04:36.399 and more about producing long term friction and specifically to 86 00:04:36.759 --> 00:04:40.279 type script. I think one of the things one of 87 00:04:40.319 --> 00:04:44.360 the major changes that we made was before we had it, 88 00:04:44.399 --> 00:04:48.879 so that's functions like find, which is the general way 89 00:04:48.920 --> 00:04:51.600 that you execute a query to load some documents. In Mongoose, 90 00:04:52.160 --> 00:04:55.240 the typescript types there were very permissive and just let 91 00:04:55.279 --> 00:04:59.319 you pass in whatever you wanted. We for Mongus nine, 92 00:04:59.319 --> 00:05:01.680 we made that more script and made it so that's okay, 93 00:05:01.720 --> 00:05:06.079 we have explicitly strong types or for what parameters you 94 00:05:06.079 --> 00:05:09.600 can pass into a query filter. The advantage there is 95 00:05:09.639 --> 00:05:16.600 twofold and in one one that helps typeescript catch typos 96 00:05:16.680 --> 00:05:19.639 and whatnot. And for developers that don't use type script 97 00:05:19.759 --> 00:05:24.439 very much like me, it helps with autocomplete because before 98 00:05:25.839 --> 00:05:28.680 the fact that it just gave you the fact that 99 00:05:28.720 --> 00:05:32.439 the types where just any object goes into find, that 100 00:05:32.560 --> 00:05:36.319 meant that tools like visual Studio code could figure out, 101 00:05:36.319 --> 00:05:39.680 like what are the properties that you should autocomplete, So 102 00:05:39.759 --> 00:05:42.519 now you actually get nice little auto complete drop downs 103 00:05:42.879 --> 00:05:47.279 or for query filters and the other The other big 104 00:05:47.279 --> 00:05:50.079 thing that we added was was like full a stinc 105 00:05:50.480 --> 00:05:53.319 a sink stack traces support in the sense that we 106 00:05:53.439 --> 00:05:57.439 used we had so longos was originally very callback heavy. 107 00:05:57.920 --> 00:06:02.720 We introduced promises support in twenty fourteen, twenty fifteen, and 108 00:06:02.879 --> 00:06:06.920 now in with our last release. Our previous breaking release 109 00:06:07.000 --> 00:06:10.879 Monkeys eight we got rid of the user facing callback 110 00:06:10.920 --> 00:06:14.920 support in all but one important case, and Alan Mongus 111 00:06:15.000 --> 00:06:18.199 nine there's no more user facing callback support. It's all 112 00:06:18.240 --> 00:06:20.920 a sink a weight, which means you get ACNC stack traces, 113 00:06:21.120 --> 00:06:21.680 which is great. 114 00:06:22.240 --> 00:06:24.160 Okay, I'm still trying to wrap my head around this. 115 00:06:24.240 --> 00:06:24.879 So what do you mean? 116 00:06:25.079 --> 00:06:25.439 Yeah? 117 00:06:26.480 --> 00:06:29.240 I understand that. So I'm I'm always big into debugging 118 00:06:29.319 --> 00:06:32.279 and being able to get you know, traces, or I'm 119 00:06:32.319 --> 00:06:36.439 more of the breakpoint debugger type of person. Uh, whenever possible. 120 00:06:36.839 --> 00:06:43.759 So what's an acyinc stack trace as compared to the alternative. 121 00:06:44.720 --> 00:06:47.879 But if you've worked with stack tracings and JavaScript, you've 122 00:06:47.879 --> 00:06:51.519 probably seen things like processed next tick and rejection or 123 00:06:51.680 --> 00:06:55.439 list not on timeouts. Those kind of stack traces where 124 00:06:55.759 --> 00:06:58.759 you just where the stack trace doesn't show you the 125 00:06:58.800 --> 00:06:59.920 actual calling code. 126 00:07:01.000 --> 00:07:01.800 That could be a problem. 127 00:07:02.399 --> 00:07:05.160 I've gotten gotten probably a few of those, and the 128 00:07:05.639 --> 00:07:09.439 reason for that is is the asik nature of JavaScript. 129 00:07:09.519 --> 00:07:13.319 Right when you pass a when you pass a call 130 00:07:13.360 --> 00:07:16.000 back into like a set time out function, for instance, 131 00:07:17.399 --> 00:07:21.240 you're losing You're losing your call stack when set time 132 00:07:21.279 --> 00:07:24.480 out calls the function that the callback function that you 133 00:07:24.560 --> 00:07:28.560 passed into set time out. You'll if that function throws 134 00:07:28.560 --> 00:07:33.480 an error, you'll see a stack trace that includes Note internals, 135 00:07:33.680 --> 00:07:38.720 let say okay, and calling it on timeout, you won't 136 00:07:38.800 --> 00:07:42.480 see your code that actually called the set timeout. And 137 00:07:42.519 --> 00:07:46.920 this was especially problematic with the callback based code because 138 00:07:47.720 --> 00:07:50.680 callback based code, you know, runs a synchronously, right, so 139 00:07:51.399 --> 00:07:55.399 you don't see the code that actually called whatever function 140 00:07:55.560 --> 00:08:00.000 is getting the callback, and that may debugging Note apps 141 00:08:00.399 --> 00:08:03.160 for a very very long time basically made every stack 142 00:08:03.199 --> 00:08:04.319 trace and industry. 143 00:08:06.160 --> 00:08:08.560 Yeah, other words, you're getting everything but what you want, 144 00:08:08.639 --> 00:08:12.519 right and getting and you're not. 145 00:08:12.560 --> 00:08:17.199 Getting your own code. Oh yeah, with a six stack traces, 146 00:08:17.560 --> 00:08:20.759 it's pretty sure. Yeah, A six stack traces is like 147 00:08:20.800 --> 00:08:23.160 a V eight feature, so it also works in Chrome. 148 00:08:24.680 --> 00:08:27.399 But the idea is that if you're calling a sync 149 00:08:27.480 --> 00:08:32.799 functions all the way down, even if the actual error 150 00:08:33.039 --> 00:08:37.279 is a synchrons, you still get the full stack trace 151 00:08:37.399 --> 00:08:40.879 of the actink functions that you call. So let's say 152 00:08:40.919 --> 00:08:43.080 you know, you I'm in function I'm in an AC 153 00:08:43.240 --> 00:08:46.519 function called A. I call an AC function called B, 154 00:08:46.759 --> 00:08:51.200 which calls an ACC function called C, which has a timeout, 155 00:08:51.240 --> 00:08:55.720 and then throws an error after five seconds. The stack 156 00:08:55.799 --> 00:08:59.519 trace for that error will include ABC, it won't include 157 00:08:59.559 --> 00:09:01.919 any I won't to cleave like the known internals for 158 00:09:02.159 --> 00:09:03.360 on timeout or whatnot. 159 00:09:04.679 --> 00:09:08.720 Well that's really handy, Yeah, but there. 160 00:09:08.159 --> 00:09:10.480 Is you need to You need to make sure you're 161 00:09:10.480 --> 00:09:13.960 calling ACYNC functions all the way down. So the instant that, 162 00:09:14.080 --> 00:09:18.159 like somewhere in your internals you start calling something that's 163 00:09:18.200 --> 00:09:22.679 callback based or call a set time out, you're going 164 00:09:22.679 --> 00:09:24.519 to lose the A six stack traits and then you're 165 00:09:24.559 --> 00:09:28.440 back to where you started. So the work of there 166 00:09:28.639 --> 00:09:30.840 for Mongoose was to get rid of all of our 167 00:09:30.879 --> 00:09:36.279 callback based internals pain point there was like the one 168 00:09:36.320 --> 00:09:39.799 of the primary ways that you wrote Mangoose middleware was 169 00:09:39.799 --> 00:09:45.639 was using callbacks specifically gang like you would say Schema 170 00:09:45.679 --> 00:09:50.039 dot pre save. You would get a next callback, kind 171 00:09:50.039 --> 00:09:53.000 of similar to Express middleware, where you would call next 172 00:09:53.000 --> 00:09:55.159 in order to kick off the next middleware and the chain. 173 00:09:56.320 --> 00:09:58.720 We had to remove that in order to properly support 174 00:09:58.759 --> 00:10:00.480 acing stack traces all way through it. 175 00:10:03.840 --> 00:10:06.799 Gotcha. So is there anything you have to do specifically 176 00:10:06.840 --> 00:10:09.039 to get this to work? Or you just upgrade to 177 00:10:09.080 --> 00:10:10.639 Mangouse nine and then you're good to go. 178 00:10:11.399 --> 00:10:15.039 Yeah, upgrade to Margus nine. Any plugins or middleware that 179 00:10:15.279 --> 00:10:20.399 uses that use it next needs to be rewritten. Thankfully, 180 00:10:20.759 --> 00:10:25.679 hopefully that's not too many right now. But yeah, but 181 00:10:25.960 --> 00:10:28.279 in the age of AI, it's much easier to refactor 182 00:10:28.679 --> 00:10:31.159 this sort of thing. Yeah, so I'm a little bit more, 183 00:10:31.480 --> 00:10:35.480 a little bit less concerned. Actually, that was pretty much 184 00:10:35.480 --> 00:10:40.159 like my first foray into AI code generation a long 185 00:10:40.200 --> 00:10:45.639 time ago was was refactoring some of Mogus's callback based 186 00:10:45.679 --> 00:10:54.080 code into put into using a Sika weight. This was probably, 187 00:10:54.120 --> 00:10:58.840 i want to say, early twenty twenty three. This was 188 00:10:58.840 --> 00:11:02.559 like before pers or anything where you could easily select 189 00:11:02.600 --> 00:11:05.559 a bunch of code and pass it into pass into 190 00:11:05.919 --> 00:11:11.440 open AI. What I did was I I wrote some 191 00:11:11.480 --> 00:11:14.759 code to basically parse out some of Maugus's test suites 192 00:11:15.200 --> 00:11:19.080 into individual tests and then would pass those tests one 193 00:11:19.080 --> 00:11:22.000 by one into open ai is a book API, and 194 00:11:22.000 --> 00:11:25.039 tell it, tell it to refactor this into into a 195 00:11:25.159 --> 00:11:28.480 synco weight based code. And even back then it did 196 00:11:28.519 --> 00:11:30.919 a really good job, got like probably ninety percent of 197 00:11:30.960 --> 00:11:33.799 the test suite done, and it took me. It was 198 00:11:33.840 --> 00:11:37.279 a like this whole the whole project of refactoring all 199 00:11:37.320 --> 00:11:40.519 the tests, like we have thousands of tests, and I 200 00:11:40.639 --> 00:11:44.279 was working like eight hours a day for several days 201 00:11:44.320 --> 00:11:46.200 straight trying to read back through all this, and then 202 00:11:46.240 --> 00:11:48.759 I just was like, I'd even tooled for the piss. 203 00:11:48.840 --> 00:11:53.200 This is getting insane. So uh yeah, I tried open 204 00:11:53.279 --> 00:11:57.120 AI and Opening I did a great job. That made 205 00:11:57.120 --> 00:11:59.159 it a one day project as opposed to a multi 206 00:11:59.200 --> 00:11:59.960 week project. 207 00:12:01.200 --> 00:12:04.360 Yep, yeah, I'll have to I have to say that 208 00:12:04.399 --> 00:12:07.000 I've used some of those same kinds of features for 209 00:12:07.080 --> 00:12:10.399 a number of things, just just to increase my test 210 00:12:10.440 --> 00:12:14.240 coverage or hey, you know I need to yeah, rework this, 211 00:12:14.519 --> 00:12:17.480 or you know, rethink that, or even add a feature, 212 00:12:18.320 --> 00:12:22.360 and yeah it it does a pretty decent job. Usually 213 00:12:22.399 --> 00:12:25.159 I have to go in and refine a handful of 214 00:12:25.159 --> 00:12:27.320 things and I have to look over the code make 215 00:12:27.360 --> 00:12:31.159 sure I didn't do anything stupid. But it's amazing what 216 00:12:31.240 --> 00:12:33.840 you can get done with AI these days. 217 00:12:34.519 --> 00:12:41.759 Yeah, I am the other. A couple of weeks ago, 218 00:12:41.879 --> 00:12:44.320 I gave a demo of some new map features we 219 00:12:44.360 --> 00:12:47.000 built in Mongoo Studio, and one of the things that 220 00:12:47.039 --> 00:12:51.600 I demoed was was the ability to just like, so, 221 00:12:52.000 --> 00:12:55.000 I have a one of my clients has a region model, right, 222 00:12:55.120 --> 00:13:00.799 It's a region is like a geopolygon forever defining just 223 00:13:00.840 --> 00:13:02.840 like a region where they have operations. You draw a 224 00:13:02.879 --> 00:13:06.279 polygon in a map that represents Dallas, and this kind 225 00:13:06.360 --> 00:13:10.120 represents the boundary of what the company's operations thinks of 226 00:13:10.200 --> 00:13:14.519 as Dallas. So creating new regions can be annoying because well, 227 00:13:14.600 --> 00:13:16.759 you need to figure out a way to get all 228 00:13:16.799 --> 00:13:20.960 the DFAs on points. But I demoed a way where 229 00:13:21.000 --> 00:13:24.639 you just lai, like, hey, create a create a region 230 00:13:25.159 --> 00:13:28.879 representing Boston. And while it didn't do a perfect job, 231 00:13:29.039 --> 00:13:31.799 Mugus Studio's willing to go into Maungus Studio and drag 232 00:13:31.919 --> 00:13:35.879 the other urgencies around. But like, yeah, I just like 233 00:13:36.399 --> 00:13:38.679 basic models already know off the top of their heads, 234 00:13:38.919 --> 00:13:43.919 like where like the approximate lads to longitude of Boston, Massachusetts, 235 00:13:44.480 --> 00:13:48.120 or or boise iaho or any pretty much any major city. 236 00:13:49.679 --> 00:13:53.799 So it makes things, Yeah, a lot of if you 237 00:13:53.840 --> 00:13:56.000 do a lot of really amazing things or amazing seeming 238 00:13:56.039 --> 00:13:58.279 things with models there just off the shelf, if you 239 00:13:58.399 --> 00:14:01.799 let them, and they do give you a good enough 240 00:14:01.879 --> 00:14:03.240 job to at least get you started. 241 00:14:04.639 --> 00:14:06.720 Yeah, if you give them a function that'll let them 242 00:14:06.759 --> 00:14:08.919 talk to the internet too. Sometimes if they don't know 243 00:14:08.960 --> 00:14:11.559 the answer that they have enough context to go and 244 00:14:11.559 --> 00:14:15.120 look it up somewhere, and so that that's the other 245 00:14:15.159 --> 00:14:17.720 piece to that that I found is Okay, here's how 246 00:14:17.759 --> 00:14:22.480 you here's how you make a call, and it's like, oh, okay, 247 00:14:22.679 --> 00:14:24.080 so what is mango studio. 248 00:14:25.159 --> 00:14:28.759 So MUGAs studio is a gooey for magaritib that's a 249 00:14:28.799 --> 00:14:32.559 little bit more higher level than than a traditional database viewer. 250 00:14:33.639 --> 00:14:37.600 It's got we're trying to make it one more schema 251 00:14:37.639 --> 00:14:42.480 a whare in the sense that in magerty B or 252 00:14:42.799 --> 00:14:45.360 maggityb gooies typically don't have a notion of a schema 253 00:14:45.440 --> 00:14:49.360 right because doesn't really have schemas by default. But magis 254 00:14:49.360 --> 00:14:51.720 who do have a schema, and that lets you fill 255 00:14:51.759 --> 00:14:55.480 in things like autocomplete and auto suggest so like auto 256 00:14:55.919 --> 00:15:01.080 field names when you're typing in the life or filter 257 00:15:01.159 --> 00:15:05.679 input for why. We're also adding a bunch of AI 258 00:15:06.159 --> 00:15:12.000 elements in the sense that you can good concrete example, 259 00:15:12.879 --> 00:15:14.279 what do you try when you want to create a 260 00:15:14.320 --> 00:15:16.720 new document in your database. There's like a nice button 261 00:15:16.720 --> 00:15:20.000 you clip to insert in your document, right, and then 262 00:15:20.039 --> 00:15:22.840 you get a code input that tells that what you 263 00:15:23.039 --> 00:15:25.919 enter in. Okay, I'm going to enter get a creative 264 00:15:25.919 --> 00:15:30.919 documents properties, but that can be a little annoying to 265 00:15:31.080 --> 00:15:33.440 type out manually. So we also have an AI input 266 00:15:33.480 --> 00:15:36.320 there where you say, okay, let's let's ask the AI 267 00:15:36.440 --> 00:15:39.879 to generate a document right there without having to go 268 00:15:39.919 --> 00:15:44.840 anywhere els And that's kind of how the Boise Idaho 269 00:15:45.000 --> 00:15:48.360 region example worked, just you know, instead of instead of 270 00:15:48.440 --> 00:15:51.879 typing out the entire all the details for the Boise 271 00:15:52.000 --> 00:15:55.399 Idaho region, I just have a quick little AI input 272 00:15:55.759 --> 00:15:59.759 that already has the context of what the schema definition 273 00:15:59.919 --> 00:16:04.240 is for this particular document, as well as what the 274 00:16:04.360 --> 00:16:08.000 user is asking, create me a region with for representing 275 00:16:08.120 --> 00:16:11.840 plays of Idaho, and then the AI just goes in 276 00:16:11.879 --> 00:16:15.519 and generates the generates the output, the user confirms or 277 00:16:15.559 --> 00:16:18.679 rejects and can edit it a little bit extra selves 278 00:16:19.000 --> 00:16:23.799 looks create. So there's that, and then we're also working 279 00:16:23.919 --> 00:16:27.879 on things like MCP server. So if you have a 280 00:16:27.919 --> 00:16:31.600 production deployment, well you'll have an MCP server that you 281 00:16:31.639 --> 00:16:36.039 can connect Claud too that lets you do have a 282 00:16:36.240 --> 00:16:40.200 controlled code sandbox access like you can let Claud have 283 00:16:40.399 --> 00:16:44.120 say read only access to your production data or or 284 00:16:45.080 --> 00:16:49.919 access to write certain collections but not others. For a 285 00:16:49.919 --> 00:16:51.120 little bit more security. 286 00:16:53.240 --> 00:16:55.519 Yeah, that makes sense, I mean, and we're seeing this 287 00:16:55.559 --> 00:16:58.000 more and more right where people are integrating AI into 288 00:16:58.039 --> 00:17:05.319 their setup, right, and you know, whether it's taking user input, 289 00:17:05.559 --> 00:17:09.799 so the user essentially is chatting with the AI system 290 00:17:10.079 --> 00:17:12.880 or at least giving it some kind of prompt or 291 00:17:12.960 --> 00:17:19.519 sometimes I've seen folks just basically say the LLM is 292 00:17:19.559 --> 00:17:21.599 going to do a good enough job if I ask 293 00:17:21.640 --> 00:17:23.720 it to do this job that I don't actually have 294 00:17:23.759 --> 00:17:27.839 to write explicit code and cover all the edge cases 295 00:17:27.960 --> 00:17:29.559 and make sure that it does the thing that I 296 00:17:29.599 --> 00:17:32.640 needed to do. And so both of those scenarios sound 297 00:17:32.640 --> 00:17:35.799 really really helpful with something like Mongoose, where you can 298 00:17:36.000 --> 00:17:39.640 essentially say all right, you know, yeah, here are the 299 00:17:39.680 --> 00:17:45.279 credentials for getting information from my data or you know, 300 00:17:45.319 --> 00:17:49.240 here's how you query my data, and then yeah, effectively, 301 00:17:49.319 --> 00:17:52.680 then it has much better information to go off of 302 00:17:53.480 --> 00:17:56.720 to solve the particular problems that my system or my 303 00:17:56.839 --> 00:17:57.559 app is solving. 304 00:17:58.319 --> 00:18:02.640 Yeah, exactly the longer. In addition to having your STEMA definition, 305 00:18:02.799 --> 00:18:05.839 we also have access to things like methods and statics 306 00:18:05.839 --> 00:18:10.279 that you define on your on your models, right, So 307 00:18:10.359 --> 00:18:14.000 that means that well, Mungas Studio can be aware to 308 00:18:14.000 --> 00:18:16.960 some extent of how you write your code and how 309 00:18:16.960 --> 00:18:22.160 your application works. But it's a more application centric or 310 00:18:22.200 --> 00:18:26.640 developer centric database SCOUI. That's meant that's meant to help 311 00:18:26.680 --> 00:18:30.720 developers do their jobs and be less kind of DBA centric, 312 00:18:31.039 --> 00:18:33.519 which I find a lot of whether database scoes to be. 313 00:18:35.160 --> 00:18:38.240 So does it just send a list of available functions 314 00:18:38.279 --> 00:18:42.680 to claude when it you know, kind of like MCP, 315 00:18:43.559 --> 00:18:45.920 or it doesn't have to be MCP. Sometimes you send 316 00:18:45.920 --> 00:18:46.839 a list of functions. 317 00:18:47.960 --> 00:18:52.160 So we have so for cases like the like the 318 00:18:52.240 --> 00:18:55.480 creat input and the chat tab places where we have 319 00:18:56.559 --> 00:19:01.640 AI inputs in the UI, there we we call we 320 00:19:01.759 --> 00:19:04.119 call out to either like the Gemini a p I 321 00:19:04.160 --> 00:19:07.839 and the chat API or prop a KPI, and we 322 00:19:08.119 --> 00:19:11.359 pull the context like we have a collect or. We 323 00:19:11.400 --> 00:19:17.400 have internal storage that stores just descriptions of the users models, 324 00:19:17.880 --> 00:19:23.359 including including the bodies of statics and methods, including STEMA definitions. Okay, 325 00:19:23.960 --> 00:19:27.559 so that data gets passed over there for the m 326 00:19:27.680 --> 00:19:34.440 CP server. What we do with the server, uh, well there, 327 00:19:34.480 --> 00:19:36.279 I think what we passed back is more along the 328 00:19:36.279 --> 00:19:41.599 line of like a typescript definition of what models are available. 329 00:19:43.160 --> 00:19:45.200 Right, and then it just comes back and calls into 330 00:19:45.240 --> 00:19:46.920 whatever it needs in order to do what it needs 331 00:19:46.960 --> 00:19:47.200 to do. 332 00:19:48.480 --> 00:19:51.599 Yeah, exactly what the MCP server what we're experimenting with 333 00:19:51.880 --> 00:19:54.680 is kind of like a code sandbox effectively for the 334 00:19:55.000 --> 00:19:59.160 for the l l M. So we're so like the 335 00:19:59.200 --> 00:20:01.240 way that our MP server works is more long the 336 00:20:01.240 --> 00:20:04.279 lives of here. The MCP tool is here, execute this 337 00:20:04.400 --> 00:20:08.279 code in your sandbox, right, and the AI just kind 338 00:20:08.279 --> 00:20:10.480 of gets the context of like this is what's available 339 00:20:10.519 --> 00:20:15.680 on the sandbox. So that's what we're experimenting with, trying 340 00:20:15.720 --> 00:20:18.039 to figure out how that can work. The other option 341 00:20:18.160 --> 00:20:20.400 that we're thinking of is almost like a CLI tool. 342 00:20:21.559 --> 00:20:24.039 That's something I've been debating on Twitter and to make 343 00:20:24.079 --> 00:20:27.119 it back myself as to whether whether I go the 344 00:20:27.240 --> 00:20:30.319 m CP route with the code sandbox, whether I just 345 00:20:30.359 --> 00:20:33.400 have like a c l I or where the line 346 00:20:33.759 --> 00:20:35.160 it's a CLI to do stuff. 347 00:20:36.519 --> 00:20:40.359 Yep makes sense. 348 00:20:44.799 --> 00:20:46.400 Yeah, I was just going to say, where has I've 349 00:20:46.400 --> 00:20:49.759 been doing some searching where's the Mango U? I keep 350 00:20:49.799 --> 00:20:51.960 finding the Mango studio what you call it? Because I 351 00:20:52.000 --> 00:20:53.200 keep finding studio three T. 352 00:20:54.200 --> 00:21:02.359 Many planks for on the website is mongoostudio dot app? Yeah? 353 00:21:02.559 --> 00:21:03.279 All one word. 354 00:21:06.359 --> 00:21:08.880 Yeah, I keep forgetting about these new TLDs we have. 355 00:21:11.039 --> 00:21:14.160 Yeah, and this is so is this something that I 356 00:21:14.160 --> 00:21:17.200 can post on my own? Oh I see in your 357 00:21:17.480 --> 00:21:22.480 video example on here that it's it's got to dot versell. Yeah, 358 00:21:23.000 --> 00:21:24.599 so it looks like you can. You can play it 359 00:21:24.640 --> 00:21:25.960 out to wherever you need. 360 00:21:26.160 --> 00:21:30.839 Yeah, exactly. We support Brusell Netlify and express right now. 361 00:21:33.680 --> 00:21:37.200 So if you have a Verseell deployment, yeah, you don't 362 00:21:37.240 --> 00:21:38.680 even need next j ask them to think of it. 363 00:21:38.720 --> 00:21:42.039 If you have a versall mangu Studio as a sidecar 364 00:21:42.119 --> 00:21:45.920 alongside your interesting application, or you can just run Mungu 365 00:21:46.000 --> 00:21:50.920 studio for local usage and you still get mostly all 366 00:21:50.960 --> 00:21:53.400 the features. I think a couple of things that are 367 00:21:53.440 --> 00:21:57.119 missing or we don't support dashboards for local development. All 368 00:21:57.200 --> 00:22:00.279 we do support have like the basic database you were 369 00:22:00.319 --> 00:22:04.720 and the chat chat tab is our kind like a 370 00:22:04.799 --> 00:22:10.119 chat GPT interface for generating for generating scripts that execute 371 00:22:10.160 --> 00:22:17.160 in the momy studio code sandbox, and I think that one. 372 00:22:17.480 --> 00:22:22.039 The chat tab also gives addresses like one limitation I've 373 00:22:22.039 --> 00:22:26.200 seen with MCP which may not be as relevant after 374 00:22:26.440 --> 00:22:30.640 last week when they announced MCP apps, but before MCP 375 00:22:30.759 --> 00:22:33.160 apps came out like about a week ago, there was 376 00:22:33.200 --> 00:22:36.240 no way for MCP to really generate like non trivially. 377 00:22:36.400 --> 00:22:39.279 Why so, one of the things that I wanted from 378 00:22:39.319 --> 00:22:41.400 the chat tab from the very beginning is the ability 379 00:22:41.440 --> 00:22:44.599 to generate scripts or to generate charts and maps from 380 00:22:44.880 --> 00:22:48.759 from after language. So the ability to say things like, 381 00:22:49.000 --> 00:22:51.799 give me a chart of users created by day for 382 00:22:52.079 --> 00:22:57.599 the last two weeks. Being able to do that is 383 00:22:57.759 --> 00:23:01.359 what the chattab is good at. But MCP did not 384 00:23:01.480 --> 00:23:03.759 really have any meaningful way to do that up until 385 00:23:03.839 --> 00:23:07.000 very recent So we're figuring out how to do the 386 00:23:07.720 --> 00:23:10.000 MSP app side. 387 00:23:10.960 --> 00:23:16.880 Cool. Yeah, I'm just looking at this and thinking to myself, 388 00:23:17.440 --> 00:23:21.079 I typically use a relational database, but if I were 389 00:23:21.160 --> 00:23:25.319 using Mango TIB, I mean, having something like this just 390 00:23:28.000 --> 00:23:30.000 it makes it easier because you get to the place 391 00:23:30.039 --> 00:23:33.160 where being able to visualize a lot of this stuff, 392 00:23:34.519 --> 00:23:36.279 it just it allows you to think about it in 393 00:23:36.279 --> 00:23:38.759 a different way rather than being stuck in your CLI 394 00:23:38.960 --> 00:23:39.319 or something. 395 00:23:40.000 --> 00:23:42.640 Yeah. Absolutely, And you'd be surprised how many times like 396 00:23:43.400 --> 00:23:45.839 a bug is difficult to spot when you're looking at 397 00:23:45.880 --> 00:23:48.400 a traditional kind of like rods and tables data. Basically 398 00:23:48.519 --> 00:23:50.559 the gids that you look at a chart, You're like, oh, 399 00:23:50.599 --> 00:23:55.200 that's a bug I actually spotted, Like from one of 400 00:23:55.240 --> 00:23:57.119 my clients, I spotted a bug that was costing them 401 00:23:57.240 --> 00:24:01.200