Search
Search
May 29, 2024

SE Radio 618: Andreas Møller on No-Code Platforms

Andreas Møller, founder of Toddle, a no-code tool for building scalable performant web applications, speaks with SE Radio’s Brijesh Ammanath about no-code platforms. They discuss the role of developers in a no-code ecosystem and explore scalability and performance considerations, as well as enterprise adoption of no-code tools. Andreas also expands on why he built Toddle.dev and its unique features. Brought to you by IEEE Computer Society and IEEE Software.

Show Notes

Related Episodes

Other References

Tools in this Episode

Transcript

Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.

Brijesh Ammanath 00:00:19 Welcome to Software Engineering Radio. I’m your host, Brijesh Ammanath. Today our guest is Andreas Møller is the co-founder of Toddle, a no-code tool for building scalable performing web applications. He’s an experienced Vice President of Engineering with a demonstrated history of working in the information technology and services industry. Andreas, welcome to the show.

Andreas Møller 00:00:40 Thank you very much and thank you for having me.

Brijesh Ammanath 00:00:42 So today we are going to talk about no-code platforms. Let’s jump in and get started with the basics. Andreas can you help our listeners by defining what is no code?

Andreas Møller 00:00:53 Yes. So that’s a really good question because I think there are quite a lot of different definitions floating around. But the general definition we go by and I think is largely also the most broad one, is it’s any kind of technology where traditionally that’s been solved by writing code, but they are now at different approach. I mean, I get visual way of doing it and so maybe the most famous example of this, and I also think the tool that coined the term is Webflow, which is an application for building websites. And there’s quite a lot of, it’s been a very popular space for a couple of years now. For the last at least five years, we’ve seen a lot of new tools come out. So it’s very much a growing space and we’re seeing more and more of these platforms pop up. And even last year we saw several quite prominent platforms launch.

Brijesh Ammanath 00:01:41 Right. And I also know that the term low code is used quite frequently. Are no code and low code the same?

Andreas Møller 00:01:51 I think that there’s sort of a minor difference in the terms. They are very often used interchangeably. So there is not a clear distinction that you can always rely on. But I think the term low-code is largely the idea that entirely removing code from a normal workflow is either not possible or not easily achieved. And as a result you sort of end up with a little bit of a mix and match solution where you’ll add some code here and there, but a lot of the things you’re building is you’re still building without code. So I think the main difference is that with low code you are still coding as part of your daily workflow and in no code workflow you might occasionally have to add a little bit of code, but it’s mostly done without writing any code.

Brijesh Ammanath 00:02:36 So it’s just drag and drop and that reduces the flexibility?

Andreas Møller 00:02:40 Well, so in a lot of times, in a lot of cases it can reduce flexibility. I mean you can overall say it does, but the way we generally see it, at least in Toddle is that we are limiting the number of ways you can do something, but we’re not really limiting what you can do. And so the limitation of each tool is very dependent on the tool. Some tools are very optimized for speed and ease of use and in return they also limit a lot what you can actually do with them. Others are a lot more broad and impose very little limitation on what you can build.

Brijesh Ammanath 00:03:13 While researching for this session, I came across an interesting stat, I’m just going to read it out. According to research and markets, the low-code and no-code development platform market is expected to generate about 187 billion by 2030 and it was about 30 billion in 2023. Gartner also estimates that 70% of new applications are going to be developed in enterprises by using low-code or no-code technologies by 2025 up from less than 25% in 2020. And those numbers are just mind bogglingly huge. What is fueling this growth or adoption of no-code?

Andreas Møller 00:03:48 So I think the first thing to note with that is that that’s not the reason of a study anymore and I would actually suspect they might be even more bullish if they had to do the same today. Because we have seen a lot of adoption and we’ve also seen a lot of growth in the number of tools out there. I think there’s a few things fueling this and to sort of understand a little bit about that. You also have to understand then when we say no-code tools or the no-code market, which like Gartner likes to say there isn’t really a no-code market. There’s quite a lot of markets that has no-code tools in the definition I sort of presented earlier saying it’s largely just a term that means an area where everything used to rely on code, where we now have a set of more visual tools, right?

Andreas Møller 00:04:33 But that really doesn’t define a market very much. So it really does depend on the specific tool you’re talking about. But the majority of the no-code sort of change has happened in the area of where it enables non-developers, people who wasn’t traditionally developers to build applications. And we especially seeing a large growth for internal software. So tools like Retool, JetAdmin has had immense success with enabling companies to build smaller internal tools very easily and usually without actually involving large part of the respective engineering organizations. So a lot of times it’s a way to sort of be able to actually produce software but without spending valuable time from your often more highly paid employees in your engineering department.

Brijesh Ammanath 00:05:21 That’s interesting and leads us nicely into the next topic of discussion, which I wanted to touch on, which is what’s the role of developer in the no-code marketplace or environment? So according to you, what’s your primary role of a developer in a no-code environment?

Andreas Møller 00:05:37 So I think for a lot of cases, for a lot of tools are really designed for people who can’t traditionally code. So they’re really designed with a first and foremost principle of how simple can we make this to a point where even if you’ve never programmed before, you can fairly quickly pick that up. But at the other end of that spectrum of no-code, which is where Toddle, the company I founded lies, we are a lot more focused on how we can improve the efficiency of technology teams. So I think there’s one end where you basically say we don’t really need programmers because we simplified things so much that that knowledge isn’t that important anymore and at the other end we have still professional software teams. And in our end in Toddle and what we are building, developers are very much a big part of that.

