 Did it say start recording? Yes, please. That would be super. And once I start my presentation, I'll need the feedback whether it's going right or not. Yes. I don't know if you're going to see the presentation. Can I see mountains at the moment? Yes, that did not go as expected. Yes, I can see your introductory slide now. Yes, that is perfect. Thank you. All right. Hi, everyone. I am Yulia, and I'm a developer advocate for Vonage, where I focus on low-code tools and technologies, different approaches to enable our audiences to use our APIs and products. So today, I wanted to introduce you to low-code using the tool that first introduced myself to low-code, and that is Node-RED. First, let's see what the low-code-no-code thing is about and how it all started. There's a lot of terms going on, as you could hear earlier in the beginning conversation. To clear things up, I tend to say no-code for every software tool platform where the user does not interact with code, and anywhere where it gets to a more technical angle, like you're using curly brackets, maybe mustache templating, or even writing code, mostly JavaScript into it, that is low-code, in my view. So what's the current state of low-code? Funny thing, I first started researching and looking into low-code solutions about two years ago, and then I did a couple of Google searches, looking through all the terms low-code, low-code, flow-based programming, visual programming, everything I could think of around this topic. And honestly, not a lot of things came up in the Google search. I repeated that last year and the last year, and only for low-code. I had four million results, and again, I did that this morning. This is a screenshot from this morning, and that is 3.7 billion results on the term low-code. So it's definitely gaining traction. I believe under the current climate, a lot of businesses had to go online, and low-code, or no-code, was really a lifesaver for many of them, because they did not have the resources for development team, but taking their services online with just a little bit of help from a low-code tool was a good solution. I also came across this image from Mario Noyoso. He tried to collect all the low-code tools he could find, and that's a lot of them. When I first looked at it, I realized at least 80% of those are something that I haven't interacted with. But if you have a closer look, I'm sure you will find names that you wouldn't have thought are low-code or do-low-code, but you might have seen before. So how did we end up here? It all started a while back. So different visual or flow-based approaches started coming in from the 1960s, and they looked a lot like this. Different directions, different approaches. Some of them were more of a hardware-oriented thing. Other approaches were to teach kids how to learn about code, and some ended up like this. So this is the case where we are applying an abstraction, a visual abstraction, to the code, in the idea to make it more easily comprehensible, easier to interact with it, and enabling people who might find code a little hard to grasp or time-consuming to get their tasks done in a better, faster, easier way. Now, when you take away the complexity of code, but add in the visual complexity, I don't think that is that useful at the end of the day. And in my opinion, this might have been one of the reasons why visual coding hasn't really gained that much of attraction, even though there have been quite a lot of attempts in the past. A couple more images from the past. This is actually a really cool one if you want to teach your kids how to start writing code. I believe it's scratch. Yes. So from those, we've come a long way. And nowadays, no-code platforms look a lot more like this. So this is up here. IFTTT. Both of these on the no-code and the spectrum really clear, intuitive, user-friendly. A little more limited, but for basic tasks like generating an invoice, sending a notification, if you are a small business that is not an API company but needs some solutions around business operations, then these two tools are really great. And so is the next one, which is Airtable. This is taking a spreadsheet and making it smart. So I think Airtable did a really good job in here. They took, honestly, what was Google Sheets and built so much on top of it that it's a whole local platform at this moment. And then we have NodeDread as we're going down the complexity line. Still pretty clear visually. It gets a little more complex, not as intuitive or user-friendly as the previous ones, also not as limited. And I would even say that Postman could be a low-code thing. So it's not that visual, it's no longer drag and drop and connecting together with wires. And yes, I personally might write 50 lines of free request scripts and 100 lines in test. Honestly, the test is shorter always. That might just be me. But the end user then comes into the collection, fills in environment variables and presses send. So from their end, there wasn't really interaction with code. And I do believe that low-code is for everyone in the sense that there is a tool out there for everyone, not that low-code in general is a good fit for everyone. So the way code is good for every developer, I'm not saying JavaScript is for everyone. And you can pick and choose your tools to find the right one for you. And yes, developers are people too. So if there is a tool out there for everyone, that means there is something for us as well. And I'll stop rambling right now. So let's get into NodeDread and let me show you how I got into low-code and how this tool helped me do that. So hopefully you're seeing NodeDread right now. NodeDread.org, this is their website. It is an open source low-code tool or platform low-code programming for event-driven applications. I always like to come to their website and check out what they're calling themselves. It's usually a good starting point. So if you go to the documentation and find the Getting Started section, you can see that there's a lot of ways in which you could run NodeDread. Today, we are going to run it locally. And all I need to do for that to happen is to install it using MPM, which I have already done. And then come into my terminal and type NodeDread. So NodeDread is a NodeJS application. It has a runtime and an editor. And when I run it, it will give me a URL that's port 1880. And if I open this in a browser, that is where my editor can be found. So this is how the NodeDread editor looks like when you first open it up. I already have it something in here, but you would normally only have one flow. This main area, this white blank space, is your workspace. This is where you're going to build your workflows. The tabs, these would be your applications. They are also called flows. So that's flow two that we are currently on and we'll be building. I also have another one next to it, flow one. This is a different application. I have it disabled. So this will not be the rest for now. On the left-hand side, you have your Node palette. So nodes are these building blocks, if you will. Well, there are black box processes more. And you will drag and drop these into your workspace and connect them together with a wire to define how the data interacts in between them. The data that goes in between them is always a JSON file and we'll see how that goes. NodeDread also is an event-driven environment. So you build your applications and then you need some things to set it off. So in testing environments, I like to use the inject button. It is a node with a button once I save this flow. That button becomes clickable. So when I click it, it will start my application. In a real-world scenario, this might be an incoming web hook or something else happening in my workflow. And it will start off my application with a certain value and that is by default the timestamp. So it will send the value of message that payload being the timestamp down towards the other node. So why message? In NodeDread, there are three contexts we talk about. There is the message object that is the data in between everything that is connected together with a wire. There is a flow object, flow context that is everything on the same tab and there is global which goes across flows across tabs. So the main information that is going from the first node to the second one is the message object. We are attaching to it message that payload will always be in there and that is the main information that's going down. And we are setting that value to start our application with. Let's change it from timestamp to let's do a hello world. Never gets old. So I can, this always happens to me, command tab, control tab, toggles the sidebar and you also use it when looking for emojis. Message.topic comes from the MQTT background of NodeDread. I don't tend to use it so we can just leave it blank. And we click done. That is to save. In NodeDread, there's a rule of thumb. If a button is read, you press it. That's how you save. That's how you deploy. So that is going to start off my flow with the text hello world. Next, I have a debug node. So this will output the value of the message that payload into the debug area which is, I think, console would be the equivalent. So I can hit now deploy. I confirm deploy. And if I open up the debug area and press the button, it will output the value of the message that payload. I could have also chosen to output the complete message object which then shows us the structure of this object. So it has an ID and currently the payload property is attached to it. Topic is empty. These two come by default but you can also choose to attach different properties to the message object and they would appear in here. Right. So if you don't really know what these nodes are for, I have quite a default setup in here. So when you first install NodeDread, a lot of these nodes will come in. The common the function one's network. So what you would most commonly use. If you don't know what they do, one, you can hover over them. And there is this little book symbol that opens up your node help. So in the right hand side, you will find the mini documentation like section which will explain what that certain node does, how many inputs and outputs it has, what these would be, and how it would interact. The inject node actually has a history section. Most nodes don't, but so and so that would be interesting. So it explains the concept of fine stamp. Right. So if you install NodeDread and you find that something that you would like to build cannot be achieved with these nodes, there's a way to install more. And then you can come over to the manage pellets section. Under nodes, you can find everything that you already have installed. These are the packages, node modules, or install and start typing and everything related to that will come up. There's a different way of looking for this. And that is by coming back to Node.org and going to flows. So this is your Node.Library. There are more than 3,000 nodes and those are usually packages. There might be more nodes in the package. You can browse from here. Or you can have a look at flows. These are complete applications. Maybe someone has already built the solution that you're looking for. And collections might be a combination of the two or collection of nodes. You can also import or export these flows. So Node.Dread does come with GitHub integration, but if you would like to share a certain bit that you've built of full flow or maybe I just want to share this bit with someone, then I can select that and bring them out and export. Now most things in your editor are defined by JSON. So click the formatted version to see a little bit more about what is in here. There is an array of JSON objects that define the nodes that I have in there and the relationship in between them. And I can take this JSON file and take it across machines, load it back into Node.Dread and run it. Now this is a really simple example, but the important bit is that it's easily taken from one part to the other. And usually at the beginning I was getting questions around version control and sharing and collaborating that is solved either this way or a GitHub integration. So if you just look at what goes into one node, it has an ID type inject because that is the node we're looking at. We did not name it. You can come up with a custom name, the properties, and we didn't really set up anything special about it except payload, which is the text we provided and then a couple other details of where it is in the flow and the wire that is attached to it. Now if we look at the other node it will have the same wire attached to it. So this is the debug. It does not. I apologize. So the wires are the ones going out, the one coming in. And I could in a similar way import a flow. So if I paste the same JSON and click import and it picks up on the fact that it's a duplicate and I have options. Yes, I do want to import it and then I can place it into my workspace. Okay, so that was a really simple example, but let's see something a little bit more real world and where I'm getting with this. I'm going to show you something with our APIs because that's the package I've been working on. So I can show you the code and see how you build the node and how you would extend it. So we are one inch previously maximum. Our nodes are the instance is still maximum. So bear with me. When I pull the code up, one inch and maximum as words can be used interchangeably. And let's pick a simple use case like sending an SMS so that we can clearly see how that node is built. So I can add this node in between the inject and the debug. If it picks up on it, if not, then I can just connect it again and double click on it to edit the fields. So first credentials. This is a thing I like about Node Red that you can provide your credentials in here. Click on add and it saves it as a configuration node. So if you come over to the configuration nodes area, then it has saved as type next no basic all the combination of my API can password. Now, I was hoping to have my real key and password in there. I'll quickly go and grab them from my bunch account. That's what the mock answer for. So I'm editing this one. It's a normal one presenting. I would use this feature to not show the API can secret, but it will save it. And that's a good idea to it. So next time I would need to authenticate with the same kind of odd. I wouldn't need to provide the API can secret. I can just use the config node. Well, it will pick up automatically on the config node. And then I have a couple of fields. These are specific to sending an SMS. So I need a destination number. Sender. Well, I'm in the UK. You're possibly in Singapore. Both countries allow for alphanumeric sender ID. So if this was my company selling different products, and I would like to send an SMS notification to a customer, I could put my brand name in there so that they know it's coming from me. And text. So you notice this curly brackets next the two from and text fields. That means it supports mustache templating. So now I have the send SMS node after the inject node. That means I can dynamically pull in properties and values that are either before this node or off a global or flow level context. So I started off the flow with message.payload value of hello world. If I wanted to send it as a text in the SMS, I can use mustache templating to reference message.payload. And that would be the outcome. Since I have an emoji in there, I will check in the code. And done to save it and deploy it. It keeps complaining about an ngrok node because it recommends on the other flow. Actually, let me delay this flow. I didn't have authentication provided for that one. So every time I deploy it, it's complained. Okay. So back to the debug area. Now, if I press the button, it will send me an SMS. And in the debug area, I will get the response object. I'm not sure how good that on camera is, but I have an SMS in there. And in here, the response object, which is quite typical to our API. So this was the expected outcome of a successful request. Now let's see what goes into creating a node like this. I'll leave this open like that. So back to documentation. I find myself coming here quite often. And the creating nodes guide is actually a really good one. So you can just go to create your first node. And you will need a package JSON, a JavaScript and an HTML file to build one node. So you could use the same JavaScript and HTML file for more nodes, but one certain node needs to have one JS file and one HTML. Let's see how that goes. Actually, I have my file system opened up in here. Hopefully you can see enough of that. So I went into the folder where Node.js got installed. And if you go into node modules, and there you can find all the packages that you've installed and the default ones. So that would be node.contrib.nexmo in my case. And in there, under nodes, I will find combination of HTML and JavaScript files for every node that we have in our package. So for example, the SMS one, I have an SMS HTML and an SMS JavaScript. I also have the package that JSON, which lists everything that I have in there. And that is the bit that you would need to add in if you were creating the SMS node right now. So first, let's see the HTML file, because that defines how the node editor and the documentation looks like. So SMS rest HTML. First, I am defining these, which correspond to credentials to from next and Unico checkbox from the node editor. Then a couple other details like number of inputs and outputs, that's the icon label. And once I, yes, label is when it's already in your workspace. But that label is when it's still in the node. And then as I come down here, this is the form for collecting those values. So the first one is for credentials, then to from text, and the checkbox for Unico. And that's all for the node editor. And then here is how I would define the documentation that appears in the sidebar. So if I come back here and click on node help, this bit on the right hand side is what is defined here in the HTML file. And then onto the functionality, which comes from the JavaScript file. For us to understand this, let's compare with the Vonage code snippets that we offer as an SDK, and the template that NeonJet provides. And then we can see how we arrived to this bit of code. So try them to our developer platform and go to code snippets and find the one that is, yes, sending an SMS with Unicode. And yes, Node.js is already selected. To be fair, I have quite an easy job developing for Node.red as we already have the code snippets for Node.js. And since Node.red is built on Node.js, so there's not really a lot of things to adjust. And on the other hand, we are back to our creating your first node guide, which if you scroll down, it will give you examples of each of these three files. So this is their JavaScript file example. This is for a simple converting to lowercase function. So we take this, and on the other end, sending SMS with Vonage that we've looked at. And then we achieve this JavaScript file. So first of all, I'm getting the data. I am rendering through master's templating, because those three fields that we've looked at before, these three, since they support master's templating, something might come through that needs to be rendered. Then I'm instantiating the next mode, that is Vonage, API secret, that is my checkbox for Unicode. And then I am sending the SMS. At the end, I am loading the response back into message.sat payload and returning the message object. And this bit at the end is getting all additional data that usually appears in every situation in Neutron. So the custom bit is this. And at the end of the day, I'm not even sure if I would say it's another framework, but me adopting that thing or SDKs to Neutron is minimal work. And I think it does help the end user a lot. So I do like doing that. So coming back, yes. So at the core of it, Neutron is just JavaScript rubbed into a visual editor, really. It does not come with the limitations of the NoCode platforms. It really can do anything that Node can do. Does that mean that it has to be used instead of Node.js? No, not always, probably most often not. So let's see when to consider the NoCode. I quite like it for prototyping because I definitely drag and drop faster than I type. So it's also a nice thinking tool. Once you're familiar with the product, especially, our customer support really likes these to recreate different issues customers might have. I, for myself, when thinking about building a certain use case, a certain solution, I like playing around with Neutron. Because at the end of it, I have a minimum viable product that I can actually use and run and demo as opposed to a theoretical something or something mocked up. So I do have a little bit of advantage in there that I have something working as opposed to a theory of we'll build it in two weeks. I also quite enjoy using it for low value or low complexity things. Well, for things that are nice to have, for example, pulling in tweets that mention our theme into Slack so that we don't miss them, is this essential? No, is there a business value questionable? But it's nice to have using NoCode for it is literally one or two minutes. I'm not wasting my time. I can focus on my real value as a developer. And on the other hand, what I mentioned at the beginning for things like business operations, generating invoices, sending emails, notifications, putting data from a form into a spreadsheet, these would be the repetitive, low complexity things that are quite valuable once automated because it saves a lot of time. So I think that would be one of the contributors for why NoCode got so popular lately. Because those are the things that people are doing more and more these days. And another thing is maintainability. So it's both a pro and the con here. You wouldn't necessarily build your revenue generating product, especially if you're an API company with low code. So you could argue that it's not something maintainable. It's more of a hobby use case, which I won't agree against. But there are certain use cases where maybe it's a small team, it's a mom and pop shop. They need a little bit of automation or a little bit of help. Maybe you're the only developer on the team. And it's important to build something that outlasts you. Also, it's quite empathetic and handover friendly to build something that the rest of the team can interact with. For example, I had someone tell me that they built the whole business operations bit on Zapier, even though they were hired as a developer. Because after assessing the situation and what they had to deal with, they realized they were the only technical person on the team. So they could have written the code. Sorry, they were also contractors. So comes in, writes the code, leaves. There's no one to maintain the code. So here is the conclusion that the best solution would be to do low code, bordering no code. Because Zapier is on the more limited side of things. Even if it wasn't the best, most elegant solution for that certain case, that was the best solution. Because then they could go away and the team that they helped could maintain what they built as a solution. And you're aren't really a production developer 24-7. So from time to time, you might find yourself in one of these situations. Maybe you're working on a personal project and it's just a quicker way or you're teaching kids about code, about building applications, playing around with hardware or yeah, just building things with non-developers or finding the common denominator to build something together. Now, what low code probably is not for? Low code is not here to replace code, engineering themes. It's not a let's stop writing code, let's use this cool thing that does everything for us. No, it's not. It's not a way to save money on development resource. I mentioned at the beginning that during the pandemic, a lot of people benefited from low code solutions because they either didn't have development resource available or they couldn't afford it. Well, that doesn't mean that it's a long-term scalable solution in every use case. It might be a nice automation to send out an email notification, but it's definitely not something that long-term replaces engineering themes. Also, it's nearly always a platform. So you will have to weigh up the risks of that, building your product and type of a platform always comes with its risks. So there's on top of every programming language tool or platform. So that's something you need to be aware of and make a decision for yourself. Well, sorry. And at the end of it, I think it comes down to the efficiency of writing code. So low code isn't here to replace code or to replace developers. It is here to alleviate us. So it might come in handy for us to get certain things out of the way, to get quickly through something and then focus our efforts on what really matters on the high-value tasks that really do require our efforts. And at the end of the day, it's finding the right tool for the right problem and creating the right solution with it. And it is from time to time that might even be low code. I'll be wrapping up in a bit. So if you have questions, you might want to start typing those now. If you want to find out more about low code, I'm doing a stream on Twitch. I do realize that it's quite late for you. That's every Wednesday at 3 p.m. UK time. They are on YouTube, so you can catch up with them. And if you're interested in signing up for a Vonage account and seeing what we've built in NewDread or with any other technologies, you can do that and use a coupon code for 10 euros. Otherwise, I will leave the resources up for you. You can find more about NewDread, about low code hour and content tutorials, how to get started with NewDread. Thank you. Thanks very much, Julia. Does anybody have any questions? I have a question about composition. I was wondering if you created a flow that did something maybe something quite complex and then you wanted to reuse it. Could you put that flow, wrap that flow up into a node and then reuse that node in other places? Yes. So I believe those are called sub-flows. I will be honest. I haven't used those or NewDread in a while because I've been focusing on something else for the past couple of months. But there are sub-flows. Tend to lag behind in documentation. But there is definitely a way to build a flow and group it into what is called a sub-flow. So visually, it will appear as one building block, although you can open it up and then you have the full workflow that you've built. You can also define input and output for it. So the whole thing will behave like a node. Does that answer the question? Yes. I think that would be useful. Okay. Does it do type checking? You made a string and then you passed a string. What if you had accidentally passed a number or passed an object? Would Node-read catch that and say you're trying to put a number in where a string is expected? Does it do that sort of thing? It would take the number as a string. Okay. It would coerce it. Okay. And if I had a JavaScript application and I wanted to execute a flow that maybe somebody, one of the non-coders in my company had written, could I call their flow from my application? Would I have to do it by API or are there other ways to do that? So have someone use Node-read and you yourself not using Node-read? Yeah. I think I guess the idea is we've got a big team and some people are developers and then some people are making flows to do a part of the application and I want to execute their flows and get the result back in my JavaScript application. I would possibly go with web hooks. Okay. Okay. Yeah. So they, okay. We host it on an API and then call to the API. Okay. Make sense? Oh, yeah. Can you make Node-read output an image? Because I quite like graphics. I was wondering if you could make a flow and the end result is an image or even an animated image would be very interesting. So I didn't touch on this, but there is a whole package that I do not have installed for dashboard UI. So Node-read does have a visual side to it. People have been working on it. Something I didn't say, if it's Node-read dashboard, that means it's a default Node-read approved package. If it's Node-read contrib, everyone can contribute to it. So always make sure you click through and see what you're installing, but I do know this one. I'm not sure if I have to restart the whole thing or just the editor can there they are. So I'll quickly just put a couple of those in there without making much sense. You also have a template. So you can write HTML and I would put things in there and grab values from the backend might fail. But what I want to show you is that I can grab that URL. So that's the localhost 1880 and that's the UI after it. And welcome to the Node-read dashboard. Yes, it does ask me to add nodes that are properly configured. So you could make the whole front end for your flow in the flow and then somebody can access it just through that page. Yes. So I could send an SMS from your web page. Yes, you're good. I just realized I have blog post that has images in there. Let's see if I can type. We have a new learning platform. It's working progress. So it is a really simple UI, but I built this in Node-read using the dashboard buttons. It's providing a 2FA, well mocking a 2FA solution for the purpose of a tutorial. And if we want to see how that was built, is this the whole flow? Yes, that's the whole flow. So if I take that and import it, it doesn't make something. Back to the dashboard. Yes. I didn't see any new connections in that flow. That is because the functionality is not in there. So all I imported was the nodes that build. So what I would do in here, I would connect to these, the rest of the functionality. I believe I should have that as well. That's okay. I believe you. I have another question. People are using your APIs at the moment, or they're using your nodes. What are the most common things people use your things for? Usually notifications. So, well, the APIs themselves, that's for all type of communication-related things, phone calls, video calls, SMS messaging, source of 2FA. So how would they get the input into those to trigger those? How would they get the input in? How would they get the input of? So they want to use a node to trigger a notification. Where would the data come from usually? Usually webhooks. So setting up a webhook, it's an HTTP in, HTTP response. And I like to add the debug as well. And you set it up method and URL. And your zone. This, what you're doing here is quite, could be quite valuable to our business because we're making APIs all the time. And it might be nice if we could make a few without having to code. Maybe. Maybe people like to code. I think it's to each their own. But I do like it. And I found myself building things for a client that was already using Node-red. We haven't released something yet. And then until the release came out, I put together something in Node-red from different nodes so that they could use it. I went to some video as well. So it's really fast for trying out different things and really just for, I like it as a thinking tool. At the end of the day, you might go in and write the code. It's quite powerful. I like it. I had one other thought, which was when you, in next mode, you had to type the template message.payload. And it was a moustache template? Yes. Okay. And there was no completion on that, unfortunately. I was hoping that would be something you could drag and drop, say, I want the message to go into this field. But maybe when there's a template involved, it's a bit more complicated because you might have other. No completion as in, have it autocomplete or? Yeah. Just autocomplete or maybe just, because you had to type this in by hand, didn't you? And it might be nice for the non-developers if they could just sort of drag this in there or have it maybe offered to them. So you type message dot and then it, or maybe... I do think that would be valuable. A lot of other low-good tools that are a little more abstracted like Zapier do that. So you could either select from a drop-down list all the values that are available to you or when you start typing. But I haven't noticed that the new drug yet. And then I suppose when you're not using a moustache template, then it would just be the input and that would be done automatic, I guess. So that would be an easy way. But it's just because of the template here. It's a bit more... Oh yeah. So an easy way would have been to just write a text in here and that would have worked. I just wanted to showcase because this is not a common use case. We would have the text to be something that, well, a string provided. But what we would do is template the two and start of the flow with an array of numbers. And then it would send to each number the same message or maybe template the message. But if we want to template the message, that would require a couple of extra steps in between. What I've used it, I think for emails as well, nice to grab a couple of details and then use a template node and put together strings with holding values. Okay. Thank you very much, Junior, for your introduction to Node Red. Anybody else have questions? So there is something in the chat. Oh yeah. So team workflows. As far as I'm concerned, there is no way to log into a team workspace. So at one given time, there would be one person working at the link. You can use hosted versions and then have two people log in there, but that usually results in a mess. Yes, there is a project feature. So if you come to the folder where Node Red is installed, you will find a settings.js file. There's a lot of things commented out in here. It's worth having a read and seeing which features you want enabled and which not. I mostly use this instance for doing things from scratch. So I have most things disabled. And if you come right to the bottom, you might have it in there. You might not have it in there, but this is the bit you want to add. Excuse me. So editor team and projects setting enabled to true. And I save it. I think I should restart it. I might actually experience it. Okay. Yes. So now I have projects enabled. And that is a git repository. Just as you would use GitHub from your computer, it's not a collaboration at the same time collaborating on something. And I'm not sure which account I'm signing to. Yeah. I don't think I can do this for now because we have our git account secured. And that's a multi-step thing. Someone has asked, could you share your Twitch stream? Yes. Let me just quickly see. So that is the URL. But it's a team level thing. So a lot of my colleagues also do streams in there. You can go through the schedule and see what's going on. And we also have a YouTube channel. So for that, I'm going to quickly take this off screen. Oh, no. That is the YouTube channel where you can kind of get the feel for what we do. We have a question here from John. What is your experience with non-developers setting up Node Red? He found that non-developers could not wrap their head around the setup process. So how has that worked with the groups you've been working with? I tend to not recommend Node Red for complete non-technical audiences. I think there are better suited tools out there that someone would be better off starting with like Zapier. I found that Zapier is one that people wrap their minds around quite easily. And once you've interacted with a couple of them, then you get the understanding of what the variable is, templating, pulling certain values in, how APIs interact with each other, how data flows, how different steps come together. And once you have that understanding, then I would start with someone with Node Red. While it allows you to do so much more, I think you do need a certain level of technical knowledge for Node Red. It's not about knowing how to code. It's about the concepts of variables of an API of web hooks. So it's not as beginner friendly as other Node Code or Node Code tools might be. I have not seen an exhaustive list of concepts. Let me see what's in the editor. So I've seen that there are courses out there on Node Red. Honestly, I haven't taken or looked at any of them. But I would assume those might explain a couple of things. Also, what you would get in a beginner JavaScript course or programming 101, I would say those would be. And also, looking at the common nodes, the function, and understanding how these web hooks work. I don't have an answer right now. But if you send me a message on Twitter, maybe, or even Telegram, because I'm in the group and you can find me, then I'll try to come up with a more comprehensive answer to that question. But I haven't really thought to a list of you have to have these concepts before I just tend to go to the easier to use tool first. And if that gets the job done, then good, because it's faster, easier, and they feel better about themselves, as opposed to trying to drop someone in the deep end and scare them with this thing that is supposed to be low code, and it's supposed to be easy. But it's not as easy as expected. Actually, I've got people who were deterred by... When I first started doing Node Red, I had people get interested in, oh, that's low code. So maybe there's hope for me, I can try to code, but I would like to understand better the APIs that our company does. And then when they saw the things I was using Node Red for, they kind of got scared of it and never touched low code again. Even though in the meantime, we've discovered different tools that were friendlier and better suited for beginners. So I tend to see each individual case and for beginners, start them off with Zapier or... Zapier is a good compromise. Because it's limited, but not way too limited. There's a lot of things you can still achieve with it. And it's also... You log in and it connects this up with this one. So you select an app that you want to start building with. I don't know. Also, there are recommended workflows. So as you open it up, already have information on how to get started, where to get started and the concepts of... Oh, you have to connect applications. So you select look for one, maybe Gmail. Oh, look, there it is. And if I receive an email, maybe I want to save something from there into an air table base. Okay, so it's connected. Oh, what happens? So when I get a new attachment, then I want to create a record. For example, save that attachment into my air table base. And then try it. I do realize that it was a quite a less intelligent example that I came up in there. And then it guides you through step by step. It's really intuitive and really helpful as opposed to Node-RED, which all do really helpful and speeds things up, especially for a developer. You kind of need to have those habits that you would have while writing code. So, okay, I want to do something. How do I do that? I go research it. I read documentation. Look at APIs. How does the API behave? Which, more often than not, I find is way too overwhelming for someone just starting it. So maybe try starting them off with something a little friendlier and then they can move on to something else if they cannot achieve what they wanted with the first tool. I hope that's somewhat helpful. That does look much easier to use because it looks like you cannot plug anything together that won't work. Whereas with coding, and I think with Node-RED, you could plug things together that then might not belong together. Yes. Someone, John says, it would be good to take a small set of core nodes. That's actually something we're working on. I'm not sure I have it installed on this computer. It doesn't come with Node-RED, but my colleagues and I played around last year with wrapping Node-RED into an electronic app and providing our custom set of nodes for customers and then having a stripped-down version even for our nodes as opposed to having all these, which even our palette gets a little confusing for someone who is not familiar with the API because I know exactly that each one of those corresponds to a certain endpoint that I am aware of how it behaves and what to expect of it, but someone seeing this for the first time, I'm pretty sure it doesn't say a lot. So we would like to take even these and, well, that would like. It's already happening. And do the nodes as your first question, more of them building a use case and having a use case focused subflow. Well, not subflow because we saved it as a node, but it's a more comprehensive node that does more things, hence taking some of the complexity away and making it more abstract. So someone who is even less technical could approach that and then we would take out most of these nodes that you see in the default palette and only leave in there what they would need at first. Let me see if I have it installed. What are we calling it, I think? Interested to see your dumb-down version. We are thinking to do the same for apps in his construction vertical. Let me see if I can remember my password. So this is not the latest option because the latest version has the low-level things, but it is an electron application and it does have things in there. This was at the stage where we were looking at the developer option because we also thought about somehow building in a switch. I'm not sure. You can see it looks like a little bit more. It's wrapped with Angroc so that it automatically exposes it to the internet so that someone doesn't have to bother with that and then I can just Angroc and select connect and it will automatically expose it to the internet. So the same way that works, we want to put in a switch so that we can differentiate between enterprise and developer customers and then the switch would go so that it's only the high-level things and this would be the option for the developer version. Making those changes is only possible because Node-RED is open source. Do you know if it's up here? Is open source in the same way? Not in the same way because Node-RED is under the OpenJS foundation. You can create nodes for events. I think it's called events in Zapier, the equivalent of nodes, but I believe it has to be approved. You couldn't just clone this whole interface and tweak it how you wanted it? No. Even the nodes that... Well, I keep saying nodes. I'm logged in. Nodes are right now with even the building blocks that are called... So it's triggers and actions. I think the collective thing you call them is events. But even these are more use case-oriented, little more limited and definitely fewer than you could see in Node-RED. So we have four triggers and four actions depending on whether it's an incoming call or outgoing for the voice API as opposed to if you go back to the Node-RED editor, everything that is green is voice API. So these are the aspects where you can see that Zapier is more limited, although quite capable. I think John's asking if Ngrok is open source, but I don't think it is. It's a paid service for custom URLs, but there is a free package. One is Node-RED running in Electron. Yes. So as you're building it in, yes. We have it... I'm not even sure if we have the word bunch thing. That's the Electron app. It's accessible for the public. It might be private at this point because it's a work in progress. I'll be honest. That's the part my colleague did. So I am not entirely sure how that was wrapped. I should have the code that wraps it. I've heard of other people putting Node-RED in Electron before and when I Google for it, there's quite a lot of results. So you could probably just grab a tutorial or if you wanted to do it yourself, probably not too different. Oh, definitely. That's what we did. At that point, I think there was only one that completely rubbed it in a way that allows for customization and extending it, and we forked that repository and then started adding in the bits like sign in Ngrok and then the custom nodes. So it's very much still a work in progress and something that I plan on working on this year. And let me see if it is indeed private. If not, I'll leave the link in there. I found something except we've been going back and forth a lot and I am not sure this is the latest version. I'll leave it in there. This is how it started and then you have my GitHub as well. If I find it later, then I'll make it public. John says thank you. Shall we wrap up now? Junior, thanks so much for sharing with us. Good luck. Thank you so much.