Description Transcript
Having trouble figuring out why your Retool apps aren’t behaving as expected, or looking to sharpen your debugging skills?
This webinar gives you a practical toolkit for breaking down issues across Apps and Workflows. We’ll walk through core debugging tips and tricks in Retool and show you how to apply them directly in your own builds.
You’ll learn how to isolate root causes, trace unexpected behaviour and steer clear of common pitfalls.
We’ll also look at how AI can speed things up — from explaining errors and spotting patterns to rewriting queries and guiding your next troubleshooting move.
Read more 0:03 Nice. So, let's get cracking. Um, thank 0:06 you so much for joining and and taking 0:07 your time to um participate in this 0:10 webinar. Uh, this is going to be on 0:12 debugging in RTO. Um, talking through AI 0:15 powered troubleshooting for your apps 0:17 and workflows. As an introduction from 0:19 me, I'm Ollie Clyde. Uh, I'm a support 0:21 engineer here at RETL. I have a 0:23 background in software development and 0:25 tech consulting. And unsurprisingly, in 0:27 my day-to-day work with customers, I do 0:30 loads of debugging, helping solve lots 0:32 of their more technical um challenges 0:34 and problems across retail. 0:37 So, let's start with a brief agenda of 0:40 what we're going to use this uh our 0:42 session for. Uh I'm first going to give 0:45 a little introduction around, you know, 0:46 what is debug debugging, why is it 0:48 important, etc., etc., you know, why are 0:50 we here? Um and then we're going to 0:52 spend the bulk of the session going 0:53 through uh the scenario that we're going 0:55 to use and then um spending around 354 0:59 minutes um talking through the scenario 1:01 and we'll give more details around 1:03 instructions um and how you can take 1:05 part or just watch along um for this 1:07 example. And then finally, um, at the 1:10 end, we'll run a little recap talking 1:12 through what were the main points I was 1:14 trying to get across, um, as well as 1:16 hopefully some time, um, depending on 1:18 how fast we go for some questions and 1:20 answers at the end. Um, again, yeah, 1:22 feel free to kind of chuck any questions 1:24 as we go, um, in the chat. Um, but with 1:27 that said, let's get let's get started. 1:29 So, uh, the art of debugging. Um, 1:32 sometimes it feels like an art, 1:34 sometimes like a science. Um I first of 1:36 all wanted to start with kind of why is 1:38 it important you know you know why are 1:39 we here why is it worth um discussing um 1:42 and I think essentially software 1:44 development is just as much about 1:46 debugging as it is about building uh and 1:49 it's kind of such a crucial skill and 1:51 although retool as maybe you already 1:53 know it's makes it far easier to build 1:55 software um and reduces that barrier to 1:57 entry it still requires um some of those 2:00 fundamental software development skills 2:02 and debugging skills um and as quoted by 2:05 Brian Kernahan um who is a famous 2:08 computer scientist. Um he says that 2:10 debugging is twice as hard as writing 2:12 the code in the first place. Um I 2:14 imagine maybe there's been times in your 2:15 life there's been very few in mine but 2:17 I've written a piece of code or built 2:19 some piece of software and it's worked 2:21 first time and I think I'm a incredible 2:23 genius. Um but 99.9% of the times uh I 2:27 get something wrong or I haven't thought 2:29 of an edge case or whatever it may be 2:31 and I need to iterate and um improve 2:34 what I've already built. Um and so it's 2:36 it's really kind of a part and parcel of 2:38 building things um is debugging. Uh 2:42 following that I think it's also worth 2:44 framing this in the importance of 2:47 defining the problem uh before the 2:50 solution. Although we'll mainly talk 2:52 around specific techniques within rout 2:54 retool and some kind of common errors 2:56 that I come across, it is a real real 2:59 common pitfall to get hung up on solving 3:01 a specific problem rather than 3:03 understanding the broader picture. Um, 3:05 and a quote that I I like to keep in 3:06 mind particularly when working with 3:07 customers is if I had one hour to save 3:10 the world, I'd spend 55 minutes defining 3:12 the problem and only five minutes 3:13 finding the solution. Um, from Albert 3:15 Einstein. I think it's a really nice way 3:17 to ensure that we're we're not getting 3:21 stuck in the weeds and obsessed around a 3:23 technical solution, but actually 3:24 understanding kind of what are we 3:25 solving for. I also thought it's worth 3:29 kind of framing this in the in the 3:30 context of of AI um and kind of both 3:33 where retail's going with this um but 3:35 also the wider industry. Um and I think 3:37 you know has this changed this you know 3:39 is debugging as important? Um and I 3:42 think on that first point um I think 3:45 it's you could argue that it's now less 3:47 about understanding specific technical 3:49 concepts or techniques um and more about 3:51 working through problems logically. Um 3:54 and so if anything um obviously I'd be 3:57 biased from from my position and role 3:59 but I would argue that debugging if 4:00 anything is more important um than it 4:03 kind of ever used to be. So you're more 4:04 likely to encounter code bases or 4:06 software or retool apps where maybe you 4:09 don't actually understand how it was 4:10 built um or you know who wrote the code 4:12 or how why it was written in that way. 4:14 Um and actually so you're more likely to 4:16 need to quite quickly understand the 4:19 problem you're trying to solve the 4:20 context around it etc etc. Um and so if 4:22 anything some of those core skills 4:24 around logical thinking and problem 4:26 solving I think are just as important if 4:28 not more so now with AI taking away 4:30 maybe you know some of the technical 4:31 knowledge you may need. And then 4:34 finally, I think an easier point to make 4:36 on on the second around defining the 4:37 problem. Um, I think it's probably going 4:39 to be easier than ever to create 4:41 solutions and build software. You know, 4:43 as I mentioned before, the barrier to 4:45 entry in software development is is 4:47 lowering and and that's particularly as 4:49 we'll talk about with assist, which is 4:51 retools um solution to use natural 4:54 language to build applications. There's 4:56 a greater chance that you're going to 4:57 build solutions that potentially don't 4:58 pro solve real problems. Um, and so I 5:02 think again that that makes this quote 5:04 an area even more important to think 5:05 about. Um, and so we'll touch on this 5:07 again kind of throughout this um, 5:09 webinar, but I think it's an important 5:10 thing to kind of anchor um, as we as we 5:13 go through um, this scenario. And so 5:16 moving on to that, um the scenario for 5:19 today is going to be about our colleague 5:22 Jerry who has built an MVP for a 5:24 software access request portal to help 5:27 demo where the retail can be used to 5:28 manage our company's various software 5:30 providers. Um but he's left for holiday 5:32 in Hawaii before finishing it, leaving 5:34 us to pick up the pieces. Um I think 5:36 it's fair to say we're not a fan of 5:38 Jerry anymore. He's really left us in 5:39 the lurch here. But unsurprisingly, it's 5:42 given us some good sections to run 5:44 through around debugging um and retool. 5:48 So, we're going to have these five main 5:49 sections that we're going to touch on. 5:51 We're going to start with app context 5:52 and the debugging tools. Then, we're 5:54 going to go into root cause analysis. 5:56 So, trying to understand the source of 5:59 of bugs and issues uh within RTO. We're 6:02 then going to get into resource query 6:03 debugging, JavaScript debugging, and 6:05 finish on workflow um debugging. Um to 6:11 um set some context around u kind of 6:13 knowledge for this. Um if you've never 6:16 touched retool, that's perfect. We'll go 6:17 really slowly and you can pick up um 6:20 lots of the basic things around 6:21 debugging within retool. If you have 6:23 used retail before and you're still 6:24 looking to try and find some new 6:26 techniques or new areas you come across, 6:27 I do hope that I will also um provide 6:30 some additional tools or or things you 6:32 haven't learned before. Um so hopefully 6:35 we can we can cover kind of both um kind 6:37 of both scenarios there. So onto some 6:41 logistics. You should have received an 6:43 invite email from our webinar instance. 6:46 It's AMIA um gosh actually what is it 6:50 called? It is called air amir 6:52 agents.retool.com. 6:54 Um, and using that invite email, you 6:56 should be able to log in and create an 6:58 account. Um, if you've joined us before 7:01 also, I could see some had logged in 7:03 earlier. You may need to kind of log in 7:04 again. And that should then take you to 7:06 this instance. Um, and this is if you 7:08 want to follow along um, manually, you 7:11 know, practically with us, you can uh 7:14 set up a copy of an app to then run 7:16 through the scenario with me. or if 7:18 you're not so interested, you can just 7:19 watch along and um watch me do it. Um as 7:23 also that's posted in the chat by Amar, 7:25 we should also have some instructions 7:26 for you to run through as well um if you 7:29 kind of get lost or um want to catch up 7:32 with where we are, but also have a 7:33 written summary of kind of what we 7:34 discussed today. So the main thing to 7:38 set your own app up is to ensure that 7:40 you copy um the main app. So it should 7:44 be once you log in you should be taken 7:46 to recents potent. Hopefully you should 7:48 see it there but if not you may need to 7:49 move to published and search for it. Um 7:52 and you can search for debugging or 7:54 main. 7:56 Um and in doing so you should then be 7:59 able to this ellipses at the side of the 8:02 app. Um you should then be able to 8:04 create a duplicate. 8:06 you'd want to include your email within 8:09 the duplicate just to ensure that um uh 8:11 there's you know there's no copies. If 8:13 you use the same name as someone else, 8:14 it will cause an error. Um and you want 8:16 to hopefully when you create it, you 8:18 should be able to set it um it in by 8:21 default it will set it within your own 8:22 drafts. Um so for example here if I do 8:25 olide at retool.com 8:29 and create the app 8:31 and it should be within my drafts here. 8:33 Um, and so then within those drafts 8:36 folder again at the top, you can then 8:37 click onto the app to then start this 8:39 web webinar scenario with me. Um, I'm 8:43 going to give a little pause there as I 8:44 imagine there may be some questions or 8:46 you're still logging in etc etc and 8:48 maybe I can give another run through um 8:50 if needed. 9:07 Nice. So, hopefully you're sat there 9:08 with your with your drafts tab open and 9:11 a nice copy of the main app. Um, and 9:14 then you can then click through onto the 9:16 app, which will then initially take you 9:17 to the preview. Um, I'm also taking the 9:20 fact that Omar hasn't um shouted at me 9:23 that there aren't any kind of core 9:25 questions or problems so far. So, I'm 9:27 going to take that as a sign to get 9:28 stuck into the scenario. 9:32 So the preview of the app. Um let's just 9:34 take a moment to have a little view of 9:36 what we think is going on here. So I can 9:38 see we have unsurprisingly this software 9:41 access request portal. Um at the top 9:44 there seems to be some KPIs around total 9:47 requests, pending approvals um and 9:49 approved requests. Then seems to have a 9:52 main table which I assume are just my 9:54 software access requests. Um that now 9:58 seems to be empty. And at the bottom 10:00 there seems to be a table for appro 10:02 admins to approve 10:05 um any access requests. It seems to be 10:07 at the top I can refresh but we seem to 10:10 be getting an error. And if I go to open 10:12 a request, okay, I can't seem to find 10:15 select any software. And so clearly 10:16 there's lots of issues here. Um so 10:18 chances are this is kind of some type of 10:21 portal where end users can come on uh 10:23 potentially request um software and 10:25 admins can then um either kind of reject 10:28 or approve that. So now let's go into 10:31 the bulk of uh the webinar which is 10:33 going to be editing and seeing what's 10:35 going under the hood. So at the top 10:37 right you should have the option to 10:38 click edit app and in doing so that will 10:42 then open up the app into this visual 10:44 editor. Um, and this is where we can now 10:47 look under the hood of what is going on 10:49 here. 10:53 So, where where do we start? Where's a 10:55 good place to get going here? Uh, and 10:57 with this newer feature in assist, which 11:00 can be found at the left sidebar at the 11:02 bottom, there should be a little icon 11:04 that you can click on to with assist. 11:06 This is a great place to start to ask 11:10 what does this app do and how is it 11:11 structured. Um, so with assist at the 11:14 bottom, we can select different modes. 11:15 So whether we want to build, create an 11:16 edit or just to ask. So for now, let's 11:20 just ask how does this app work and what 11:24 does it do? 11:26 And hopefully that should give us a nice 11:28 rundown uh of what's going on here, but 11:30 also while this is loading, I'm also 11:33 going to point to some core areas that I 11:36 would always go to when first coming 11:37 across a new app. Um on the sidebar we 11:40 have a load load of useful tools that um 11:42 you're going to come across or when 11:43 building and retool use frequently. The 11:45 first one at the top is pages. So this 11:47 gives a nice overview of if it's a 11:49 multi-page app, what are the page 11:50 structure here? At the moment it's just 11:52 one page. So it's nice and simple. We 11:54 also have the component tree. So this 11:55 gives a nice breakdown of how the 11:58 component structured. Are there any 11:59 hidden components? Um how do they fit 12:01 together? Not so important for today's 12:03 webinar but something to um keep in mind 12:05 and be aware of. And then importantly 12:08 the main section you should have is um 12:10 the code area. So this should give a 12:12 breakdown of quite simply all of the 12:14 logic um that's uh your app is 12:16 functioning on. So such things such you 12:19 know all of your queries, some variables 12:21 um some transformers etc etc. We're 12:24 going to go into this area in a lot more 12:26 detail and some of the kind of core bits 12:28 of this app within it. Hopefully if we 12:30 go back to exist we should now have a 12:32 nice overview of what's going on here. 12:35 So it seemed to have a clear purpose. So 12:37 the app allows employees to request 12:38 access to different software 12:39 applications and enables administrators 12:42 to review and approve and reject those. 12:43 So pretty much exactly what we thought 12:45 when we first had a little overview. Um 12:48 that seems to have that request button 12:49 at the top right where they can have a a 12:51 modal to then submit a request. Um we 12:55 using a retail database to be able to 12:57 store those requests. We have some 12:59 metrics at the top. We have the requests 13:02 table etc etc. and then the approval 13:05 model at the bottom. So when an admin 13:06 clicks to review a request, they can 13:08 approve it and reject it. Now some 13:10 technical architecture which is a really 13:12 useful bit of information to understand 13:14 kind of what's some of the logic that's 13:15 going on here. So we seem to have retal 13:18 database with a mock access requests 13:20 table as well as a postman mock server. 13:23 Um, and so 13:25 they seem to be giving our main uh 13:27 sources of data for this application as 13:29 well as a whole selection of different 13:31 queries um that's pulling or inserting 13:33 data um as well as some transformers um 13:36 that we're going to get into in more 13:37 detail. 13:39 Brilliant. So that's now given us a nice 13:41 overview of what's going on here. I'm 13:43 going to close that for now. And now the 13:45 other area I want to mention is the 13:47 debugging tools. So, at the bottom right 13:50 here, you should have the option to be 13:51 able to open up the debug tools. Um, and 13:54 if you haven't come across these before, 13:56 unsurprisingly, we're going to use these 13:57 very heavily during this session. 14:00 And I'm going to give a little just 14:01 overview of of how they're structured 14:03 and and uh how you can use them. 14:08 So, pardon me. So, it may look familiar 14:10 to some of you um because they mirror 14:13 the dev tools or similar debugging tools 14:16 um on your browser. Um just for those 14:18 that are curious um I always think it's 14:20 kind of um quite interesting to see um 14:22 if you double click on a page um kind of 14:25 outside of the retail visual editor um 14:27 you can see your own browsers dev tools 14:29 and unsurprisingly here you can see both 14:32 the kind of structure of this page lots 14:33 of the code as well as also uh the 14:36 console as well and network requests etc 14:38 etc um and so we've created our own 14:41 retool specific debugging tools that can 14:43 give you lots of information around um 14:45 what's going on in your retool runtime 14:47 time. And so the first page is the 14:49 console. So this will give you an 14:51 overview of all of the successful 14:53 queries, any errors, and also any info 14:55 messages. So for now, we're going to 14:57 filter it. So we just see the errors and 14:59 we just see the info messages. And this 15:02 is the the the main intel that we can 15:04 use to um start debugging. The other 15:07 area I wanted to highlight is the 15:08 timeline. So this gives a visual 15:11 representation of the query execution 15:13 order. So typically all of the queries 15:14 that are fetching or updating data um 15:18 and you can see um information around 15:21 timing of these etc etc. We're not going 15:23 to go into much detail on this now. This 15:25 is mostly mostly useful but for 15:27 performance issues um and the like. 15:31 Uh and the other area is state. So this 15:34 gives you a view of all of the current 15:35 components, queries, variables um etc 15:38 etc that are available um within retool. 15:41 Um what is state? state is effectively 15:44 the the snapshot at this given moment in 15:47 time um of you know all of the 15:49 information um within retool. We're 15:51 going to come into more detail around, 15:54 you know, why is state important, how 15:56 does it work, um, and how you can use it 15:58 to debug a little later on. Um, so it's 16:00 good to be able to flag this now. 16:03 Brilliant. So, I'm going to go back to 16:04 the console and have that nice kind of 16:07 open on the page here. Um, and now that 16:09 we've understood what's going on here 16:10 with the context of the application, as 16:12 well as had a little um, mooch around on 16:15 the console logs, we're now going to get 16:16 into the first kind of main section, 16:19 which is how do you find the root cause 16:20 of bugs? You've come across an 16:22 application and there's a load of errors 16:23 showing, oh no, you know, where do I 16:25 start with all of this? Um, and so we're 16:28 going to talk through kind of two main 16:29 ways to go about this. Um, and 16:32 effectively a great place to start 16:33 unsurprisingly is just to pick one of 16:35 these and use this to work your way 16:37 backwards to find the root cause of the 16:39 issue. Lots of times errors like this 16:42 are showing as symptoms of a issue 16:44 further upstream. And so we're going to 16:46 um we're going to work through a 16:48 scenario together. So to be able to open 16:50 up um and investigate this error in more 16:53 detail, you should be able to click um 16:56 on these on the side here to open up the 16:58 associated query with this error. The 17:01 one that I want to open up um is the one 17:03 that is named all requests with software 17:06 name. So you can see that on the right 17:07 here. For me, it may be different for 17:09 you. It's the fourth one down. And if I 17:11 click onto that, that should then open 17:13 up this transformer for me. And so then 17:16 I can use both the error in conjunction 17:18 here and also uh the transformer open to 17:21 now start debugging um um and finding 17:24 the root cause here. So for those that 17:25 aren't aware, transformers, you know, 17:27 what are they? um effectively they're 17:29 ways that um they're code within retool 17:32 that you can use to write larger re 17:34 reusable blocks of JavaScript. Um and 17:36 unsurprisingly it's typically used to 17:39 transform data. So whether you're 17:41 combining data sets, filtering or or 17:43 kind of whatever it may be so if we have 17:46 a quick run through together of what we 17:47 think is going on here at the top we 17:49 seem to be pulling in uh lots of kind of 17:52 all of the access requests. Then we seem 17:54 to be also getting the software 17:56 providers. Um, and then we seem to have 17:58 a function that is simply combining the 18:00 two. So we've got all of the quest 18:02 requests and we're going to find for 18:03 each request find the associated soft 18:05 piece of software and then we're going 18:07 to match on that and then we're going to 18:09 try and find the uh name of the 18:11 software. Um, and then we're returning 18:13 that so that they're kind of combined 18:15 together. So with that in mind, let's 18:17 get started into kind of analyzing this 18:19 error in more detail. So, as I mentioned 18:22 before, great place to start is actually 18:24 on the error itself. Unsurprisingly, um, 18:26 one thing to note, something that I do 18:28 all the time is I skim read an error and 18:30 then I think, oh, I know what's causing 18:32 this. This is simple. What am I, you 18:33 know, obvious don't take the time to 18:35 actually properly read it and analyze it 18:37 and then, you know, I'm down a rabbit 18:39 hole um when actually if I'd taken the 18:40 time initially, I could have saved 18:42 myself um lots of effort. So, let's take 18:45 a moment to read through this error. 18:47 We've got one error. Software.find is 18:49 not a function. And by clicking onto the 18:51 error, typically in JavaScript, you'll 18:53 always find a bit more information 18:54 around which line it's on. And so we can 18:56 see here it's highlighting line five. So 18:58 if we go to line five in the 19:00 transformer, we can see that 19:02 software.find function. 19:07 Now software defined is not a function 19:10 typically means that the property of 19:14 fine on software um doesn't exist. And 19:17 so in a slightly obscure JavaScript way, 19:19 simply that this is saying software is 19:21 most likely undefined 19:23 um or or kind of not appropriate an 19:25 array to be able to call.find on. Um so 19:28 let's now work our way backwards from 19:30 this using um the first method that is a 19:33 really powerful tool within a retool. Um 19:35 which is being able to hover over any 19:37 piece any variable um within a piece of 19:40 JavaScript within retool to understand 19:42 its current state. So if we were to 19:44 hover over software here we can quickly 19:45 analyze okay well you know it is 19:48 software indefined is it an error and in 19:50 quickly doing so here I can analyze the 19:53 data and I can see yeah there's there's 19:55 a clear error going on here and an error 19:57 message bad request etc etc so that is 20:00 undoubtedly must be causing this 20:02 software.find defined error in the 20:04 console. Um, and if we take a moment to 20:06 work our way back from there, we can see 20:07 software is defined at the top and then 20:10 it's actually defined from this query 20:11 get software providers. Um, as you may 20:14 know in RETL, a kind of real trademark 20:16 retool thing. Double curly braces allows 20:18 you to access any of these components 20:20 queries um state within RET um and and 20:23 kind of yeah access and then use that 20:25 data. Um, and so we can see here again 20:27 hovering over it, it's coming from this 20:30 get software providers query. Um and so 20:33 if we were to hover over the select icon 20:35 at the top, we can then open up the uh 20:37 culprit here. So that's one method which 20:40 is using uh basically the inbuilt um 20:44 function to hover over a v variable and 20:46 view the state instantly. Um it's really 20:48 powerful, really easy way to quickly 20:50 understand what's going on within a 20:52 within a transformer. 20:54 But the other method that I wanted to 20:55 also talk through is um how you can use 20:58 state and understand understand state to 21:00 debug more complex issues. Um so if I 21:04 now go back to opening the transformer 21:07 and I now open up the state tab um I'm 21:10 going to give a little uh little 21:12 overview story time of why state is 21:15 important and how you can use it to 21:16 debug within retool. So for more complex 21:20 issues typically where maybe unlike here 21:24 where we've got a clear error where 21:25 maybe data isn't showing where you think 21:27 it should be or a component is not 21:30 getting the correct column or or 21:31 whatever it can be a lot harder to 21:33 actually understand particularly more 21:35 complex applications where the data is 21:37 coming from and what links into what. Um 21:40 and so this state tab is a great place 21:42 to be and so why is it important and and 21:44 and kind of why is it a concept that we 21:46 need to understand? Um, and so to give a 21:48 brief overview, essentially front-end 21:50 frameworks like React or Angular, maybe 21:52 you've heard them heard of them or 21:54 worked with them before. Um, 21:55 essentially, 21:57 you know, why do they use state and why 21:58 is dependency so important? And it's 22:00 because if we didn't track states and 22:02 the dependencies between them, um then 22:05 essentially anytime a piece of software 22:07 updated in your in your app, you clicked 22:09 button um or sent a request or whatever 22:13 it may be, we would need to rerender the 22:15 whole page in order to ensure you know 22:17 all the all the right bits of 22:18 information updated in in your um user 22:21 interface. Um and so that unsurprisingly 22:23 that's deeply inefficient. Um and so 22:25 like those frameworks here, that's 22:27 exactly what we're doing in retool. 22:28 We're analyzing you know for each uh 22:30 piece of state you know what is it 22:32 dependent on and if you see here at the 22:34 bottom uh if we search for all requests 22:39 with software name so if we're searching 22:41 for this transformer we can actually see 22:43 you know what it's updating and what it 22:45 depends on that's really powerful and 22:47 really useful um I imagine if you have 22:49 ever played around with any of these 22:51 front-end frameworks like React um there 22:53 will be a time where dependency loops 22:55 happen um or um 22:59 um or yeah you haven't quite configured 23:01 state correctly um using ustate and it 23:03 causes all sorts of issues whereas here 23:04 we have a visual representation to 23:06 actually understand okay so you know 23:07 what is it updating and what what does 23:09 it depend on and then this is then 23:11 really powerful to then move up and down 23:13 that chain to be able to find the root 23:14 cause of different bugs. So if we were 23:17 to go down the chain in this example, so 23:19 clicking through on the component, the 23:21 table that should be displaying this 23:22 data, unsurprisingly, it's not showing 23:24 any data because it's relying on this 23:26 transformer. So if we go back up the 23:28 chain, we can see the transformer here 23:30 and it's null. Unsurprisingly, we just 23:33 discussed that, you know, has currently 23:35 has an issue returning any any data. So 23:37 nothing here. But now if we go back up 23:39 the chain, just like we figured out 23:40 before, we can see get all requests 23:42 query. And unsurprisingly, we do have a 23:44 request here. This is the one that is 23:45 working. Uh again, if we go back back, 23:48 we can now go check get stuff with 23:50 providers. I know we've already figured 23:51 this one out, but unsurprisingly, yes, 23:53 this is showing as having the error. 23:56 So, I'm going to give a little um pause 23:58 there. So, just give a recap. So far, 24:00 we've discussed how to understand um app 24:02 context with assist um and the debugging 24:05 tools. And then we've discussed two of 24:07 the main methods to um find the root 24:09 cause of issues. um one by 24:12 uh using the kind of inbuilt ability to 24:15 hover over variables um within retool to 24:18 understand its state but also the 24:20 concept of the state tab in and retool 24:22 and the ability to move up and down the 24:24 dependency chain. 24:27 So with that said we want to now open 24:29 get software providers uh as we have um 24:31 quite extensively covered that this is 24:33 most likely the root cause of the issue 24:35 and we're now going to get into resource 24:37 query debugging. So with any um uh kind 24:41 of query in the code editor um you can 24:43 both either test or run the query. Uh 24:46 main difference being test you're just 24:47 running it within the context of this 24:49 output you know output pane within this 24:51 query whereas run you're running it in 24:53 the context of the app. So you're 24:54 updating this the state um in the 24:56 context of of the application. Um so for 24:58 now we're just going to run test um to 25:00 not change anything and we can get a 25:02 clearer breakdown of the error here. 25:04 Invalid credentials error unable to 25:06 authenticate. double check your API key 25:08 and try again. Now, this is a classic um 25:11 authentication error. Again, probably 25:13 one of the most common um kind of 25:16 resource errors you're going to come 25:17 across. So, we're going to walk through, 25:20 you know, what are the main scenarios 25:21 here and how how can you go about 25:22 debugging this. So, typically with 25:24 authentication errors, there's um only a 25:27 limited number of options that could be 25:28 causing this. So either we aren't 25:30 sending the API key, we're sending it, 25:32 but it has the wrong credentials, or 25:34 we're sending it in the wrong format for 25:35 this server uh to be able to um uh 25:39 interpret it. So let's work our way 25:41 through kind of understanding what which 25:43 of those three is it likely to be before 25:44 we go into depth of actually researching 25:47 um uh the solution in more detail. So in 25:51 the output pane, we can uh switch across 25:54 to API request. And this gives us a nice 25:56 little breakdown of both what we're 25:58 sending. So the request so what what 26:00 we're sending to the resource uh and the 26:02 response of what are we what are we 26:03 getting back? And if I go to the request 26:06 property here um I can view okay we are 26:09 sending an API key. Um and it's nicely 26:11 sanitized by retool. Um so we do seem to 26:14 be sending something here. So next I'm 26:16 now going to check okay you know it does 26:18 seem to be the correct API key. Uh and 26:20 like I was showing before the ability to 26:22 hover over variables. We can hover over 26:24 this one and we can view. Okay. Yeah, we 26:26 are sending an API key here. Just as a 26:29 disclaimer, it's generally not best 26:31 practice to store an API key um kind of 26:34 in the header within the resource query 26:36 in an app. It's better unsurprisingly to 26:38 have it within the resource itself, but 26:40 for demonstration purposes here um I've 26:42 I've set this up um kind of within the 26:45 query. So, we've ticked off those first 26:47 two. So, chances are it's actually 26:48 something in how we have configured the 26:50 header. So we're going to go about um 26:52 asking assist to see whether it can help 26:54 us with this. So with opening up the 26:57 assist panel on the side uh we have the 27:00 ability to reference things within 27:02 within the app. So if I uh type at I can 27:07 then search for get software 27:10 uh providers. So I am selecting this 27:14 specific query and let's ask and see if 27:16 assist can help me. 27:19 How should I be setting up the resource 27:24 uh API key here? 27:28 So great class great place to start is 27:31 um asking assist or AI in general you 27:34 know how should I be configuring these 27:36 resources um how do they work you know 27:38 you know I'm getting this error back 27:40 typically you know what does it mean and 27:42 while assist is working on a little 27:44 response there and it seems to actually 27:45 have 27:47 given it um and we'll see if it 27:57 So it seems to be struggling here to get 28:00 understand what's going on. So it's 28:01 saying how to set up the API key. You 28:02 have two options. Create and configure. 28:08 So I don't think it's quite getting to 28:10 the root cause here. So the other option 28:12 is if AI maybe isn't quite giving you 28:14 the solution. Um the other option is 28:16 actually to go the old school way which 28:18 is going finding some documentation. So 28:19 let's search for Postman mock server um 28:23 API key and let's try and research. 28:26 Okay, how should things be configured 28:27 here? Uh I'm not going to read through 28:29 the docs with you um on this call but 28:31 let's have a quick uh run through and we 28:34 can see when creating a mock server from 28:36 an API call and if we give a quick skim 28:39 down here we can see okay to the request 28:42 X API key header. So actually it seems 28:44 to be we we're probably sending the 28:46 header in the wrong format. So if we go 28:48 back. Yeah, we're sending API key, not X 28:51 API key. Let's change it to X API key. 28:55 Hopefully give that a test. Amazing. 28:58 That's now returning a list of software. 29:00 So let's now click save and run. 29:03 Wonderful. That is working and sending 29:05 the right request. One. Amazing. 29:08 So to give a brief recap, we've 29:10 understood the app context. we have gone 29:12 into root cause analysis and then we 29:14 have looked at using both assist and 29:16 also manually looking at the 29:18 documentation to try and understand um 29:21 how a resource should be configured and 29:23 we've changed the resource header here 29:24 to X API key uh which is the header that 29:28 this postman server is looking for and 29:30 so now we're getting the appropriate 29:31 list of software providers I assume here 29:34 that um for this demo for this MVP that 29:36 Jerry's made um we're just currently 29:38 using example list of of software 29:44 Nice. 29:47 I'm going to take a quick pause there, 29:48 have a have a little drink, 29:51 and then let's go on to the next 29:54 section. 29:57 So, now we've made this change, we've 30:00 made this fix, let's see if there's more 30:01 errors for us to um get stuck into. So, 30:05 you can either reset the app state from 30:07 the top right here. You can click on the 30:09 ellipses 30:11 uh on you know at the top right of the 30:13 editor and click reset app state. Um or 30:15 you can just refresh the page and this 30:17 will just reset the state to see okay um 30:20 let's let's see if there we're still 30:21 getting any issues. Uh and just like we 30:23 did before let's go straight to the 30:25 debug tools to see if we have any 30:26 problems. 30:28 And looks like we're still got some 30:30 errors that are going on here. So just 30:32 like we did before let's start with 30:33 these and work our way backwards of of 30:36 what could be causing this. Um so again 30:38 like I did before you can open up 30:41 uh this specific uh route of this bug um 30:45 by clicking onto the um item here and 30:48 that will then open the transformer and 30:49 it seems to be the same transformer we 30:51 were looking at before. So the one that 30:52 was taking the requests getting the 30:54 software um and adding the software name 30:57 to the to the requests. And now let's 31:00 get into the wonderful world of 31:01 debugging in JavaScript. 31:04 So 31:07 it's a lifelong journey understanding 31:09 JavaScript errors and getting better at 31:11 debugging with it. Um I wanted to 31:13 highlight one of the main tools that u 31:17 that you would use to debug in 31:18 JavaScript um and then kind of talk 31:20 through um kind of some more areas from 31:23 that. So like we did before let's do a 31:26 slow work through of looking at the 31:28 error in more detail. So error cannot 31:30 read properties of undefined reading to 31:33 uppercase 31:35 and like we did before let's open up 31:37 this error and we can view which line 31:40 it's happening on. So this is line 8. 31:43 Let's go to line 8 in the transformer 31:46 and we can see um again here that two 31:49 uppercase issue. Um so similar to that 31:52 find.software issue the same thing here 31:54 means we're trying to read to uppercase 31:57 on full name. Um but 32:00 full name probably most likely is 32:02 undefined or doesn't exist here. Um so 32:04 let's now try and work our way back from 32:06 there. So looking at the code here, we 32:07 can see that there's a match um made on 32:10 software. Um so chances are here it's an 32:13 issue with um whether full name exists 32:16 as a property on software. So what we're 32:19 going to use here is something called um 32:21 console logs. Um, so effectively, 32:24 unsurprisingly, they're ways to be able 32:26 to print information into the console 32:28 that you have on the side here in your 32:30 debug tools. Uh, and they're one of the 32:32 main ways to understand um the 32:35 information that's what's going on 32:36 within um your logic. So you can do that 32:39 by typing console.log 32:42 and then you just type the specific 32:44 variable that you're looking to print. 32:45 And typically I always like to also 32:47 include a string, you know, a comma and 32:49 then a string to then also print, you 32:52 know, what am I actually showing here. 32:53 It can sometimes be hard if you have 32:55 lots of console logs to understand 32:57 what's printing what. I'm going to do 32:59 this for software and also while I'm 33:00 here, it can also just be useful to get 33:02 as much information as we can. So I'm 33:04 going to also do requests so we can see 33:07 both of them. And then we have the 33:09 ability to run a test. And then as you 33:13 can see here, it should then print out 33:15 in your console the information. You'll 33:17 need to make sure that you have both the 33:19 errors, well importantly the info 33:21 messages enabled. So you can view 33:23 console logs. And you can see every time 33:25 this piece of code runs, it's going to 33:27 keep printing out this information for 33:29 me. And then I can use this to 33:32 understand, okay, let's first look at 33:34 requests. And I can see requests is 33:36 coming through and nothing unusual 33:38 there. But if I open up software and 33:41 let's say we see we've got an array of 33:43 objects here. Um and if I open up the 33:45 object I can see the structure of the 33:47 software and we seem to have an ID a 33:49 name and a notes. So actually having a 33:51 look here we are defining the name um as 33:55 a property um rather than full name 33:57 here. So actually I think this should be 33:59 name rather than full name. So, I'm 34:02 going to change that. And like we did 34:03 before, I'm going to run a test. Ah, we 34:05 now have a software request with the 34:07 software name here. Amazing. And if I 34:10 run save, let's double check that. 34:11 Perfect. So, that's now saved and 34:12 working. We've got an access request 34:14 with a software name. So, that's working 34:17 as expected. 34:20 So, you may be thinking, that's great, 34:21 Ollie. I've used console logs, but that 34:23 was quite a lot of effort. And you just 34:25 showed me earlier around how you can 34:27 hover over um any variable in retool and 34:30 understand straight away what's going 34:31 on. So I could have just gone there. 34:33 Let's have a look at what the match is 34:34 made up of. We've got ID, name, and 34:36 notes. Okay, come on. That's name 34:38 straight away. Very quick fix. Um why 34:41 have you showed us console log here? Um 34:43 and I think the the main reason is um 34:45 for more complex applications um and 34:48 more complex pieces of code um 34:50 console.logs logs is always the fallback 34:52 to go to to understand the makeup of 34:54 what's going on here. Um, typically when 34:56 you find 34:58 uh AI can is incredibly efficient at 35:00 writing good bits of code. So if I was 35:02 to give this to um an AI and say write 35:06 me a more efficient solution, it 35:07 probably will come up with a better way 35:09 of writing this this piece of code. But 35:10 will it always have the appropriate 35:12 context of the data structured and how 35:14 it's being passed around etc etc? No. 35:17 And so um console.logs logs is a really 35:20 um good solution or or or way something 35:23 to have in your toolbox to fall back on 35:25 um to kind of really understand what's 35:26 going on in the code here. But then 35:29 following that you may say okay that's 35:30 great Ollie um I can you know use 35:32 console logs but what about if the AI 35:34 does understand context you know 35:36 unsurprisingly here we could um go to 35:38 assist and just like we did with the 35:40 resource we could probably at this 35:43 specific transformer like we did with 35:44 the resource and say fix this piece of 35:46 code for me and it will most likely give 35:49 a good effort at providing a solution. 35:51 Um and I think again we run into that 35:53 same issue that potentially for for 35:54 simpler issues um that would work but 35:57 soon as you get to a point where there's 35:59 you know it's more specific context that 36:01 that you you haven't passed on or takes 36:03 sort of effort to pass on um suddenly 36:05 you can be uh lost at sea with what's 36:08 going on in your code. Um and so having 36:09 the idea of being able to use 36:11 console.logs um is a great place um and 36:13 a great skill to have. 36:16 So, let's just for aesthetic reasons get 36:19 rid of those console logs. Now, we know 36:20 it's working. So, I'm going to delete 36:22 those and save that again. So, that will 36:23 then stop printing out on the console. 36:26 Uh, and just like we did before, let's 36:28 um refresh the page um to double check 36:31 whether if there are any more issues. 36:33 And we now seem to have no more problems 36:35 in the console. So, maybe we're we're 36:37 nearly there. Just to give a brief pause 36:39 um and recap, we have now discussed app 36:42 context, debugging um finding the root 36:45 cause of issues, debugging resource 36:47 queries, and also debugging JavaScript. 36:51 Uh we're going to now finally get into 36:53 the last section, 36:57 which is let's see if we can actually 36:59 submit an access request. So, I'm going 37:02 to click request. I'm going to click 37:04 through on a piece of software. So I'm 37:07 going to select one randomly. I want to 37:09 be an admin test and I'm going to write 37:12 just a test justification. Let's see if 37:14 we can submit this workflow. 37:20 Okay, unfortunately we're still getting 37:23 a problem here. It does seem to be 37:25 creating the access request, but the 37:26 workflow that seems to be triggered um 37:28 to send an approval doesn't seem to be 37:30 working. So just like we did before, 37:32 let's start with the debug tools. Let's 37:34 start going to the error. Let's start by 37:36 clicking onto the um the resource query 37:39 that's triggering this. And like we did 37:41 before, let's run a test to double check 37:43 what the error is. Okay. Yeah, we're 37:45 getting that problem through. Um so with 37:48 this scenario here, um it's only I have 37:51 access to the workflow. We're not going 37:52 to run through the same process of 37:53 duplicating um um dup duplicating the 37:57 JSON and etc, etc. So you can just watch 37:59 along if you have been following up 38:00 until now. 38:02 Uh, and so reading through this error, 38:04 we've got this error true message, no 38:06 recipients defined. We also get the 38:08 workflow run ID. So clearly there's 38:11 something wrong potentially with how 38:12 we've set up this workflow. So we can 38:14 open this workflow from this app and get 38:16 started into debugging workflows. 38:20 So just like we did before, we're going 38:21 to take a moment to understand what's 38:23 going on here. We have a start trigger 38:26 that seems to take in a request ID and 38:29 an email. We then get that the details 38:32 of of that specific request. We then if 38:34 we do get the uh details of the request, 38:37 we then are looking to send an email to 38:39 notify the admin to say you've got an 38:41 approval that you need to make. 38:43 Um and so that seems to be kind of what 38:46 we're trying to achieve here. So just 38:47 like with the app with the debugging 38:49 tools there, we have the run history or 38:50 run logs. Um where we should then be 38:53 able to go into more detail around what 38:55 caused the problem here. Um, 38:57 and what we can do is we can filter the 38:59 runs. Um, and I just want to try and 39:02 find the specific run that I'm looking 39:04 at here. Um, and by clicking onto that 39:08 one I want to investigate, we'll get a 39:10 full history of the uh, what happened. 39:13 Um, so the global all the blocks. So the 39:15 blocks are the individual bits of um, 39:17 code here. Um, so the start trigger, the 39:19 get requests, um, the even the branch 39:21 etc. And you'll see here we get a full 39:24 breakdown of what was triggered, whether 39:25 it was successful, etc., etc. And 39:28 actually, we can see the email admin 39:31 block is the one that's highlighted in 39:33 red. So, this is the issue. And if we go 39:34 to data or JSON, we can see a clearer 39:36 breakdown of this problem. So, error 39:38 true, no recipients defined. If we go to 39:41 the block, we can see here, chances are 39:43 we're not appropriately configuring the 39:46 um email to send the email to send this 39:50 uh to. So a really really useful tool 39:52 within workflows is to go to um inputs 39:55 and within here you'll see basically all 39:56 the information that this block takes in 39:59 um and in opening that you get lots of 40:01 insight into what you're trying to use 40:03 to um get that data and then what it 40:06 evaluated as. Um so we can see here for 40:09 this um who we're sending the email to. 40:11 We've got start trigger.data email. So 40:13 we're pulling from the start trigger and 40:15 we're just getting my full name but not 40:17 my email uh which isn't great. And if we 40:20 double check that so we can see what's 40:22 happening here with the body. We can see 40:23 we've got the raw expression with the 40:25 get request details data um and my name 40:28 um but 40:30 so that seems to be kind of working as 40:31 expected. So let's double check where 40:34 we're pulling this from which is the 40:35 start trigger. So we can click onto the 40:36 start trigger and again for this 40:38 specific workflow run we can view what 40:40 did this start trigger output? What was 40:41 it d what was its data? Um and viewing 40:44 this here we can see next to email again 40:46 we're just sent seem to have sent my 40:48 name in this um trigger uh rather than 40:51 my email. So actually it looks like the 40:53 error lies with the app um not with the 40:57 workflow. So, if we go back to the app, 41:00 um, we can now have a look at this in 41:02 more detail. And we can see here it 41:04 seems to be that we're sending my full 41:06 name. And just like we were doing 41:07 before, you can hover over to see the 41:09 current state. And we can see, yeah, I'm 41:11 sending Ollie Clyde there as my full 41:12 name, not email. But I do have access to 41:14 send my email here. So, let's change 41:16 that. 41:18 Um, and let's run the test again. 41:22 True. Amazing. So, that's now working. 41:24 And hopefully if you have followed along 41:26 um you should have been able to add your 41:28 email to current user and should have 41:30 received an email. Um so just like we 41:33 did before let's refresh and and finally 41:35 let's see if Jerry has made any more 41:37 problems. Um so I can see here I've now 41:40 got my pending request at the bot. Let's 41:43 try and approve that. So if I click on 41:45 to that pending request um I can now 41:50 determine whether to reject it or 41:52 approve it. Let's give myself access. 41:54 Let's approve it. Brilliant. Amazing. 41:56 And let's now turn to approved. So, it 41:57 looks like everything's working um as 42:00 expected. 42:02 Amazing. Thanks so much for following 42:04 along. Um I hope you found that 42:07 uh kind of useful and covered some areas 42:10 that either you haven't seen before um 42:12 or some new tips or tricks that you can 42:15 now use when working um in retail 42:17 yourself. Uh to give a little recap of 42:19 some of the main points I I wanted to 42:21 get across. Um, one, the importance of 42:25 starting broad um, and then going deep. 42:28 Um, effectively using things like assist 42:31 to understand the bigger picture of how 42:33 the app works and then going from the 42:35 debugging tools to the error um, to then 42:37 kind of work your way back to um, the 42:39 specific issues or like we found with 42:40 the resource query, what are the the 42:42 most likely um, uh, issues here and then 42:46 work our way picking them off before 42:48 going into the deep depth of reading 42:50 documentation. um the importance of 42:52 testing incrementally. Everything we 42:54 went through today would make one change 42:55 and then test. Um and so uh not trying 42:58 to fix everything at once, but iterating 43:00 is is really useful and important when 43:03 debugging, understanding dependencies, 43:05 checking dependencies, using the state 43:07 tab, understanding state, I think is a 43:09 really important part of debugging. Um 43:11 and so something to be familiar with. Um 43:14 and finally, the importance of reading 43:16 the documentation. Uh, I don't know if I 43:18 mentioned this already, but when I was 43:20 first started to um um get into software 43:22 development, biggest piece of advice I'd 43:24 got was always read the docs. Um, 43:26 obviously that's changing now with how 43:27 good AI is at um summarizing things for 43:30 you. Um, but 43:32 um effectively the amount of times I've 43:34 gone to set up a resource, skim the 43:35 docs, think I thought I understood 43:37 what's going on and then ended up um 43:38 having a really common error that I 43:40 could have avoided um uh earlier on. 43:44 Lovely. So, thanks so much for following 43:46 along and listening. Um, looking at the 43:49 time, we do have some some um uh some 43:53 extra bit at the end to talk through any 43:55 questions um that you may have. Um, I 43:57 don't know if there any in particular 43:58 that cropped up that we can get into um 44:00 straight away. 44:11 I think Mike had one question about uh 44:13 the header um in the resource 44:17 configuration. So maybe you could show 44:18 that on the screen. 44:22 >> Yes. Um so if I go back to that resource 44:26 query in the header that I have set up 44:28 here. Um 44:31 let me see if I can get the specifics of 44:33 the question. 44:51 Um, so yeah. Yeah. Any questions around 44:53 the header? The solution was to add in 44:55 the X API key. Um, which 44:59 >> yeah, 45:01 >> if you could show the uh if you edit the 45:03 resource configuration, how you can 45:04 place it there as well. uh so where it 45:06 should be for best 45:07 >> practice. Yeah. Yeah. So um so for best 45:10 practice um by editing the resource it 45:13 just means that anytime this resource is 45:15 used without within um any app um it 45:18 will then by default have that API key. 45:20 And so we could do the same here XP API 45:22 key here and then set it um just like we 45:26 did before. The only difference being 45:27 actually it's defined as an environment 45:29 variable here. 45:31 Um so we can see that postman API key 45:33 rather than within the app itself which 45:35 is stored in the retool context. Um so 45:39 um just explain that in detail there's a 45:40 slight um difference there set as an 45:42 environment variable um rather than a 45:44 within the retool context. Um so 45:46 effectively what this means is you as an 45:48 admin can set it up of here are the 45:49 details of how you can connect to this 45:50 resource and then you know you can then 45:53 um they can use that without knowing the 45:54 API key or it being exposed on the 45:57 within the app itself. um but they can 45:59 then still access the data or maybe 46:00 create even create their own requests um 46:02 to this endpoint. 46:06 >> Uh we had one question from uh Ollie 46:08 which is how do you know which queries 46:10 run on page load? 46:13 >> Great question. Um 46:16 so 46:17 on timeline here the the um so that was 46:21 in in the debugging tools um the 46:23 timeline tab. 46:25 Um, effectively if you refresh the page 46:31 um, and go to the timeline tab, this 46:32 will show you basically all of the ones 46:34 that that run kind of on page load. Um, 46:37 and typically it's also ones, you know, 46:39 most likely. Um, if you go to any 46:42 resource query here, 46:44 um, you should be able to view if we 46:46 were to say get request query, um, you 46:51 can look at the run behavior as well. 46:53 and you'll you'll be able to see okay 46:54 this run behavior is that it's going to 46:56 um kind of run on page load and so it's 46:58 automatic rather than something that's 47:00 done manually. So you're manually 47:01 tricking triggering it you know through 47:02 an event handler um whether you know 47:04 whether within a button or whatever it 47:06 may be. Um but yeah technically speaking 47:08 these are all on that refresh on that 47:10 page load. Um and yeah out of curiosity 47:13 as well you can sort of see some 47:14 information around um the timeline of 47:18 that load. Um, and so, um, yeah, as I 47:20 mentioned, you can use this to go into 47:22 more detail around, um, what could be 47:24 causing, um, uh, 47:28 performance issues within your 47:29 application. 47:42 Nice. Um, within the instructions, I've 47:44 also included some, um, useful 47:46 resources. Um effectively they're just a 47:48 rundown of you know the debugging tools 47:50 in the app. Um the run history setup and 47:52 workflows as well as kind of common 47:54 resource connection um errors that we 47:56 see. Um so they're very useful to um 47:59 have a read yourself uh and kind of use 48:02 when debugging and retool. 48:09 >> I think that's it for questions. 48:11 >> Nice. Um brilliant. 48:17 So to finish for the next event that 48:20 we're that we're running um we have a uh 48:23 we're running a retail summit uh in the 48:25 shard um March 26th um don't know m if 48:28 there are any more specifics on this but 48:30 if you if anyone wants to scan the QR 48:32 code um they can get some more details 48:34 around how they can register um find out 48:37 what's going on 48:41 and it would be brilliant to see you 48:43 Yeah. 48:59 Can see a question on 49:22 Okay, brilliant. Well, to wrap up there, 49:24 um, thanks so much for joining. Um, and 49:26 yeah, hopefully see you at Retall 49:28 Summit. Thank you so much.