Andreas Møller 00:06:27 While we are removing a lot of the early frictions of learning to code, I think all your lessons will know that’s not all software engineers do. There’s actually quite a lot to the job and you don’t even code all of the day, right? So there’s still every bit as much need for engineering. We are still building distributed system at the end of the day and they have raised conditions and problems and everything we always run into. You still need to do data modeling and architecture and all these things. None of that went away. The only thing that we’ve slightly changed is the fact that you don’t need to spend often several years learning a programming language before you can get started.

Brijesh Ammanath 00:07:05 Can you expand on that and are there any examples of tasks or responsibilities that developers typically handle in a no-code project?

Andreas Møller 00:07:13 Yeah, absolutely. So I can sort of mostly speak about how we do it at Toddle. So we both build a no-code tool, the platform, but we are also working in it. So since Toddle is itself building Toddle, we build a no-code tool in itself. So that means we are also a full company working every day in this no code tool, building it. And we are a cross-functional team that consists of engineers, designer as well as a marketer. We’re a fairly small team still and the whole team, including our marketer actually works in Toddle, not always daily. Obviously, our marketer does a lot of other things, but he’s also able to go in and make changes. And so what really changes in our setup is that rather than having a more traditional sort of almost assembly line of features where you know a product manager will come along and say let’s build this thing, a designer will then design it and engineer implements it.

Andreas Møller 00:08:10 We’re actually able to work in parallel. So engineers can work on the logic of one feature while the designer works on the UI and they’re not handing off the design to be implemented, they’re literally implementing the final UI. So by having that sort of dynamic ahead of the, like the role of the developer didn’t change, but a lot of the sort of more maybe cumbersome task of just producing UI that someone already designed that actually goes away and you can start focused on the functionality in the interaction, which is I think what most engineers find to be more interesting, especially when building the front end part of applications.

Brijesh Ammanath 00:08:48 We will deep dive into the Toddle development model, in terms of that platform itself in the next section. But before we go there, I had a few more questions on the role of developers. The next one would be, do you have any examples or success stories where developers have played a crucial role in driving innovation through no-code development?

Andreas Møller 00:09:09 Yeah, I mean again, I think our own case is a very good example of building something immensely complex in a no-code setup, right? We’ve also had a lot of examples among our customers. We had a person who signed up to Toddle and actually managed to start a company in 10 days. He started building an app till he had his first customer onboarded, it took 10 days, right? And he was a developer but he was not a particularly experienced developer. He has done some coding before but didn’t have a long career behind him. And we are also seeing examples of people switching from, we have a few users that have longer careers in coding that switch to no code for the simple reason of you can just deliver faster, right? You can produce applications faster than you can do in a traditional setup, right? And that iteration time, that sort of ability to move fast ends up being incredibly valuable.

Brijesh Ammanath 00:10:03 Agreed. When I started coding, we had something called a thread rapid application development and low code reminds me a lot about that.

Andreas Møller 00:10:12 Yeah, I think there’s a lot of similarities. I think forever we’ve been chasing this idea of a lower feedback type, right? Most of my career has been as a web developer and we sort of went from in the old days where you wrote some code and then uploaded it somewhere and then had to refresh your browser to see if it worked. And then we started getting build system and eventually we got some auto reload where the browser would automatically refresh and it was the greatest innovation in the world because now it only took like two seconds from, you made a change to you could or maybe five seconds because our page didn’t load so fast at the time. And so we’ve seen these improvements all the time and the fact that feedback time has always been a key metric to chase because we know the lower the feedback time essentially the faster you can experiment and the faster you can iterate, right? And what we are seeing with no-code, especially for front end and for building UI is that we are now getting that feedback down to milliseconds. So you’re really like clicking on something, you’re selecting, you’re changing properties and you’re seeing the changes right there. You don’t even have to look away from what you’re working on while you’re editing, right? So by getting that cycle time down, productivity just goes way up. And that keeps happening all the way down to like when you’re getting down to a couple of milliseconds feedback.

Brijesh Ammanath 00:11:29 I also believe there’s change in perspective that needs to happen when you start building out a no-code platforms. So have you seen developers facing challenges when they start out in this new model of development?

Andreas Møller 00:11:42 Yeah, I think one of the things, a way to look at a no-code platform is you can kind of see it as a framework that’s very opinionated, right? Because generally no-code platforms are, so where for example if people work with web development where something like React is generally considered very not opinionated, you can bring in whatever other technology you’re looking for, right? However you want to do styling to it that way, however you want to do routing and server-side rendering to it that way. I think we are looking at something that’s more on the end of like, Ruby on Rails where like there’s one way, we do things and this is how you should do it and if you don’t do it that way it’s going to be harder, right? And no code is like even more opinionated with that. So I think there’s a lot of times where you kind of have to say, well whatever platform you choose, they made some calls up front of this is how we like doing and generally you need to lean into that. So Toddle for example, gives you a ton of flexibility on what you can do. But we generally have a fairly strong opinion about how did you do styling, how do you do A, B, and C? So I think that’s usually the first one and we see a lot of people like I wanted to do it this way. We basically said, well you can achieve what you’re looking for, but you can’t do it that way.

Brijesh Ammanath 00:12:52 Right. What advice would you give developers who are interested in exploring or transitioning into the world of new code development?

