RX 24 - Lava 201 - Mark Lee

Transcribed Content

We're just going to get started. Hey, this is Lava two zero one. This was originally called Advanced Lava. I found out that this was actually renamed to two zero one as I got to the conference. So all right. Hi, I'm Mark. I used to be a children's minister. Now I hack rock. You can guess what company I work for. So this is Advanced Lava and advanced is such a subjective term. It's going to mean a lot of different things for a lot of people. Some folks, you know, they're going to think, Oh, you know, we're going to print more harder lava. Or we're going to, you know, for me I'm so I'm like, oh we're going to code our own Lava. But really what I want to talk about more is the theory behind why Lava behaves the way it does. I talk to a lot of people and they know SQL and they love SQL and they're very smart and then they start trying to use like Lava in a workflow and they're just absolutely flabbergasted and they're like why doesn't this work like SQL? So I want to go into a lot more theory of this and I want to kind of use the example of when I was a youth minister, I learned how to play guitar and I found out that you can just go on YouTube and they will teach you how to play your favorite guitar solo. But if you want to know how to write your own music, you're going to need to know a little music theory, whether it's through osmosis or through like some formal training. In the same way, if you want to have a conversation with you know, somebody from another country, you can use a guidebook to ask them where the bathroom is. But if you want a meaningful conversation, you're going to need to know how that language works and how it interacts with their culture. And in the same way, I want to help you guys go from, oh, I can copy some code, some lava that I found on the community or maybe you've been unfortunate enough to try to ask Chip AI who is notoriously, he's notoriously inaccurate and kind of understand like why does Lava behave the way it behaves. For example, person dot nickname. Okay. So I know that this will print the person's nickname and I can kind of surmise that Lava knows who that person is and is going to go into the database, find the first name column and it's going to print that on the page. But if I do person dot full name, that also works but I can't select full name from person in SQL. So we know something's happening behind the scenes there, right? It's not just grabbing data straight out of the database. And here's another one, person. Birthdate works, okay. But person. Baptismdate doesn't work. Even though I can see them on the same profile page for somebody, one works and the other doesn't work and this is the advanced level class. You guys know this is an attribute. I have to use pipe attribute baptism date. But why doesn't this work? If I have a workflow and I get a person from an attribute, I can't get their baptism date this way. Why doesn't this work? And to make it even more complicated, person. Baptism date used to work. And to make it even more complicated, person. Birthdate and person pipe attribute baptism date will both print date but in different formats. So the goal of this talk, my wife hates this slide by the way. She wants to organize the cables. The point of this talk is to kind of unravel and figure out what's happening behind the scenes. And instead of kind of taking rock and trying to piece through the ten plus years of development and why it works the way it works, I think it might be simpler to kind of start the opposite way. And we can develop our own like little toy church management system and then try to apply Lava to that. And so we're going to use the greatest database that was ever created by mankind. But you know, it's basically what it is, okay. So we're going use Lord of the Rings characters and we can make our person table and we can make all of our columns for data. So Microsoft Excel gives us that free, you know, all IDs on the side there, that's why it's the best. And we can create our columns, so first name, last name, email address and we have just made a church management system. Like I don't understand why it takes a whole year to come up with a new version of Rock. All right, fine. We need a little bit more. We need some more, right? So we have a group table, okay. So we have, now it's a real church management system but I want to put people into that, into groups, right? And so when I think about that, like how do I do that on Microsoft Excel? Like I can't just have like a group member section and then like try to shove a bunch of people into a cell. Like that's not going to work, right? And you guys use Rock, you know this. There's a group member table, okay, which is going to join that all together and it makes things a little more complicated but I can add as many people to as many groups and I can look that up by name and so I can say okay, alright that's the one from the first books and then so that guy was only from the second books and this is very similar to how Rock works. And I can even imagine how this works in SQL, right. This is very straightforward. I can join against the groups and members and I can get their first name and their last name and the name of the group and that works really well. But how do I put that on a webpage? How do I put this in an email? And that's the point of Lava, right? The point of Lava is it's a templating language. It's going to take the data that Rock gives us and lets us template that and put that on a page more simply. But looking at this, there's some major differences, right? For example, our SQL is more prescriptive. I want this data in this format filtered by this and just give it to me all at once. Our lava is much more procedural. We're going step by step. Hey, get me the group name. Now go through each of the members in the group and get that person and print their full name. So there's a procedural aspect. So when we think about like, I want to think about this in SQL terms, we can't really do it. They're not the same. And on another, continuing this thought is, you know, in our SQL, that bottom line there where group ID equals one, we're not actually selecting the group in our lava. So you can imagine this might be a group toolbox page that we want to display every person in our group on and that group toolbox is going to supply us that group. Or if this was an email, it's going to supply us the person we're sending it to. Or if we're on a webpage, it's going to supply us the current person. And so SQL and Lava are going to act very differently. And so when we think about like, oh I want to hook SQL into our little toy church management system. Okay, we need to hook the Lava excuse me, not SQL. We don't hook Lava into our Excel church management system. We're just going to make them talk to each other. But this is not how Lava works. Lava is just a templating language. It just takes the data that ROC supplies to it. It doesn't actually talk to the database. In fact, Lava like many of us has to get its data delivered to it by Amazon. By entity framework I meant. But I like to think of it like entity framework. So you guys have been to IKEA and if you want to get some furniture from IKEA, you got to go down into the warehouse, you've got to go to the exact row, you've got to find the exact style you want. If there's three boxes, you've to make sure you put all three of those on the cart and you've to wheel them out yourself. That's how SQL works. Entity Framework, is what Rock is built on, works a lot like the Amazon man. Hey, I want this. And Entity Framework will go into the database on your behalf, put all the data into, I like to think of it as a box. The correct term is an entity or an object. It's just a box of data. He will box up the data for us and deliver it. So in this example we had before, know we're going to have like a group toolbox block. It's going to ask Entity Framework on our behalf to box up that object which is the group. And so we can say, okay, well what are the things that are in the box? Well it's the same things that are in the columns of our group table. So when I say group dot name, I'm saying in SQL you call those columns. In an object, we're going use the word property. Okay, so there's like your lexicon for us. So we have an object, an entity, that box of data and it has properties. SQL has rows and columns. This isn't SQL, these are objects. So they have properties. So it's the same thing but it's the same thing that's in the rows. So when we say group dot name, we're telling Lava find the object called group and get the property name and print that on the page. But there's another one which is members because remember how I really wanted to shove all the members into that one cell? Well Entity Framework already knows about these relationships. Rock tells them about these relationships. So it's able to add additional things. So what is members? What's the members property? What's another box of data? In fact in this case, it's a collection of group members, okay. So that's where we get our four member and group members. We're saying in the members box, I want to go through each and every one of those group member objects and pull that out, all right. And we're going to assign it to the name member, okay. So for member and group member and I can look inside that member box which is itself a group member and it's the same properties we had in that junction table except entity framework is really nice like the Amazon guy and he's pre boxed up additional objects for us and made new properties on our behalf. And so there's a group object which is the exact same object we just started from. So you can just go in endless circles over and over again in here if you wanted to but that's not the one we want, right? We want to get the person information. So we have member dot person dot full name. That does not show up the very light text. There's some light text around there. Sorry about that. And I can look inside that person box and see what's inside there and it's the same thing. So we say person. Fullname. We're going to print fullname. Now remember before we said okay, the Amazon guy, he gets that data, he boxes it all up. Well, just like an online service, we can tell Entity Framework, hey, would you just make up some data for us and put it in the box? And so we can say, hey, make up a new property called full name which is just first name plus a space plus full name and full rock, it's like a little more complicated than that. But we can just say hey, when you go get data from the database, wouldn't you just make up additional data based upon it and relationships and everything like that. And so when we say person. Fullname, we're saying hey, you made up some data. Please print that on the page. So one of the things that kind of happens a lot especially if you're used to SQL is you know, you look in the database and you're like, okay, well if first name is not in that person table row, not one of those columns, how do I know that full name exists, right? How do I know that exists? Or how do I know that a group member has members or that, or a group has members or a group member has a person or a group or whatever? So there's a spot in Rock called the model map. So you go to admin tools, power tools, model map and it has every one of these objects, every one of these entities and all of the properties that are accessible with Lava, okay? Whether it's actually the data that's in the database or it's made up data or it's the relationships, you can find them all. So I can actually look at this and I can go, oh, there's our members. And it'll say right there, it gets a collection, we needed that for loop of group members and I can click on group member and I can see all the properties that are available to me in Lava, right. And there's other ones in there that I might not know. So like a group can have a parent group, right. And in SQL you just have a parent group ID. Well I can get the parent group. And if you have a parent group, then I'm going to have child groups. Oh and the property for that is not child group, it's groups. Okay, I can look that up. And it says it's a collection of all the child groups. And so the model map has all the objects, all the entities and their properties and whether you can, how accessible they are from lava, if they're from the database, if they're made up, if they're connected to something else. All right, so let's go back to our toy database and good news, it's really, really taken off. The children's ministry now is tracking everyone's favorite candies. This is great. Good news. You know Bilbo likes M and M's, Gandalf likes Red Hots and Thor and Oakenshield did not survive the battle of five armies at the end of The Hobbit and he does not have a favorite anything anymore. It's very sad. So we have splank data there. But this is good. Now unfortunately, while in Excel we can add new columns of data fairly easily. In a real database like what Rock uses, it's a bit of a hassle to and a lot of work and a lot of consideration just to add a new column of data. So we don't want to add a whole lot of new columns of, okay, there's another one. We don't want to add a whole lot of new columns because it's a little bit of work. Now we can add new rows of data. We could add a new person to our person table but every time we add a new column, it's a lot of work. And so more goodbad news, the church down the street loves our Microsoft Excel database and they want to add all these other columns. And okay, that's fine. It's going to be a lot of work and that man, that we're going to be scrolling back and forth in our Excel table. That's Uh-oh, I just noticed there's there's favorite snack at the end there. We already have favorite candy. So like is candy a snack? Like does that do we do two things? What a church gets on and they're like never snackers or another church is like once candy, always candy. Like I don't, how do we make everybody happy? And all these rows are a lot of work. It would be wonderful if we could add data points as rows and then attribute those to a person and you get where I'm going with that. We have attributes in Rock. So we can create data points as we need to, as our church needs to, as our specific needs are And we can add that to an attribute table. This works pretty good. So like here we have Bilbo ID one and his favorite snack is M and M's and his favorite shirt size is youth large. And we can look that up and it works pretty good but there's a couple problems. One is you're going to have to put an attribute row for every attribute for every person. That's a lot of rows and Thorin Oakenshield still has blank data. He's never going to have any values in those rows. We just tons and tons of blank rows. And so the solution we can do is we can actually break that up between the attributes and the values, the attribute values of that. And this makes things kind of challenging. So like Gandalf here who is person ID two, his favorite snack which is attribute one, we can look that up in the attribute table two and one and it's red hots and so it gives us a lot of flexibility but it's a lot more work to get that data out. And you know, we can even take this a step farther and we can say, well what if I want groups to have attributes? What if I want group members or workflows or connection requests or defined values? And so we can take this one step further and we can say what is, remember how I called the objects entities or objects? What is the entity type? So I can add, say oh, these belong to the people, to person and you know, this study topic here belongs to group. And so in Rock, it uses a very similar system where there's a table for all the attributes for any entity. Any entity in ROC can have attributes and then there's an attribute value table that you've got to do a little bit of mental math. If you've ever had to like join the attribute value table in SQL, you have that flashback to the first time you realized you had to do that but it's a pretty powerful system. Attributes have a lot of like challenges though. Like so they're harder to use. They're gonna be different across each system. You got to look them up. Harder to use generally means slower as well. Attributes can be pretty slow but the nice thing is, so you, we can, Rock does a really great job of having properties when it makes sense and attributes otherwise. So properties have all the benefits except they're not flexible. Attributes are flexible but they're really hard to use. And so when we go back to our example, person. Birthdate property, right. And we have that pipe attribute baptism date because we need to do that little zig zag thing. And I have ba, you know, person. Baptism date crossed out because that's called, that's an older system called LegacyLava. So if you ever heard LegacyLava, that's what that kind of is. You could do that notation. So if you imagine having like a bunch of attributes on some entities and it's doing that zigzag every time you load the entity rather than just when you want that particular thing, well it's going to slow your system down quite a bit. And so that's why we use that pipe form, that filter. I showed you the model map earlier. So you guys have all seen this UI. This is the attribute editor. And so the big things are there's a key, so we're not going use ID just like Courtney said in the last hour. And so I can, you know, get that baptism date for that and then it'll print that out. And then there's a field type. And when I think about field types, I think, okay, that's the input, right? So that is, you know, if a text field, it's going have a text box, it's a date field, it's going to have like a calendar thing. If it's a person, it's going have a person picker. If it's a group, it's a group picker. Maybe a dropdown. It's going to have that input, right? But the field type also works with lava, works with rock on the output as well. And that field type is going to know what kind of attribute that is and it's going to try to translate that to the best of its ability to be very human readable. So if I do person attribute baptism date, it's going to print off maybe January one of twenty twenty four. But what's actually in the database in that value table is this like ISO standard that no one can read. In fact, it's so unreadable, you probably didn't even realize those aren't the same dates. And so it's, it's trying to give you the most readable version of whatever is in it. So if it's text, it's just going to give you that text. If it's a person, it's going to give you their name. If it's a group, it's going to give you the group's name. If a money thing, it's going to give those commas and periods where they belong. It's going to format that to you for the best human readable experience. So where this comes into a problem is if you have like a workflow. So I might have a workflow and I've got you know, a serving group and I just want to print the people's names on that serving group. This doesn't work because that field type is monkeying with our data. And so let's go back to our database that we had and so like say we had, you know, we have an attribute value and we want to put that group into that attribute value and we've already discussed before, you can't just put data in there, you got to put a reference in there, right? Except in ROCK, there are two forms of ID. There's that integer ID like you see on the screen and then there is what's called a globally unique ID. You've probably seen this, every row of data in the database has these two IDs. And so for attribute values, if we're referencing like a person, a group, another, you know, piece of data in the database, we're not going to use the ID, we're going to use this GUID. And so this is a globally unique ID and the reason why is like if we all went to our ROCK instances and created a new group, the ID in all those groups would be completely different. So if I write a migration that creates a group on, in your system and then I have to make an attribute that references it, I'm not going to know what that ID is. So I can use a GUID instead. So we use GUIDs instead because I can choose what that GUID's gonna be. I can't choose the ID. I can't choose the GUID. And so if all that kind of seems confusing, here's like your bottom line point. When we use properties, you know, like a group member has a group ID, we're to use ID. When it's attributes, we're going to use GUIDs, okay. That's the bottom line. Generally speaking, there's always, you know, asterisk, asterisk, asterisk in this case, whatever. We're just going to simplify it for your sake, okay. So properties, IDs, attributes, GUIDs. So when we get back to this, you might look at this and go, oh, I know this. This is an attribute. It uses the GUID. The value, the reason why this doesn't work is because the value output is going to be a GUID and you're closer but we're not quite. So let's go back to the Amazon guy and and let's imagine we ordered a box of assorted batteries, okay. And so, if we use this format here, this is the equivalent of the Amazon guy coming up with our box of batteries, coming over the door saying, hi, opening the box of batteries, looking inside and going, it's a box of assorted batteries and then throwing the whole box of batteries away, okay. It will print the friendly name of whatever that thing is. So since this is a group, it's going to print the name of the group. If it was a person, it would print the person's name. Okay. It's going do the friendly version. If you want to actually know what is in that, in the database, what is that actual value, you need to add comma, raw value. And this just tells Lava to say no, no, no, don't talk to the field type, just give me whatever that is. Now if I order a box of batteries from Amazon, I would like a box of batteries, right? And so the way you do that is instead of raw value, you say object. I want the actual object. And I changed this Lava format a little bit to say like, okay, we're not going to print the object. I want to assign this to a variable so I can do things later. And that will give us our entity framework object, okay. It's going to be an object or entity. And if you want, you can even get really fancy where you're like the Amazon guy comes up to your house and you're like the smoke detector keeps beeping. I just need the nine volt and he'll just hand it to you. So you can ask for just a single property. So you can say give me the property ID and it will give you the ID. Or you can say give me the parent group ID and it will give you that. Or whatever the property is, you can just ask for that. You know, if you want to buy a box batteries just from the nine volt. Anyways, and so when our example here, group, we're trying to get that serving group into that variable, we need the actual object. So we need to do ask for the object, okay? And so the field type is going to work with LOB and how you handle that is going to matter. And this is where it kind of trips people up a lot of times because they just expect, oh, I'm going to get a group. It's like, no, actually, it's just trying to be very friendly to you. So that was a lot of theory. And now we're going do some more theory. So this slide's called Lava's Lazy. It's actually a lie because Lava, Lava doesn't talk to the data. It's entity framework is lazy but that does not make a good alliteration. So we say that it uses something called lazy loading. Sort of that initial example where, you know I had a box and you know you get that group box, that object, that box of data and I look inside and I get the members box out and it contains all the group members and I start going through that. Well it's the equivalent of you know I get that members box out and I open it up like expecting a whole box of members and I look inside and I go, there's nothing in here. And the Amazon guy goes, oh did you want those group members? And he jumps back in his hand, drives back to the warehouse, gets all the stuff boxed up, runs up to, you know runs back up to me and like drops it inside and goes it's always been in there. And then you're like thank you and you get to the group member, you open that up and there's the person, the person you know object in there You open that up and there's nothing in there and he goes oh did you want that too? And he gets back in his van, drives all the way back to the warehouse, gets the person, it all up with all the special rules that you told it, comes back and just drops it in the box and you're like thank you and then you get the name out and put it on the page and then you get to the next box, person and it's like again? And every single time that we open, you know you think about when we open one of those data boxes, it's not actually going have any data in it until we actually look at it. This is called lazy loading. And this seems a little silly but if you think like, think about how relational everything is in Rock, right? You've got a person and they have a family and that family has family members and they all have groups and check ins and attendances and everything, you don't want, you know, you could basically say, okay, give me this person and like the entire database shows up, right? You don't want that. But this can make your system slow if you're not careful. So depending on how you're using this, if you've got loops within loops within loops, that Amazon guy, he's running back and forth and back and forth and there's only so many Amazon guys, all right. And so the question really when you think about oh this is slow, you should not be thinking I should do fast things or this is slow. You should be asking, does this matter? So if you're doing this in an email and that email, you have a bulk email and instead of it going, taking fifteen minutes for that email to send, it takes an hour to send, does it matter? Probably not. If it's an internal page that five people see once a week, does it matter? No. If it's in a workflow, like you really actually have to get that data so that you can process it. So like most of the time, it's not going to matter. However, we also use Lava on our website a lot, right. So we're going to display our sermons using Lava. Well does that matter then? Probably because every time someone is opening your page, they're getting an Amazon man, right, And he's running back and forth for you. And so you really need to think about like okay, am I really thinking like okay, well one person's not going to break my site but what if it's Sunday morning and people are looking at your website or Monday morning and the new sermon dropped and they're looking at it. So there's some things we can do to speed up lava. So the obvious simple one is caching. So on lots and lots of blocks, can set this thing called cache duration and it's very easy. Like the first person who visits that block, it will render the lava and then everyone else will see that lava. And it's very simple. So oh, it renders all my sermons and we'll just, the output gets printed. So maybe the first person it takes, you know, twenty seconds to run. Everybody else, it'll be instant. There's some downsides to this, some caveats. While it's very easy, current person doesn't work. There's some like meta tags like stylesheet and JavaScript Pro shouldn't use those anyway. But things like I wanna, you know, if you're using Lava to change the title of your page or metadata or whatever, that's not going to work, okay. So just you know, just be kind of aware of that. Another option is there's a entity or not entity, a tag, a cache command, excuse me, that you can use, that you can just use in place. And the nice thing is you can set a key on that and you can use that, reuse that key on different pages. And so it loads on one page and it will save that output and it will be the same for everybody even if it's on different pages. And you can also do this thing called to pass which, you know, this is not really a great example but if you like want to use current person, you can set this true pass equals true and then wrap whatever you want to be rendered on the second time through in raw. So you're actually kind of generating Lava that generates Lava that then gets processed after it's cached. You know, it's kind of a niche case, but it's really useful to know that that exists. So caching's really, really, really easy. Like you just turn it on and it caches but there's some like downsides. So remember I said like a person will see the page and then everybody else will see what they saw? So if you have like things that, you know, you as an admin can only see and you see that and it's cached, everyone can see it, right? That's a problem. Internationalization can also be an issue. So if you have dates or, you know, on a page and somebody from say Korea visits South Korea, visits your site and the month will then be in Korean because it recognized that from your browser and it gets cached that way. Or somebody from, we have in America we've got month, day, year. In Great Britain, it's day, month, year. So the day and the month will get switched to someone from Great Britain, use your site and it gets cached as that. Everyone will have that. In some cultures, the numbers, like the commas and the periods are switched to us in America, that'll be like that. And it can even do things, we've tried to do math before and it breaks it. It's been kind of interesting. So just be aware of that. It's really easy but it has limitations. So another good option is something called a persistent dataset. You'll find this under CMS Tools and and it caches the data rather than the output. And so you create this, you create datasets and you can run Lava. You have to generate JSON and so you'll just generate all whatever sermons you have. And then the nice thing is where it says refresh interval, it will just in the background update the value. So remember how I said you know that cache value, it goes to what the first person saw. Well what if it takes two minutes for that to run? Do you want somebody sitting on your website for two minutes? It's like it's okay. You're saying you're taking one for the team, right? Like so you can have that run-in the background and you cache that data and this is all in the documentation. You guys can read documentation, right? And so you can just read all that out there. But it's a really, really great tool. Another really great tool that I love is Lava Webhooks, All right. So imagine we had a, you know, our sermon page and we get to the bottom there and you get that previous button and the next button and that is not how we do things, right. That's not cool. We need a load more messages button, right. And if you know JavaScript or know someone who knows JavaScript, it's very trivial for them to, you know, load some more data and show more sermons on a page. But where are they getting that data, right? They still have to get that sermon information and so if you look at kind of the raw documentation and you look up API, you'll see about the odata, like the odata dataset. That is not suitable for the web because it opens up too much stuff. Do not use odata on the web, that's my disclaimer. It opens up too much stuff or you have to use a key, right, in the website. Like you have to publicize a login basically in your source code. But you can use Lava webhooks. Now they are hidden in defined types. So you have to go to general settings to find types and then like do a little search for Lava webhook. But you can create a defined value for every Lava endpoint. So here I've got slash messages slash page. So like if you go to mychurch.com/webhook/lavashx, it's a long word thing, slash messages and then that like placeholder of one, it can read that out and you can say like okay, skip, you know, the first, you know, 10 sermons and we'll look up in the content channel and we'll provide that. And so that gives you the ability to like basically make your own Rock API exactly how you need it to be. And I have used this for all sorts of stuff. For like the dynamic content, we run whole apps off of it. You can do interactions and sort interactions. Facebook like little bell icon stuff. And another nice thing is like while you can't secure defined values very easily, current person works. So you can say something like if the current person, you you can do like filtering based upon that and it knows who that person is if they're logged in. So that's really nice. And so like continuing the thought of security, let's talk about like some security implications of Rock. So the first is don't trust user input. And what I mean is imagine I have a website which is mychurch.blog and then one, two, three and that's the ID of the blog entry. Well, what's to keep me from changing the URL to be one, four or to create a script that just goes through all the numbers until I'm tired and get all the data. Well, hopefully you lock down every single content channel and every single content channel item because otherwise it's being scrubbed. And so you really need to think about like okay, what is the user entering and I don't want to trust it. So for example here, instead of just saying like get me that item, I can say okay, get me that item and the content channel has to be this content channel, right. There's a lot of different ways to think about this and link this. The big thing I want you guys to think about is when you have a user input, whether it's the URL or even a variable, I want to say an attribute or a property, a name, a person's name is user input. They can put whatever they want in there. Don't trust it, okay. You to think about how somebody could misuse that. And that's especially true for SQL. I kind of diametrically opposed SQL and Lava but really they're BFFs and you can use SQL to get a lot of data out and then parse it and print it on the page with Lava. But this is something that I see and it's very scary and this is the only slide in my entire talk of good, you know, first bad idea then good idea that I just labeled no bad which is do not put Lava in your SQL because you can try to scrub that. That did not work for Myspace. Okay. Look up that one. They can put anything in there. They can put SQL in there and remember somebody's name is user input. You're like, oh it's fine. I'm just pulling it from my own database but where did that data come from? So do not trust that. Do not do this. What you need to do instead is something called parameters. So that at search, this tells SQL this is a parameter. This is not safe. You cannot trust this And then you're just going to feed that in. They could literally write just straight SQL in the search string and they'll be like yeah, I'm not going to trust this. I'm just going to treat this as a parameter. You can do this in a SQL command. You can do this in a webhook or actually in a workflow where you got the parameters and assign that parameter but do not put SQL or do not put Lava in your SQL. Can put SQL in your Lava but do not put Lava in your SQL, okay. It's really easy. It's really convenient. I wish it wasn't a thing you could do. Use parameters everywhere. Be careful with user permission. The Amazon guy just makes deliveries. He doesn't care if it's a porch pirate or whomever. He's just like here's a box, here's another box of data, here's another box of data. So you can do things like, you know, has rights to view, there's a filter and it'll actually, you can actually check if that's a thing you're kind of worried about. You can say like has rights to view or edit or administrate, any other thing there and you can do that. And then finally, questions, assuming I didn't talk too long.