Noel: Yeah, hello. Welcome to PodRocket. My name's Noel. Today, I am joined by our Arpit Mohan, who is the Co-founder and CTO of Appsmith. How's it going, Arpit? Arpit Mohan: Hi, Noel. Super excited to be here. I'm very well and glad to be talking with you today. Noel: Awesome, awesome. Yeah. So I know we can start wherever you think makes the most sense. But just tell us a little bit about you and your background to get us rolling. Arpit Mohan: Right. So I'm a engineer, and I'm a software engineer, that's how I end up defining myself. And so I've been working professionally in the industry for about, God, has it been 13 years now? So it's been a little bit of time that I've been around. And for a good part of the previous decade, I've done multiple startups. I've primarily worked in and around startups largely. And this has given me the opportunity to work with a lot of different products, seen a lot of different industries, ranging from AI, FinTech, telecom, mobile gaming. And this time around with... You know? I'm working on Appsmith, which is a low-code application builder platform, it's an open source project. And yeah, with Appsmith, I get the option to work on an open source project, and I get to work on a developer platform for the first time, so which is super, super exciting. Noel: Nice, nice. We like dev tools at LogRocket. That's what we're all about. Yeah, so tell us about it. Arpit Mohan: Yes. Noel: Absolutely. You said it's like an open source app building platform, is that right? Arpit Mohan: Yes. It's an open source. I think the industry term now is low-code. Noel: Gotcha. Arpit Mohan: And so it's an open source application building platform, so where users can drag and drop UI elements onto a screen, position them however they wish to, connect them to any API, private or public API, any database that they're running, MySQL, Postgre, whatever, and just simply publish their web app. And it's a great way to build a lot of the admin panels, dashboards, a lot of custom tools that every product team, every growing team requires just to keep the business and the engines running. Arpit Mohan: And the reason that we started out with Appsmith was by trade or by education, I'm a distributed systems engineer. So I've spent a lot of time working in Java, Golang, and Node.js. So while I can manage servers, like lots of servers, I can manage databases, for the life of me, HTML and CSS has always eluded me. That is a skillset that I'm not very good at, and that's where we ended up starting Appsmith, as well. Because I believe that there are a lot of other engineers, as well, who need to be building these dashboards, these panels, as well, but they may or may not be as comfortable using Bootstrap, React Admin, or any other material UI solutions out there. And that's why we ended up building Appsmith, to ease the pain, and make it super, super simple to get up and running with... Well, with something like this. Noel: Gotcha, gotcha. So just for our listeners, what is the output of Appsmith? Is it web apps? Is it like mobile native stuff? Like what are you building? Arpit Mohan: Oh. Yeah. So once you build an app on Appsmith and you click the deploy button, which is actually going live with, it's a web app today. And so you can share the link with your team or anybody else who needs to use the admin panels, so we have authentication or security built in. So the way you invite somebody to Google Doc is the same way that you would invite somebody to your Appsmith app. So because we deal with a lot of databases or private APIs, so everything in Appsmith is private by default. So by default, only you can ever see your app. Everybody else, even if they have the link, they'll get a 404 because they're not invited to it. Arpit Mohan: And on the flip side, if there is any reason that you wish to publish a web app publicly on the public internet, as well, like a Google Doc, you can always make it publicly readable. So that link or that webpage is then accessible as if you would access any other SaaS application itself. Noel: Gotcha, gotcha. Yeah, so I think it's a bit of a paradigm shift probably for most web devs, and when they think about building and deploying a little app. Let's see. So if I build and deploy an Appsmith app, does that have to go to infrastructure that you guys are hosting? Is that the default? Arpit Mohan: No. So we ship a Docker container, which you can run on your own easy to instance, Azure, VM, et cetera. That has the entire Appsmith engine running. And all the apps that you build, you can literally just do it on your laptop if there's something that you want to do personally, or you can run it inside your VPN or inside your firewall itself if it's within your team. And so none of these apps are... So while Appsmith has a cloud hosting platform, which you can definitely leverage, where we manage and run the entire infrastructure of platform, users can literally just download one single Docker container and run it on their own system. And all these apps are powered by the Appsmith engine, which is running in the Docker container. And yeah, and that's how you get all the shareable links, you get all the authentication and other features that are powered by the Appsmith engine. Noel: Gotcha. So what is the Appsmith engine all running? Like is that off layer the primary server piece? Is most of the other stuff just a front-end web server? Or is there other back end stuff that the engine is running? Arpit Mohan: Yeah. So there's actually a bunch of stuff that's running inside the engine. So when an Appsmith app is built, so there is no HTML, or CSS code, or JS code that is generated underneath the hood. So we don't do any sort of code generation. All users are really doing underneath the hood is creating a configuration, a large JSON configuration of which the Appsmith engine at run time infers and then renders the UI, the HTML CSS that the browser requires. So this translation from the JSON configuration to the HTML CSS is performed by the Appsmith engine. And the Appsmith engine, that's obviously one of the primary things that it does. Arpit Mohan: And then because the engine, it's because we have an engine, it also does a lot of other things, like you said. You know? Authentication, security. If you are making an invocation to an SQL database or a Mongo database, all these DB calls or API calls are not initiated through the browser, through the user's browser or the client browser, because that becomes a security risk. Because if you have to fetch data from an SQL database, you need credentials. And if these credentials get exposed to the client browser, your database is at risk. So all of this is these credentials are stored privately in the Appsmith engine, and the engine, which is running on the server is the one that actually executes the SQL query. So you never have to plug holes in your firewall to expose your database to the public internet. You can literally have it the way you would run any other web app is you'd host your container inside your firewall, and all you're really doing is just exposing [inaudible 00:08:38] to the public world and just get access to it. Noel: Nice. Just as a technical curiosity, what language is that handoff logic in, where the frontend needs to make a query that requires a SQL query, for example? Arpit Mohan: Right. So the frontend is completely React. So we are a huge proponent of React, so that's what the entire frontend [inaudible 00:09:05] logic is. That's written in React. The actual query executions, the DBO, the the API query executions that is written in Java Spring. So we use the newer version of Reactive Spring, which is called WebFlux. So it brings in all the niceties of Node.js, of being non-blocking in nature, of us being able to write reactive code while still leveraging multiple cores and getting the stability and the scalability that Java provides. Java, by the way, is a absolute beast of a language, so all the stability that Java provides. So yeah, so and the backing database where all this configuration is stored is MongoDB. So Mongo DB's our DB of choice, so it's React, Java, and Mongo. Noel: Gotcha. So is Mongo where those configuration files live that inform- Arpit Mohan: Right. Noel: ... how that frontend gets build? Are those saved in Mongo? Arpit Mohan: Yeah. Noel: Gotcha. Arpit Mohan: Yes, exactly, exactly. Noel: Gotcha. So and this is to paint a more full picture here. Say I have UI elements that are conditional, like based on the... I don't know, if the user is in North America or elsewhere in the world, as an example, how does the output, I guess how does that... Like say I change some user property, how would I have that of proliferate through the app and change how views are entered? Is that stored in the database ever, or is that just at render time those decisions are made? Arpit Mohan: Right. So in Appsmith, everywhere that you can write English, so you can also write JavaScript. So any button, any UI, any table, anything and everything can be configured at runtime by a JavaScript condition. So you can say that Noel sits in North America, so show him maybe a red and white background, but Arpit sits in Belgium, so show him a yellow and black background. So you can have this conditionally as a JavaScript code. You can just write that, where you pick the browser location and just determine what the background color is. Arpit Mohan: In addition to that, because we are a developer platform and a developer tool, we also ship with an entire CodeMirror, editor, as well. So with Async, Await, Promises, et cetera, so you can leverage nearly everything that ES6 provides. So we are, I think, close to supporting the ECMAScript completely. So anything that you can, that would be supported in ViaScore or modern browsers, you can actually write that entire logic in Appsmith, in the Appsmith editor, as well. And you can control just about any property that you wish to control. Arpit Mohan: And so it translates to a much easier way of building a lot of complicated applications where you want different UI elements to show for different users, you might want to hide something for maybe a non-admin user, you might want to control the data itself, so on and so forth. So it allows users to rise above a simple CRUD app. So a simple CRUD app, the first level would be to just be able to do CRUD operations. And by here, CRUD, when I say, it mean create, read, update, delete operations. But you can then go one level up and start building more complicated workflows and say that because it's all JavaScript on the UI, you can control anything via JavaScript. Noel: Yeah, nice, nice. Very cool. We touched on it briefly there, but can you talk a little bit more about the developer experience? Like what's this like if you're a dev working on an app built in Appsmith? Arpit Mohan: So just to clarify, you're asking about a developer building an app on Appsmith? Noel: Yeah. Like what's the developer experience like? Like say, you know? Arpit Mohan: Okay. Noel: Like say, I'm in there, I'm editing how stuff looks or how behavior changes and I save it. How do I work on my Appsmith app? Arpit Mohan: Right. Okay. So yeah, so in order to get up and running with Appsmith, like I said, you just start a Docker container on either your local machine or an EC2 machine and just go to that IP. By default, you start. You know? We'll ask you for an admin login, so that's the first login, which is an administrator login. And you are literally just dropped into your first application itself. We have a bunch of templates you can derive from or fork from. But you know? If you're that kind of an artist who loves the blank page, you can start with that. Arpit Mohan: The first thing that we've seen a lot of users do is drag and drop UI elements to get your UI, or get a skeleton of the UI, where you want a table in a certain place, a button on the top, or text scale on the top, so on and so forth. The next thing that you would probably do is connect this Appsmith instance to your database or to your REST API. And that involves just feeding in your SQL credentials, your Mongo credentials, or your API. If you have a private API, maybe some header parameters, so on and so forth. Arpit Mohan: And by and it's a very postman like experience. So for the API, for Mongo, again, it's a very consistent, very, you can write raw SQL queries and you can, again, control the query, how you're constructing it. Because like I said, because absolute allows you to write JavaScript wherever you can write English, you can also intersperse JavaScript inside your SQL query. So I can say, "Select start from users where ID=2," and then I can have a conditional, a JavaScript conditional, which says, "If user in North America, ID, return 1, elsewhere, return 2." So you can conditionally return different data, and that's a big, big superpower. Because at run time, the JavaScript engine, sorry, the Appsmith engine will translate this to a valid SQL query and then execute it, send it to your database. Noel: Gotcha. So you said the backend isn't running Java as script though, right? So is that JS executed on the client? The client sends up a value to the server, the server- Arpit Mohan: Yeah. Noel: ... puts that value into the SQL query, is that what ends up happening? Arpit Mohan: Yes, exactly, exactly. Noel: Gotcha. Arpit Mohan: That's absolutely perfectly it. Because so at run time, the browser client only sends the evaluated values. Like the browser evaluates what the JavaScript value would be, return value would be, and just sends it to the server and says, "There were three parameters in this function. Parameter one is this, two is this, three is this." And the server knows which function you're talking about, so the function itself is never exposed to the client browser again. So again, as an end user or as a random user, you will never see what the SQL query is, or you'll never see... You'll just know that a query of ID 1, 2, 3 was asked to be executed with parameters... You know? P1, P2, P3. And so this server is the one that just puts it all together, replaces whatever needs to be replaced, sanitizes everything, ensures there's no excesses or anything funny happening, and then sends it to your database for execution. Noel: Got it, got it. Noel: Yeah. I'm considering the security implications of this. So say I'm a developer and I'm writing, I'm setting up logic like this, where I am returning records to a user based on the output of one of those JavaScript queries, right? So I say like, "Show me the," I don't know, "The records where the user ID is bleh," like is the current user ID. Would that be exploitable by the frontend because someone could go in and modify what value ends up getting sent up there, and how do you solve that problem? Arpit Mohan: Right. So as an end user, so in the deployed mode of the application, so in the deployed mode, the JavaScript query itself, again, because it is just executed by the Appsmith engine, running on the renderer engine, if you will, on the browser front, so there is no explicit JavaScript that you can see in the... You know? You go to your sources, or you look at the JavaScript console, or et cetera, you'll actually never see any of this JavaScript. Because it was all part of like one big JSON configuration that came at the beginning and which the renderer engine passed. So as an end user, there is a nearly zero chances that this JavaScript can be modified. I mean, you can't modify it, rather, unless it's returned by the server itself. So at run time, you can't modify this JavaScript, you can't modify what it evaluates to. You can literally just... In the worst case, you can open the network console and you can see that, oh, these are the three outputs of a couple of things that I did. So that's pretty much what you can do. But you can't really modify it, or do anything to it. Noel: I guess, so what's preventing? Again, maybe there's a simple use case for this. But say someone designs an app where the user ID is being passed up in the request and then used in a SQL query upstream to fetch records back. What's stopping me from modifying the request? Or I see the request go through with my user ID, user ID 2, and they're like, "I want to see who, what's user ID 3's got." I modify the network request, put a three in there, and send it up to the engine again. Does that work, or is there some mechanism that's preventing that from happening? Arpit Mohan: So technically, yes, it'll end up working. Like if you literally copy the network console and you execute a call with different parameters. So you know? In your terminal, or in postman, or whatever. So you can technically change what the server is executing. Arpit Mohan: And a couple of things that we recommend to app developers to ensure that this does not happen is A, obviously, either if the data is very sensitive or et cetera, then you ensure that the app is not accessible itself to outside your team. So share it with people that actually need to use the app and don't make it necessarily publicly available. That's one. Arpit Mohan: The other is we also have you can add checks where you can say that... You know? So we also expose the Appsmith user object. So you can compare maybe the email ID with the ID itself. So you can have a check. So even if you pass an ID2, or you change any one of the function parameters, and you say, "Oh, you know what? Instead of ID1, let's pass ID2." You know? In your SQL query itself, you can have a check that says, "Oh, you know? The email ID should match with..." Or you can have a condition over there. You can add some of these conditions that the user cannot modify- Noel: Right. Arpit Mohan: ... because it comes from your session, it comes from your login. It says- Noel: It's in the back, it's on the back end. Like it's saved. Arpit Mohan: Yeah. So you are deriving it from a session variable or you're deriving it from there. So it's possible for you to ensure that that does not happen. Noel: Gotcha. Arpit Mohan: And the third thing that we recommend people is to, or people users who have a much higher security barrier, if you are a FinTech company, or if you are a health tech company, et cetera, is to secure the API or the database through JWT or through an OAuth 2.0 token itself, which Appsmith will transparently pass. So that token will never be exposed to the client. It's just stamped on by the server before it is sent out. So a lot of FinTech or health tech teams end up using OAuth 2.0 Or JWT tokens for stamping with the user's log in token, and that's how they verify are you allowed to execute this query? And they have a couple of checks and balances at their end as well before the query actually gets executed in their database, or their GraphQL, or their API servers. Noel: Gotcha, gotcha. That makes sense to me. So in that third step there of using a token of some kind, is that paired with the second case of then in the app server, like when I'm building the SQL queries and I reference the user object, like is that just building on that notion? Or is there some other step that I'm missing where that token ends up getting sent all the way to the client and then back up to the server? Because I would think you'd still need... Like if the Appsmith app is what's in charge of filter, like instructing how to write a SQL query, it's still going to need to know that this user is actually authenticated to make a query of this form. Does that make sense? Arpit Mohan: So, yeah. So Appsmith is basically executing any query that you've written as a user. So if you end up writing, let's say, a query without a WHERE clause, or without that doesn't take any parameters, Appsmith will just blindly execute it. So as a developer, you still have to... Because it's a developer platform, Appsmith gives some guard rails, but as a developer, if you don't follow some of these dev practices around am I writing the right query? Am I opening myself up SQL injection? By default, Appsmith uses prepared statements, but you have the option to turn it off. So but if you're turning it off, you're opening yourself up to SQL injection, so on and so forth. So that's one aspect of it. So as a developer, you still have to, you build an app the way you would build any other web app. You know? A Rails, or a Node.js app that you were building anyways. Arpit Mohan: To your second point, the Appsmith user object has a bunch of details. You know? Your name, your login name, your email ID, et cetera, so on and so forth. There are a few things that the server also stores against your login session, the JWT, or the ID token being one of them. And querying, or using, or stamping that ID token, or sending that along with your query is just a matter of just using the $Appsmith ID token. That's all that you really need to put in somewhere in your query. The moment the Appsmith server sees this keyword, this environment variable, it just substitutes it with the user's ID token and then just sends it out. So you can use it in a REST API header, you can use it in your SQL query itself, you can use it anywhere and everywhere. It's just that that ID token is never exposed to the client. So the client will only ever see a $Appsmith ID token. That's all that, even including an end user. End user will also never be able to modify this. Noel: Gotcha, gotcha. Yeah, that, I guess, yeah, yeah. Having a user ID object that's only modifiable and accessible by the server I think answers that- Arpit Mohan: Yeah. Noel: ... authentication question that I was- Arpit Mohan: Yeah. Noel: ... chewing on a little bit there. Emily: Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcast. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers, so check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. Emily: All right. Back to the show. Noel: I guess my only other big question on this front of querying data and stuff is could you guide me, like walk me through an example of say I had a button that I wanted to... Like a user clicks this button, it increments a global counter that everyone sees, like everyone's watching for updates on this. How would I wire something like that up? Arpit Mohan: Great question. This is not something Appsmith supports yet. This is on our roadmap. We're basically doing WebSockets where you publish some data and other users on that page automatically see the updated information. As of today, you would do it maybe with a web app where you would store the incremented counter in your SQL [inaudible 00:27:09], wherever else, in some backend database, and on refresh, every user will see the updated value. So everybody is pulling the data, the server doesn't push anything the way you would do a server-side event or a WebSocket for that matter. Noel: Gotcha. Could you set up a Golang- Arpit Mohan: This is on a [inaudible 00:27:26]- Noel: ... or something, like every 10 seconds? Like is that possible? Arpit Mohan: Oh, yeah. That, that you can do. That you can. Noel: Gotcha. Arpit Mohan: You can set. And because JavaScript, full browser JS is available, you can just say, "Set interval," and call the- Noel: Yeah. Arpit Mohan: ... the unction again, the query again. Noel: Mm-hmm. Arpit Mohan: And that'll just keep... So a couple of people set up their televisions or with the monitoring systems and dashboards. Noel: Mm-hmm. Arpit Mohan: So they just put it up on the television with a set interval of five minutes. Noel: Cool. Arpit Mohan: So the dashboard just keeps getting refreshed, so you're just pulling for new data. Noel: Nice, nice. This is kind of changing gears a bit here, but what have some of the challenges that you guys have faced around building a platform built on open source? Has that been difficult in any respect? Arpit Mohan: I would say it's been different. Because traditionally, historically I've almost always exclusively worked on closed source projects. And shifting gears to building an open source project, building in the open, building in public, that was something that I had to learn, unlearn some of the previous practices, learn new ones. And I think the biggest one for me was whenever we work on any closed source project or a closed source product, we keep everything very, very secret. And at the code, our issues, our bugs, future enhancements, so on and so forth, right? And opening this up to the entire world to see at first felt like people will know all the bugs we have. People will know how crappy our code is, or you know? So there's always this vulnerability that you're exposing yourself to the entire world, and that was something that took, at least me, personally, a while to get over, get over that hump. Arpit Mohan: But over a period of time, I came to realize that building in public is one of the best things that we did. Because the open source community and the community at Appsmith that we've ended up building has been incredible. People have been very forgiving of our mistakes. We've obviously made mistakes in our engineering, in our product decisions. And people have been very forgiving of our mistakes and actually shown us better ways to do stuff. You know? Whenever we made a mistake, people are like, "Oh, you know what? It happens. Just learn from this, move on from here." In addition to that, they've contributed a lot towards ideas about where they would like see the product move, the direction that they would move in, so we get a lot of product insights from the community. Arpit Mohan: And yeah, and largely overall, just our code got better. Like when we open sourced everything, our code just automatically got better. Because a little part inside us, that lizard engineer as I would call it, that vulnerability, like you want to write test cases. You want to ensure that if your name is out there publicly attached to this code base, it better be the best thing that you've written because all your future roles, everybody, you're going to look back and see that, "Hey, I wrote that code." And so our test coverage became better, our design decisions became better just because we had to do it in the open. Noel: Gotcha. Nice. Arpit Mohan: Yeah. Noel: Nice. Very cool. Yeah. Who have been the most common users for Appsmith? Like what kinds of apps do you see people writing? Arpit Mohan: Right. So we see a lot of, I mean, one of the most common use cases, if you will, or the apps that we see are things like customer support dashboard, something that connects to Zendesk to pull your tickets, and then connects to your orders database, as well, and your user database as well, and shows it all in a single screen. So a customer support dashboard like that with some workflows here and there. User management systems, especially KYC are loyal customer systems, where users need to be approved or their plans need to be changed, so on and so forth. So user management system. So these are a couple of some of the most popular use cases. Arpit Mohan: Although, we have a very broad usage. You know? People host us on Raspberry Pi right up to clusters of servers on EC2. While we have a very broad range, I think the sweet spot for us has always been SaaS companies or products that have a lot of operations. You know? Overheads, or operations, or large operations teams. Because that's when you get, you need to build a lot of admin panels, a lot of tools just to keep the entire operations team on the single page and running together. Noel: Gotcha. Awesome, awesome. Yeah, like internal tools like that seem like a pretty logical use case. Like you have these [inaudible 00:32:49]- Arpit Mohan: Yeah. Noel: ... technical people, but they don't want to spin up and maintain another web app. Like okay, we can do, find something that does some of that lifting for us on the frontend, point it to the backends, let people manage their data. Arpit Mohan: Exactly. Exactly. Noel: Nice. Awesome, awesome. Noel: Yeah. We talked a little bit about potential features, but what are your guys' big next steps? What are you working on now at Appsmith? Arpit Mohan: Right. So over the next few quarters, or over the next year, if I will, one of the things that we are obviously focusing on very heavily is on stability and improving the performance of the apps that are built. So by default, we want apps to be faster, and we want it to be more stable so that people can start relying on Appsmith a lot more and a lot more confidently. So stability and performance is definitely one of the big areas that we're working on. Arpit Mohan: A couple of the other areas that we're working on is improving our mobile responsiveness. Today, Appsmith is largely geared for desktop web, but not really for mobile web or native mobile, so that's another big push that we making in that particular direction. Arpit Mohan: And the third is supporting a lot more use cases around being able to handle larger amounts of data so that there are a lot of users who want to do... So there are a lot of users between basic charting and a Bi system like Tableau. So but there's a big gap between these use cases, so we want to support more users who want to do a bunch of stuff around handling and modifying this data within Appsmith. Noel: Awesome, awesome. Yeah. Are there any components of Appsmith that are not open source that you guys have been struggling, or you're thinking about open sourcing, or vice versa, like that are open source now that you're thinking about closing? Arpit Mohan: No. So definitely, this is a commitment we made to ourselves and to the community, that if we've open sourced something, we won't close it again. So open sourcing something, or anything for that matter, is a thought out decision for us. Arpit Mohan: So one of the things, the close source things that we do at Appsmith is so we have a commercial or a paid edition, as well, so which builds on top of the community edition and comes with additional security audit logs, multifactor authentication, so on and so forth. So that code base is, or those plugins or those extension points, are closed source. As of right now, we are not really going to open source. That's not on the cards. Arpit Mohan: There are a couple of things though, that I would like to spin out of Appsmith, from the Appsmith code base and publish it just as a library, like a separate library. I think the biggest one for me was a call parser in Java. Like I just, for the life of me, couldn't find a good call parser, and we ended up writing one in Java for ourselves. So that's something. Right now, it's like embedded. I mean, it's inside a class file somewhere in the code base. But I would love to just take it out as publish it as a secured library or SDK which everybody can use. Noel: Nice, nice. That makes sense. Cool. Noel: Yeah, I think I've got a pretty good handle then. Noel: Yeah. I guess, yeah, for context, for everyone listening, in our preparation for this podcast, as well, yeah, Arpit came, and we were talking a little bit about managing microservices, as well. Is that an area you've been thinking about a lot recently? Arpit Mohan: So Appsmith is the first monolithic system I've ever worked at. So till date, I've almost always worked on microservices and web scale systems. So in one of my previous roles, I was working on leading the team to design and deploy a system that did 30 million transactions a day, it was a telecom system. So I've almost always operated in such distributed systems. Arpit Mohan: But coming to Appsmith, we made everything monolithic, and this was a complete 180-degree turn from what I usually do. And a couple of reasons for that. The first is having microservices would mean that as a user of Appsmith or a developer on top of Appsmith, you'd then have to just the maintenance overhead of any distributed systems is multifold. So just having two services or three services does not mean it's twice the effort. I think it's eight times the effort just to get, ensure that everything is running, nothing is dying on you, so on and so forth. So that's the first. We wanted the install experience, the maintenance experience for Appsmith and self-hosted scenarios to be very, very simple, so that's why we made it monolithic. Arpit Mohan: The other one was for purely for performance reasons. So if I do not have to go over the network, I don't have to talk to five different services in order to accumulate the data that the user needs, by default, we'll be a little more performant, a little more snappier for the user. Arpit Mohan: And the last bit was I would say just the ease of deploying. So while we support Kubernetes and we support other installation targets, and we also support clustering, as well. Like if you actually reach a scale where you need to cluster, Appsmith can be clustered, and we help users do that as well. That's something that we don't generally recommend as the first use case. We expect people, or we tell users that, "You know? Get to a point where you have about 200, 250 odd users on your 4 GB instance, and then let's talk about scaling." Because anything below that, it just makes no sense for users. Whether it's Appsmith users, or just normal web app, or SaaS developers to actually worry about a distributed system. Like one single Java JAR, or one single Golang binary, or whatever it is, Node.js on the 4 GB or 8 GB machine written correctly will go of very, very long way. So I'm generally of the opinion that, at least for startups, there are a lot of, plenty problems that you probably have when you start doing a product, distributed systems shouldn't be one of them. Noel: Yeah, yeah. Gotcha. I think a lot of people have marched into that camp over the last five or so years. Like that seems to be a trend. Would you agree? Arpit Mohan: I'm not so sure I agree with that. Because looking at the popularity of Kubernetes, so Kubernetes being an absolute beast of a product, like a lot of respect for the product and the developers, et cetera. But at the end of the day, it's really complicated. It's complex, it's complex to maintain that cluster, to run the cluster, et cetera. And the number of people who've started to use Kubernetes for running their blogs, for running their first, MVP of their startup product or the SaaS product has always amazed me. That why are you wrangling your head around Kubernetes and its configurations, even you're not at that scale? Like it's really, really relevant if you are at a Google scale. But if you're not Google scale or you're not even planning to get there anytime soon, there's no reason for using Kubernetes. Arpit Mohan: And that's why I feel that I'm not so sure I agree with you. But maybe that's just a bias because I'm just seeing the other side of this coin, where I see a lot of people just saying, "Hey, I want to use Kubernetes. I want to learn Kubernetes," and my first question to them is, "Why?" Like- Noel: Yeah. Yeah. Do you find usage, like the usage of Kubernetes, in your head, is that synonymous with microservices? Arpit Mohan: I would say that if... Yes, I would say yes. Because if you're using Kubernetes to run a single pod, then I mean, it's just like why are you even doing that? Noel: Why? Right. Arpit Mohan: You know? Unless you're running like multiple pods, you're trying to scale out your pods, you're running five services, services on it, I don't think it makes a lot of sense for you to even be running on Kubernetes. You shouldn't be touching that product at all. Noel: Mm-hmm. Arpit Mohan: That product's not for you. Noel: Gotcha. Arpit Mohan: All you should maybe be worried about is jus SCP-ing or Rsync-ing your binary to your server and just restarting your server Noel: Sure. Yeah, yeah. Arpit Mohan: Mm-hmm. Noel: I guess I'd always assumed, I don't really have any data to back this up. But I had the impression that there were people who were using Kubernetes for their small to mid-size projects, but they wouldn't or they would never even argue that they really have a microservices architecture, but they're using it for auto scaling and ensuring that like, "And my database is here," and they're just using it for the orchestration piece, but of managing a much more like centralized, monolithic app that maybe is starting to need a little bit of auto scaling and stuff like that. Do you think that that is not very common? Arpit Mohan: Well, yeah. Actually, I would say that I have seen quite a few people. In fact, Appsmith supports Kubernetes as an installation target and that's pretty much what we do. We don't really break it out into five different pieces. It's just we auto scale it out and we scale it back in if required. So yeah, so a lot of people just use it for cluster management or just cluster scheduling, which I think is fine. There itself, again, I personally, but maybe this is just me coming in from because I knew a world before Kubernetes, so maybe I'm just comfortable with that world and I haven't become as comfortable yet with Kubernetes. You know? The same thing can happen with with Amazon's auto scale or any cloud provider's auto scale. You know? By clicking a button and not worrying about too many configurations that need to go in. Arpit Mohan: Yeah. So because with Kubernetes, again, you're just running those five nodes. Whether you have one part or you have 20 parts, you have like these five EC2 instances that are running your ETS cluster or your Kubernetes cluster. And in case you need to scale down your EC2 instances or scale down your nodes, now you're doing two levels of auto scale, where you're not just scaling your actual hardware infra, you're also... So you're doing two levels of scale, which I think just over-complicates the problem. Arpit Mohan: For the longest time, I would... You know? Again, to a lot of startup teams, my advice, I gently recommend that just deal with the simplest thing that you can, or do the fastest quickest, simplest thing that you understand and can do. Maybe with more newer age developers, or maybe somebody who's just gotten into the industry and they've been introduced to Kubernetes, for them EC2's auto scale would be like, "Oh, my God." Like, "What is this? I know how to do a cube CTL command. I don't know what EC2's auto scale is." And I totally understand that opinion. It's just that I believe the other way around. Noel: Yeah. I think that that's fair. Yeah. And yeah, I think that there's... Yeah, we're on the periphery of a couple different topics here. One is like- Arpit Mohan: Yeah. Noel: ... microservices, managing them in and of themselves, versus what is the correct level of abstraction in tooling cloud infrastructure? Like- Arpit Mohan: Right. T. Noel: ... they're very tightly coupled conversations, but they're different things- Arpit Mohan: Oh, definitely. Noel: ... a little bit, as well. Arpit Mohan: Definitely. Noel: Yeah, yeah. So yeah, I think I agree that a lot of people do end up over-tooling their simple apps. And I think the thing I'm curious about and I feel like there's still a large diversity of opinions, which I find interesting, is what is the correct stage of an app where you should be like, "Eh, let's just do the overhead work to get this built on top of Kubernetes, even if it's still like a monolith right now"? Like we have a database server, an app server, and maybe one or two other managed services, but we'll just set them up with Kubernetes, and then we can deploy it everywhere. And I feel like a lot of devs are in that camp, "Well, let's just do it that way so we're set up," versus, "Oh, let's not worry about that problem right away." Yeah. So it's interesting to hear an opinion, and I think I agree that like no, just use the hosting provider's thing as long as you can. Arpit Mohan: Yeah. Yeah. Noel: It'll be fine. Arpit Mohan: It's just build versus buy, and I just use whatever. Amazon doesn't charge you extra for auto scale, so just do that. And yeah, in general, just use whatever is the simplest thing you know how to use. So if you are comfortable with Ansible, then just go with Ansible, or Chef, or Puppet, or whatever it is. Noel: Nice, nice. What trends do you expect to continue happening in this domain? Do you think devs will keep reaching for tools like Kubernetes and like these highly, highly configurable, complex tools? Or do you think you see more and more people reaching for the off-the-shelf tooling that is simpler to configure? Arpit Mohan: I think there will always be a trend towards simplification, that's what I, or higher abstraction level. So, you know? Amazon came in and abstracted the hardware away. Kubernetes came in and starts to abstract Amazon away, or the virtual machines itself. I think some other service or some other abstraction layer is waiting to be built, which just abstracts Kubernetes away, and Kubernetes then becomes the de facto platform that everybody uses the way Amazon just uses KBM or hyper-visors underneath the hood, and nobody really cares about it. Similarly, I think there's an abstraction level that's waiting to be built. Arpit Mohan: Heroku was doing a great job, or Heroku is still doing like a great job at that layer. Where I just want to do a get push, just do it for me, don't worry, don't bother me too much about it. And I think the other cloud providers, Amazon, or Azure, or et cetera are just trying to catch up to that experience that Heroku provided 10 years ago. So I think Heroku did that 10 years ago, then there was a move towards complexity. I think the next decade will be defined by simplicity. Because we've gone the Kubernetes way, and now we're just going to build that next layer of simplicity again. Noel: Awesome, awesome, cool. Noel: Well, yeah, we're running a little bit low on time here. I want to make sure, is there anything else you want to plug or you want to talk about quick, send the listeners to? Arpit Mohan: No, nothing apart from definitely check out Appsmith on GitHub. So that's a we are a great community, we are a great repository, we're always looking for contributors. So yeah, apart from that, not really much else. Noel: Nice, nice. Yeah. We'll get a link in the show notes, as well, just so everybody's got one. Arpit Mohan: Oh, thank you. Noel: Cool. Cool. Well, yeah, thank you for taking some time to chat with me here, Arpit. It's been a pleasure. Arpit Mohan: Yeah. Thank you so much, Noel. It was an absolute pleasure chatting with you, and thank you so much for having me here today. Noel: Yeah, of course. Speaker 4: Thanks for listening to PodRocket. You can find us @PodRocketpod on Twitter. And don't forget to subscribe, rate, and review on Apple Podcasts. Thanks.