Andreas Møller 00:13:00 Well I think the first thing is it’s important to start out with an open mind. Especially because I think a lot of, if it’s a more experienced developer that’s been around for time, I think a lot of them are sitting with the feeling of, we’ve heard this story before, there is nothing original in the idea of no-code or visual development. The earliest example I’ve been able to find is from 1963. So before it became a standard to have monitors attached to computers, someone started to paint and start programming with a light pen. So it really isn’t new, right? And we’ve seen all these examples of visual basics was probably one of the most successful ones. But we’ve also seen Dreamweaver, we’ve seen a lot of them and they never really took off. And I think a lot of people have a general feeling of it’s nice and it’s cool, but obviously you can’t do real programming, is it? You can’t build anything complex. That’s the big change that’s happening today that we’re beginning to see platforms that actually lets you build things that are immensely complex. Things that are scalable beyond what most people ever thought was possible with that. So I think that’s probably the main thing, come at it with a little bit of an open mind because a lot has happened since maybe last time people took a stab at this, right?

Brijesh Ammanath 00:14:12 Yeah, agreed. I think it’s important to understand there is a lot of engineering con behind developing the no-code platform, which allows you to move faster and not treated as something which is just for fun and games.

Andreas Møller 00:14:25 Absolutely.

Brijesh Ammanath 00:14:26 The other thing I wanted to touch on was methodology. So when you’re developing software, you usually have the traditional way of developing software is Waterfall and now mostly it’s Agile. When you’re doing no-code development, what methodology do you use?

Andreas Møller 00:14:41 Well I think that kind of still is left up to people. I mean generally, your platform is not going to dictate your team structure and they’re not going to dictate how you want to run your software process. I think the one thing we’ve seen that’s interesting is that it opens up for a new way, at least what we’ve experienced with Toddle, it opens up for a new level of agility that you didn’t have before. So as I said, like traditionally, even if you’re working in Agile, what you’re doing is you are reducing your iteration time to maybe you’re what you’re spitting out in a week, but you’re still having a team that’s put together people with different backgrounds and you still largely have this sort of designer feeding design sort available to implement. And so what we’ve seen a lot is that when you start bringing iteration time down, and not just iteration time but also the time it takes to actually go from, I want to start working on a feature till that feature is done.

Andreas Møller 00:15:38 Like the time to deploy in Toddle for example, is incredibly short as well. So we’ve had cases where, for example, a user has reported a bug and I think our current record is 11 seconds from it was reported till there was a fixed live. Now that was a really trivial bug of course, right? But that’s kind of the level and when those tools become available, when you start changing what the normal is, all of a sudden your team, at least in our case also start working a little bit different, right? So I’ve worked in companies that had very large complex setup for how you release a feature where you have staging environments and you have even pre-staging environments and staging environments and then you have level one, two and three environments before things got released, right? And anything from that to a way more sort of continuous deployment model.

Andreas Møller 00:16:27 And with Toddle we’ve sort of been able to take that even further where we are sort of internally very heavily run on using feature flags. So someone can literally push like we are pushing to production. I think we have a five person team and we have days where we push to production 20 to 30 times and we are not always shipping all those features. A lot of times they’re feature flags. So we are the only ones that actually get to explore them. But the fact that we can do that, and it’s not just engineers that are doing that, but our designer is doing that as well, right? He’s modified design and actually get these things out quickly. So I think that start is sort of, there’s some new opportunities of how you can work, which is sort of like Agile, but even more agile.

Brijesh Ammanath 00:17:09 The other question I’ve got is, something related to my personal experience. Quite early on in my career I worked as a VB6 developer and VB6 had a very low barrier of entry. Almost anybody could pick it up and start coding in VB6 and start delivering to the business. And that meant there were a plethora of VB6 developers and that talent was easily available, which meant that the only way you could differentiate was being very good in the domain. So you became a VB6 developer with say, FX options knowledge, which allowed you to differentiate yourself in the job market. Is it something similar for a developer who’s developing in a no-code platform and how do they progress in their career?

Andreas Møller 00:17:52 I don’t know if we’ve entirely seen that trend yet, or at least seen enough of it to conclude that’s where things are going. But I think it’s a very likely outcome. We’ve lowered the barrier of entry to development, which means that obviously a lot more people can, and I think one of the interesting thing is as we’re saying, all of a sudden the designers on the Toddle team are not just designing anymore, they’re actually developing, but they’re just developing a very specific aspect of our application. So they are essentially UI UX developers and not just designers, right? They’ve embraced that and without having to fundamentally change that much about their current skillset, they’ve now adopted a whole new role. And at the same time we’re seeing a lot of our developers that come from a traditional coding background are still doing many of the same things they’re doing, but a lot of the UI implementation work, they’re not doing as much of anymore.

Andreas Møller 00:18:46 And a lot of the traditional, like there was always a ton of tickets was like, can you please change the text on this button? That kind of stuff, right? Which was never really, it didn’t feel like there was a reason to have a senior engineer handle that one, right? So those kind of tasks kind of go away because they’re so easy to implement for anyone that it’s kind of easier to fix it in the app than it’s to create a zero ticket, right? Yeah. So I think roles do change and I think to some degree we are seeing more specialization in that way towards focus of design and focus on either logic or I think we’ll also see a lot more full stack developers in this world because if you understand the logic of how it works one place and the other, there’s not that big of a gap, right? Kind of like we saw it with JavaScript that once people could start working in one language, all of a sudden we saw a lot more full stack developers, right?

Brijesh Ammanath 00:19:39 What is full stack in a no-code world?

Andreas Møller 00:19:42 So I think it lastly means the same as it does in the traditional sense. So for example, Toddle as we build is only focused on the front end. So it’s built to connect to a backend, whether that backend is building code or whether it’s built in in another no-code tool that focuses on the backend, right? But I think it largely is the same responsibility of someone that cuts across that network connection between the browser and the backend that focuses on not just how do we present this information to the user and how do they interact with it, but also how do we store it? How do we update these things? And it’ll most likely be anything from database design to implementing a lot of this in the front end as well. So if anything it might go a little bit further than it did before.

Brijesh Ammanath 00:20:25 Okay. And I think that’s a good segue into a next section, which is a deep dive into Toddle. And the question I’ve got to start it off would be why doe Toddle not have a database?

Andreas Møller 00:20:36 Yes. So there’s a couple of reasons actually why it doesn’t have a database. One of them is that it’s practical not to have one. So when I started out looking at Toddle, I was sort of saying like how can I actually make this work, right? I wanted to build a tool where at least coding is optional and it’s very clear like if coding is optional, then where do you put your source code? Doesn’t make any sense, right? If I’m removing code as a barrier to getting started, you kind of also have to remove your source code, GitHub style hosting, right? Because it doesn’t really make sense to have that. So I also needed like a version control system built for Toddle, like going line by line and comparing anything wouldn’t make sense when you weren’t working with source code, right? And of course the last part is actually figuring out how to deploy all this and run it is also something we often as engineers end up spending enormous amount of time on, even if we’re using a service provider, there’s still always work setting that up.

Andreas Møller 00:21:31 So it’s also very clear for this actually work I would also need to have a host service. So it’s like I’m building a programming language and it’s easier to work with that program language as well as a version control system and a hosting provider. I don’t really need to add more to that stack. I feel like that’s already more than enough to try and get working. Right? So a purely practical of saying trying to do everything will mean that I’m going to end up doing most of it sort of less than ideal, right? But the other part is actually probably for the same reason where we never really saw a full stack code framework. We’ve seen some examples trying and then I mean certainly some of them has been more successful than others, but the model never won out. And I think the fundamental reason for that is that while the front end tends to not be too dependent on the kind of app you’re building, like whether you’re building a web shop or a social media platform or an enterprise or a scheduling software, React tends to be the number one choice of framework for the front end.

Andreas Møller 00:22:33 Or there are other choices and I mean this is certainly not a reactor necessarily better than any of them, but it is the most popular, right? So we have this one framework that works across all of them, and the other frameworks are not more industry specific, right? They’re all super cross-functional in nature. Now when we go to the backend, people start to pick technology a little bit more specifically based on a use case. In the front end we tend to largely just go with the front-end framework, and you’ll pick one or the other, but it’s always got to be one of the big three, right? On the backend I think there’s a lot more variation. So sometimes it makes sense to have some lambdas running some JavaScript. Sometimes you’re setting up GO and docker containers, sometimes you have, you know, Magenda, e-commerce platform. Sometimes you are hooking into a whole different system. So I think when you fundamentally look at frontend technology stacks and backend technology stacks across different companies, you’ll see a lot bigger difference on the backend. It’ll be easier to check what is this company doing by looking at their backend as opposed to the front end. I think that’s largely why we haven’t seen these full stack frameworks because the one size fits all don’t really exist. At least that’s my theory to why that never went out.

Brijesh Ammanath 00:23:49 Right. I think, you know, version control is one thing which is missing from majority of the no-code platforms available in the market and Toddle bridge that gap. Were there other reasons why you felt the need to build a new no-code platform?

Andreas Møller 00:24:06 Yeah, absolutely. So I kind of came at this from my own slight personal use case. So when I started considering Toddle, I actually spent almost a year trying to convince myself not to do it because it’s obviously a massive undertaking to try and build something like this. But when I started looking at like playing around with the idea of this got to be possible, why does this not exist? Can I figure out how to make this? Obviously, I looked into what actually does that exist? And obviously the first thing I saw was like, okay, no code is a is a very broad spectrum of a lot of different solutions and we have anything from like page builders like Squarespace, right? Which is a no-code tool, but it’s very much not one for building SaaS applications. And then as I looked at the ones that were more focused on building applications rather than website, that’s a bit of a gray area of overlap.

Andreas Møller 00:24:56 But I think in the more complex end, there was a few things I was always missing. So one of the measurements is version control, which is I don’t think any engineer out there would take a job if they said, by the way, we don’t use Git. We all work on the same files, and we just try not to ruin everything. I think nobody would really want to work in that setup, right? And I mean if you are one person, it’s fine. If you’re two people it’s very difficult and if you’re three people, well you’re not all working at the same time. So that just from the world I was coming from of more professional software engineering of working with anything from startups to enterprise level companies, the idea of not having version control and like a Git style version control was just kind of unheard of, right?

Andreas Møller 00:25:39 Like it wouldn’t make any sense. So that was one of them that was really key. The other thing that I had was performance is one of those things that you don’t care about until you need it. I think we had this conversation, the React community a lot is react fast, is it fast enough? I think for many things it’s fast enough but it’s definitely not fast. And eventually you might run into a scenario where it’s not fast enough and then you need to consider something else, right? And that’s kind of the same with a lot of this in in the no-code world, that’s just the same problem but at significantly lower performance, right? And as I mentioned, you can often do a lot of things but how you do them is differently. So when you’re locked into a no-code platform, it basically sets the benchmark like it sets the bar for how performed an application could be. It’s not going to be ever faster than the platform allows you and fundamentally you have no ability to influence that. So just like with frameworks, it is very important. Frameworks are fast because if you need it to be fast, there’s nothing you can do with people building the frameworks hasn’t built it that way. It’s the same thing with no-code. And so that was a limitation where I could see it, but I can’t invest in that as for a larger project if this is the baseline for performance.

Andreas Møller 00:26:55 And I think the third bit was basically I need to be able to know that if I start building a project in this, like obviously in the professional engineering world, if we make a bet on a technology, you’ve got to also know that that holds six months down the line or a year, right? And obviously any new technology, there’s a certain like you may not like what you chose. Sometimes you make a choice, and you realize it wasn’t the best choice. But it should never be in a situation where the platform tells you this is not possible, right? It can’t be the platform dictating what kind of features you can build. And that was kind of the case for all of the existing platforms. Like a lot was possible but there’s always a limitation. There was always a point where it says you can get to here, but you can’t get further. And from where I’m coming from, those were sort of the basic principle of saying we can’t ever have any of those, right? We got to have good version control, we’ve got to have really good baseline performance and we’ve got to have a platform that’s flexible enough. So no matter what problem you end up having, there has to be a solution.

Brijesh Ammanath 00:27:56 Right. I’m very curious in understanding how did you solve the performance problem? Because fundamentally a no code platform allows you to build only within the constraints of the platform. So how did you solve for it?

Andreas Møller 00:28:09 The interesting thing is that that’s actually a plus for performance and not a negative, right? So when you’re building a framework or a platform, the more constrained your users are, the easier it is to optimize performance because the less edge cases you have to deal with. So in Toddle it kind of works. I mean fundamentally Toddle works the same way as a web app built in a framework. It’s a very, like if you’re familiar with React, angular view, actually any of those, you’ll really see the influence and the parallels very clearly when you start working with Toddle. And so we actually have the additional benefit of, because we are building the language like the underlying language as well as the editor and the framework and the hosting platform, we can optimize things across all three that would be very difficult to do in a code setup.

Andreas Møller 00:29:01 So actually the fact that there are some constraints in how you can do things in Toddle allows us to optimize performance more than would otherwise be possible. Now that doesn’t necessarily mean we are faster than every web framework — like some of the new frameworks out there like solid and quick are showing really impressive performance — but I do think it means that we can be, I do think there’s the possibility to optimize Toddle. So down the line as we invest more and more time in this, I think there’s the possibility to actually baseline be faster than most code frameworks for this very reason.

Brijesh Ammanath 00:29:34 And how do you balance that performance with the flexibility you’re able to provide your users?

Andreas Møller 00:29:41 So that’s a really good question and I think it’s not so much one-to-one that when we give more flexibility you get less performance. It’s more when we give more flexibility, we give people the opportunity to worsen the performance, right? So there’s always a certain level of like is this the responsibility of the platform or is this the responsibility of the developer? Right? And of course we could get really good performance by just saying, well it’s their responsibility we put it on the final developer, right? And then, you know, if images are not optimized, if you’re loading too much code or being inefficient, well you should not do so much. But I think our approach has sort of been it there has to be a balance. We want to do as much as we can unless we say flexibility is one of our core principles, we never want to not allow you to do something.

Andreas Møller 00:30:29 We just want to make sure that you’re doing it in the smartest way possible. So we don’t strike so much a balance there. Like we rarely ever limit your flexibility for performance in terms of what you can do. I think most of what we’re doing is sort of prioritizing, right? There are sometimes where we want to build more powerful features for users and there are some times where we want to go back and optimize performance. And I mean we’re taking part of this journey of making Toddle an incredibly fast platform and it’s a very fast platform today, performance today is kind of comparable to a next React setup where actually Todd is slightly better on the update performance. So once your application is loaded, it generally performs better than React, at least for a large complicated apps. But there is still so much more work that we can do and that we are continuously doing on getting that even better and even better.

Brijesh Ammanath 00:31:17 Right. You talked about the challenges to move from staging to release and also to have continuous deployment and how all of that is solved in the new code platform where we immediately deploy stuff. One of the big gaps that I see in the current existing set of no-code platforms is the lack of a test environment, a staging environment before you go into production or deploy into production. Is that something which has been solved in Toddle or how does that transition from a dev setup to production happen in Toddle?

Andreas Møller 00:31:50 So what we’ve done in Toddle is basically what we so often do, which is look at who do we think currently solve this the best, what is the best solution we think is out there and then can we basically adopt that? And personally I think platforms like Versal and Netlify are the ones that has cracked this best. I for a long time haven’t been a particularly big fan of joint staging environments where code goes to live and eventually nobody actually knows what they’re releasing by the time they get around to a release cycle where the sort of Netlify an Versal model of every branch has its own live environment and you can go and test that and verify and do everything you want and it’s an exact copy of what production’s going to be like or at least as much a copy as you want.

Andreas Møller 00:32:35 You could choose to run it against a separate server if that’s what you want to do. And so we have the same, when you create a branch in Toddle, that branch is live from the second you create it and every time you change it, those changes are automatically updated. So as you are developing a branch, people looking at that preview environment as they refresh it, we’ll see the always see the latest version of that, right? And so I think that’s kind of the best of both worlds. And how you then decide to manage your deployment process, again we give you some freedom here. We strongly believe that pushing often and early is the best approach and using something like feature flags to make sure that you control what actually gets released to customers, which is something we use quite a lot. That’s our preferred way and that’s what we are sort of nudging people towards. But you still have the freedom of doing something a little bit more traditional and saying I want this branch to live a little bit longer. I want to do a proper like full end-to-end test on everything before it releases.

Brijesh Ammanath 00:33:34 So if I got that correctly, what you’re saying is that as an open needed platform you do not encourage long lived staging branches. Rather your focus is to try to get your users to use feature flags and production so that specific features as it is can be enabled or disabled in production.

Andreas Møller 00:33:54 Yeah, absolutely. Most of the team I have here in Toddle is someone I brought along from the last company I was at. This was the same thing we experienced again and again there that staging environments tend to end up being a lot more trouble than they’re worth. And actually there’s a lot of research, there’s an almost endless amount of this ports pointing to the fact that the ability to deploy quickly and having quick release cycles is the number one thing that predicts quality of software. So we are very big proponents of that, and I think that’s also what we wanted to build with Toddle. We wanted people to get into that mindset of push early, deploy earlier, deploy often, right? And of course when you use feature flag deploying to the main environment or to your production environment doesn’t necessarily mean shipping new features to customers. So changes to customers, you get to do that control in your live environment. So it doesn’t mean that you’re shipping things that are untested, it doesn’t ship that anything is riskier, it just means you have a lot more of a streamlined approach to software delivery.

Brijesh Ammanath 00:34:56 Right. I think you also mentioned that most of your team are building Toddle using Toddle. What does that mean?

Andreas Møller 00:35:02 Well, so what essentially happened is that really early on, which is now a couple of years ago of building Toddle, I got to this stage where I started to realize that this could actually work, right? Okay. I might actually be onto something. Because in the early days I was sort of very skeptical about is this even a good idea? Do I even know what I’m doing, right? So I ran into a lot of issues but they were already solvable. So every iteration it seemed to work better and better. And eventually it kind of got to a point where this seems to work like when I go through this logically, this model works like this platform works for building something very complicated, but there’s a big difference between thinking it works and you know, theorizing that it works and then actually knowing it works.

Andreas Møller 00:35:47 And so I realized in order to both prove to first of all myself but also to anyone in the future that you can actually use this to build very, very complex applications, I needed to build a very, very complex application. And since I was a lone person working on this, that didn’t make any sense having to work on multiple large complex systems at the same time as a single developer. And the same time I always knew that eventually the ultimate test of a platform like this is the same you see for any program language. Are you going to write the compiler in the language itself? That’s why most program languages do that today. And so I started rebuilding, like I had a version one that was built and React at the edits part, right? And then I started rebuilding it in Toddle and eventually got to a point where I could then throw away the React version and keep building in Toddle from there on.

Brijesh Ammanath 00:36:38 Interesting. Moving on to the next section, which is around scalability and performance considerations. Can you touch on the strategies which are employed to ensure that platforms can handle spikes in traffic and usage without degradation in performance?

Andreas Møller 00:36:54 Absolutely. So because we made the choice early on to at least initially, and I think we don’t have any plan to expand on this, but for now we’re frontend only platform, right? And we do have a little bit of code running service out. We are hosted on Cloudflare and we are running some code on Cloudflare workers specifically for server side rendering. But there’s two things we handle server side we let you proxy API requests through a Cloudflare worker and that basically means that you don’t ever have to deal with things like course issues. We can also handle authentication in a very secure way. So even if you require like an out token as part of a header, we can actually store that in an HCP only cookie and then just add the header on the proxy layer and thereby making sure that your secure credentials actually never make it to the front end but sort of eliminates a whole suite of potential cross side scripting attacks you can do, right?.

Andreas Møller 00:37:49 And the other thing is server-side rendering. So you actually get like a server side rendered version of the application as fast as possible to the user. But that’s really the only two things we do on the server right now. And since both of those hosted on Cloudflare workers, they’re very good at handling spikes and traffic. They’re very good at handling large scalable things and it’s all serverless so it does scale really well. So I think scalability in terms of traffic is not a particularly large issue for us. It’s kind of almost delivered by the platform. Now that’s a little bit oversimplified. Of course there are always challenges as you scale, but not in the sense that for example, if you were providing a server as a service solution you would’ve to deal with. Right,

Brijesh Ammanath 00:38:31 Right. Got it. And is that a similar approach you take for monitoring and analyzing the performance metrics, you know, such as through port response times? Is that also something that you rely on the cloud flare metrics?

Andreas Møller 00:38:45 Yeah, so we get a lot of it from Cloudflare metrics. We also use Honeycomb with the distributed tracing analytics tool that I can highly recommend. I don’t know if you’ve had any of them on the podcast, but it’s a really impressive tool that basically allows you to get very detailed view of almost down to a function running in the backend if you want, of how long did that take to execute and what exactly it took time. So when we are for example trying to optimize page load time for Toddle applications, we are looking at things like how long did it take for our worker to figure out what project it needed to load, how long did it take to fetch the actual code or no code if you will, that actual data that needed to essentially turn into the rendered output for that application. How long did rendering take? All these things we can break down by each step of like what is actually the performance. And because we have that in honeycomb, we can also get like what did the 95th percentile, what is the average? All these things. So we can do a lot more detailed performance analytics of things like how long did different pages take to render, et cetera. Which is a big part of how we are also working to optimize that performance.

Brijesh Ammanath 00:39:54 Right. Moving on to the next topic, which is around security concerns. What are some of the common security vulnerabilities in a no-code platform that is different from traditional coding?

Andreas Møller 00:40:05 I don’t know if then necessarily that different. I think there are some benefits and some setbacks if you will. I think the benefits of a no code platform is again back to this idea that as you are slightly limiting how people can do things, you are also limiting some of the bad ways that people can do things, right? So one of the things for example we’re doing with Toddle is this idea of saying, well you can store your out credentials with us and by credentials here, I mean access token, I don’t mean like your actual password, we never store that of course. But let’s say you’re logging into a service you can sort of choose to saying when I’m getting a token back, I want to save that as a session cookie in Toddle. And what we are actually doing is we’re storing I say HCP only cookie and thereby preventing the front end from being able to read it again.

Andreas Møller 00:40:50 And then whenever you’re making an API request to the service that needs it, we are adding it back in on the proxy layer. And so that sort of eliminates a whole session, like a whole suite of potential attacks right there. And again because we can handle a lot of it at a platform level, there’s a lot of things where we can actually make this more secure than you wouldn’t code simply because we are closing a lot of the potential issues, right? We are handling a lot of the potential mistakes you could make as an available. Now the downside of that is that as you advertisement platform where everyone can learn to code, it also means everyone doesn’t have experience with software security and different attack services. So I think if you are overall looking at no-code today, I think on average I think it’s fair to guess that platforms are probably a little bit less secure than most one’s written code. I don’t think that’s the limitation of no-code. I think that is that generally on average your no-code developers less experienced today than both software engineers.

Brijesh Ammanath 00:41:53 Alright. I did a quick look up and we have not done a specific session on Honeycomb, but we did do a session which was Episode 455 where we had Jamie Riedesel on Software Telemetry and we had discussed a range of topics or telemetry tools.

Andreas Møller 00:42:11 I will go and look that up because that is probably worth, it’s one of the things I only quite recently started looking into, but every now and then you try one of these services technologies where you realize you’re never ever going back, right? And this was definitely one of them, like having that kind of insight into what happens in your system once you’ve tried it, you’re never going to want to not have it again.

Brijesh Ammanath 00:42:31 True. Are there any specific compliance frameworks or certifications that organizations should consider when using no-code platforms?

Andreas Møller 00:42:40 I don’t know if there’s anything outside of mainly just your standard service providers, things you should consider. There’s a few things that I think they’re the same. You should always consider when using a service provider. So like if you’re a European company, you need to be aware and actually no better way your company is, you need to be aware of things like GDPR compliant. So again, with Toddle, we don’t store any data on your users if you are using our platform. So GDPI is not really an issue in our case. And also, we don’t do any tracking on any app you do in Toddle. You can obviously add that in if you want, but we are not doing that out the book, any sort of tracking of any of the users. So that issue is not there. But if you’re using a no-code backend, of course anything where you store data, these all things you need to be aware of. And of course depending on your industry, you might need to require things like HIPAA compliance, all these things. It doesn’t add any new concerns that you don’t always have if you’re, let’s say an authentication provider or a hosted database, it’s the same kind of things. You have to go the same checklist; you need to go through and verify that actually it is well within compliance of your requirement.

Brijesh Ammanath 00:43:44 Right. Moving on to the next topic, which is enterprise adoption. What’s the current state of enterprise adoption for no-code platforms?

Andreas Møller 00:43:52 So we are seeing really good adoption on certain areas. I mentioned earlier that no-code is this vast space of many, many different kinds of tools. So when we are looking at internal apps, so for example, I think right now the key ones, people are talking a lot about Retool and JetAdmin being two really popular ones. They’re seeing a very positive trend also among enterprise customers. We have one of the earlier platforms like AppGyver, which is a no-code platform that was acquired by SAP. So I mean that’s obviously very enterprise focused then, right? So we are seeing it, we are seeing it in specific areas. And usually around internal apps or sort of secondary apps, which means it’s not used for your primary product. And again, Webflow also being very successful. We are seeing a lot of really large companies in the high-profile companies building their landing pages and Webflow. One area where we haven’t seen much enterprise adoption yet is in the actual SaaS space, which is where Toddle also is, right?

Andreas Møller 00:44:53 The area we’re looking for. And I think there’s largely two reasons for that. One is that the same reason I listed early on as to why I built Toddle are the things that I felt was lacking for me to be able to commit to an existing no-code tool. I think all those same problems is preventing any enterprise adoption. You can’t run an enterprise software team if you don’t have proper version control, that’s not really going to work, right? And at the same time, often when you get to larger companies and it’s looking at their products, now the larger software teams start to talk about things like performance budgets, etc. And it’s becomes normal for teams to actually continuously measure performance as you deploy. And I mean once you’re getting at that level when things like load times instead of something you take very seriously, historically a lot of the platforms just wasn’t able to deliver on that, right?

Andreas Møller 00:45:42 I think Google and Amazon both did studies on the cost of a hundred millisecond load time. And so when some platforms are saying page load time is somewhere more like five to six seconds or three to six seconds, right? For a web shop of Amazon scale, like that would never work. It would simply not be worth it to go in no-code way. And so I think for the newer tools like Toddle, we simply haven’t been around long enough to get to that level. We are looking at good adoption from early adopters and startups getting started with Toddle and building things and smaller software companies starting to notice us and start building projects in Toddle. But for these to get to enterprise level’s going to take a lot longer.

Brijesh Ammanath 00:46:23 Right. And what’s the level of integration support provided by no-code platforms with existing IT systems and infrastructure?

Andreas Møller 00:46:32 Yeah, so I think that depends a lot on the platform again. There are many different setups for, if you look at the kind of no-code platforms like Toddle for the front end, we sort of decided early on that we would want to start with working with everything and then later on making specific things easier. And what I mean by that is we started out building a good system for connecting to HCP and Rest APIs, right? So basically no matter what your API is and where it’s hosted and what platform it is, it’s easy to connect to it because everything speaks to HTP. And then later on we’re beginning to look at how can we make this even easier for a select amount of platforms. So build easy to use integrations on top of this abstraction, but by default you can connect to anything.

Andreas Møller 00:47:18 So there’s nothing you can’t integrate with, just like when you’re building your front end React, you’re using Fetch to connect to your backend, right? So it works with everything. You don’t have an integration that you need to look at, right? For some of the other tools, I think one of the tools that I discovered early on is a tool called Make. There are actually two really big competing tools in the same category, Zapier and Make. And they’re basically like sort of glue code or glue no-code, if you will for services. And what they basically do is you can sort of set up integrations to call each other and then add a little bit of logic in the way. So you can do like when I get this Stripe web hook when this Stripe web hook is called actually call this workflow that I set up in let’s say Zapier.

Andreas Møller 00:48:02 And then from that call, let’s insert a road into my database or call, hook in mail a light to send an email to someone. So you can build all these automation workflows efficiently. And both of these platforms has thousands of integrations. So depending on where you are, some of them are really, really well integrated and designed for that and some of them are a lot more flexible and sort of has you do a little bit more yourself but sort of allow you to still work with pretty much any platform you’re looking to.

Brijesh Ammanath 00:48:33 Agreed. But I’ll make sure we’ll link to those tools in our show notes. But Make is quite an easy one to remember. It’s Make.com and very flexible.

Andreas Møller 00:48:42 Yeah, absolutely. We actually it’s one of the tools we also use as part of our stack. So we obviously built the front end in Toddle and then we are using Cloudflare workers as sort of a proxy layer for server-side running on APIs. But we also have super base, which is sort of I think generally considered more of a low code or just a backend as a service platform as well as Make a sort of being a glue that binds a lot of different services and workflows together.

Brijesh Ammanath 00:49:10 What’s the role of IT departments and governance teams in supporting a no senior adoption of no-code platforms in an enterprise?

Andreas Møller 00:49:18 Oh, that’s a good question. IT department’s role would probably change a bit, but I suppose it’s largely the same trend we’ve seen with DevOps happening over the last couple of years. As you are managing a lot less of your own software and a lot more get hosted, these roles start to change. And so in that sense, no-code are largely managed the service and managed the platform that takes care of a lot of the management of your infrastructure, so you don’t have to do it yourself. So in a lot of ways it’s just kind of a continuation of that same trend. I think governance and compliance, those things don’t necessarily change too much their roles as they see today. I think you always need to validate your suppliers and in this case your no-code platform is another supplier, right? So it’s as this becomes part of your service infrastructure, it’s part of the network of services that you need to be aware of and understand what data is available there, what are we providing them, what are the agreements we have for them?

Brijesh Ammanath 00:50:18 How do you see the landscape of enterprise adoption of no-code platforms evolving in the future? And what trends or developments do you anticipate emerging?

Andreas Møller 00:50:29 I think the trend we are on now, the trajectory we’re on right now where we are seeing certain types of tool being adopted very quickly, I think a lot of the build internal tools is sort of the easiest to adopt because I think it’s the one that carries largely the less risk. It’s not being exposed to your customers and it’s not also, usually not a critical part of a data flow, etc. right? But we’re also beginning to see these tools like Zapier and Make making their way to enterprise and actually being adopted by really large customers that are running very large workflows through these no-code systems. And I think we’re generally seeing, which often happens in enterprise, it tends to not be the quickest early adopters, but we are seeing sort of a continuing move forward of adopting more and more of these types of software.

Andreas Møller 00:51:17 Because I think for most of them, they see the values there, right? The easier it is to automate something, the easier it is to set up and build, essentially the easier it is to manage for last enterprise as well. So we are seeing kind of a steady trend towards more and more adoption of these services, and I think that’ll continue. I absolutely believe that we’ll start seeing the first enterprise companies whose entire products are built on a no-code stack. And if not maybe entire, then at least the majority of the stack will be built in, in a no-code solution.

Brijesh Ammanath 00:51:50 Interesting times. We’ve covered a lot of ground over there, and as we wrap up a couple of questions, was there anything we missed that you’d like to mention?

Andreas Møller 00:51:59 No, I think we’ve covered it pretty well. I think I obviously want to say that for anyone out there that is interested in trying Toddle, it’s completely free to sign up and you can also deploy your software and share it with anyone, anything you build in Toddle without having to go on a paid plan. So I would encourage everyone to go and try that and see how far this world of no-code has actually come, especially if we have some older, more seasoned engineers there that’s tried some of the earlier generation visual programming languages out there.

Brijesh Ammanath 00:52:30 If people want to find out more about what you’re up to, where can they go?

Andreas Møller 00:52:34 Yeah, so definitely check out Toddle.dev, T-O-D-D-L-E.dev, our website, and that’s where you can also go and sign up. We are also very active on Twitter at Toddle dev, and I would also recommend checking out our YouTube channel. We got a lot of content on how to start building with Toddle. We specially have a playlist in a course called First Week in Toddle. So if you’re just starting out and have no idea how it works, that’s a really good place to sort of start learning how to use this tool.

Brijesh Ammanath 00:53:03 Thank you, Andreas, for coming on the show. It’s been a real pleasure. This is Brijesh Ammanath for Software Engineering Radio. Thank you for listening.

[End of Audio]

Tagged as:
Join the discussion

More from this show

Menu

Recent posts