Debugging your apps in Appsmith with the Appsmith Debugger, part 2

Debugging your apps in Appsmith with the Appsmith Debugger, part 2

Debugging your apps in Appsmith with the Appsmith Debugger, part 2
Ayush Pahwa
 minutes ↗
Meet the sidekicks, Logs and Inspect Entity

The first part of this teardown helped you see how the Error pane can save you hours in debugging and build better internal apps. In this one, let’s meet two seemingly innocuous features that can give you debugging super-powers when used right.


The Logs pane shows you everything logged by Appsmith and, like Errors, in lockstep with the sequence of code execution in your build. Borrowing from the experience of showing logs in general—in the browser console, from a shell, or on your favorite IDE—the Logs pane has four views for specific debugging use cases.

Post_5.jpg (1920×1080)

All Logs

This view shows you all logs timestamped by when we saw them in your Appsmith session. Updated a widget’s property? Wrote a new action to your GraphQL datasource? Ran a JS Object to concat two queries? It all gets logged, including the errors you see in the Errors pane, in a separate view called Error Logs. You will see how that can be useful in a GIF, pun intended.

The All Logs view can be a little overwhelming, though, and a bit of work when you have been at your build for a while. For easier tracking of relevant logs, use one of the three options below.

Post_6.gif (1440×810)

Errors Logs

Everything you learned about the Errors pane applies to this view, too, but there’s more to this view. Here's a likely scenario to show that.

State #1

You have a button to reload a table, presumably to refresh the data from your datasource.

Condition #1

You use the Button property, onClick, which runs the query to fetch the latest data into the table.

Scenario #1

Your query fails.

- On just the Error pane

  • You see just the error for the failing query. Although helpful, it doesn’t offer context for the before and after of the error.

- On the Error Logs pane under Logs

  1. You see logs for the Button click and the executed onClick event .
  2. Because the onClick property is binded to queries and JS Objects, you see the ones that are successfully executed and those that fail.
Error_Logs__Appsmith.gif (1440×810)

The triaging in our example above is especially useful when you have nested queries, several dependent bindings, and a more complex workflow overall.

Console Logs

console.log_in_the_Editor__Appsmith.jpg (1920×1080)

Just introduced in the Debugger, console methods in Appsmith help you see statements for just JS Objects and JavaScript bindings so much better than in the browser sub-window.

Set points in your code that you want to log statements at, view tabular data, or see groups for repeated errors.

System Logs

Post_7.jpg (1920×1080)

Automatically tracking all your interactions with Appsmith during build, System Logs show a helpful trail of activity by descending order of timestamp, especially useful when you want to go back in time or pivot from a point of failure to everything that led to it.

They show up for different situations and interactions for the type of entity you are working with.

With widgets, you see a log when you

  • Drag-and-drop a new widget on the canvas.
  • Update the widget’s properties
    Updating a property also updates all its dependent properties which then show up in System Logs.
Dependent_properties_updates_in_system_logs__Appsmith.gif (1280×720)
For example, when you update the tableData property, you also see its dependent properties like selectedRowIndex, filters, triggeredRowIndex, and so on.
  • Trigger events with an end-user action.
Trigger_events_with_an_end-user_action__Appsmith.gif (1280×720)
For example, when you are using an end-user action to store a value with storeValue or when you want a click-action to trigger an operation like an update or delete and are using onClick, you see them show up in System Logs.
  • Delete a widget from the canvas

With actions, you see them when you

  • Create a new datasource or a query
  • Update query properties like queryName, queryBody, queryConfiguration, and queryProperties.
  • Execute a query
Execute_a_query.gif (1440×810)
This can be either from query pane, running a plain REST API query, a JS Object, or via a widget’s bindings.
  • Delete a query

With JS Objects, you’ll see system logs when you

  • Create and update code inside JS Objects
  • Execute JS Objects
Execute_JS_Objects.gif (1440×810)

Just like errors, system logs are native to entities and have four parts to them.

Parts_of_a_system_log_line__Appsmith.jpg (1920×1080)

The timestamp

Logged as your entities are created, updated and deleted, these little breadcrumbs help you track back from when the error occurred to when it was last A-Okay.

Timestamped_logs_in_System_Logs.gif (1440×810)

The message

Useful during build, the message of the log answers two questions— what were you doing with an entity—creating it, updating it, deleting it—and what happened with your action—success or failure.

  • With widgets, outside of CRUD information, you also see event-specific info like onClick and showAlert linked to those widgets.
  • Queries and JS Objects are straightforward with start and end points that indicate if they were updated, ran, and failed.

The source

Like errors, a system log has two parts to its source—the entity’s name.the type of entity, e.g., SELECT1.TABLE1.WIDGET.

Redirect_from_an_Inspect_Entity_sub-window.gif (1440×810)
👌🏽 Appsmith Experience plug

Clicking the source from the logs takes you to the associated entity anywhere in Appsmith, be it a widget, a query, or a JS Object. Noice!

The response

This doesn’t always show, but when it does, it can be useful confirmation of a binding working, a query running successfully, or a JS Object executing completely.

  • For widgets, you see which properties are updated when you are configuring them and how.
    Say you’re updating the text widget’s background property and you don’t see it change on the canvas. Track the log to the response for a quick confirmation of that and troubleshoot the canvas next.
  • For queries, you’ll see two different logs—the start of a query run and the status of its execution.
    The first type of log will show you configuration details of the query—helpful to verify if the config matches the request.        

    "body":"SELECT * FROM public."users" LIMIT 10;"

  • The second type will throw an error if the run fails. When the query runs successfully, it shows all the parameters that the query ran with and the time taken for the response.

	"response" : [...],
	"request" : {
		"actionId" "6321c1193668£71e£7caala2"
		"requestedAt" : 1663912830.640344
		"requestParams": {...}

  • With JS Objects, you see the response from the function as a JSON after an object is successfully run. This shows you how Appsmith handles the function while evaluating and running it and can be useful for spotting conflicts, undefined references, or troublesome variables.

Inspect Entity

Borrowing from a modern browser’s Inspect Element feature, Inspect Entity lets you see incoming and outgoing entities for any widget. These entities can be queries, JS Objects, or even other widgets.

Group_8480.png (1920×1080)
  • Incoming entities are those that fetch data from the datasource into the widget.
    For example, if the data on a table is populated by a Postgres query, you’ll see the query name under the Incoming entities column.
  • Outgoing entities are those that can specify the data that’s to be sent to the datasource in a typical CUD operation and then send it to your datasource.
    Say, a text widget is binded to a table's selectedRow property, you will see the text widget’s name under the Outgoing entities column.

The Inspect Entity pane lets you see dependencies for all your widgets on the canvas, especially useful if you have a medium-complex app with several widgets working off of each other. For example, when you have a parent widget or query that controls bindings on other dependent widgets---call them children widgets---, Inspect Entity can show you all those children when you click the parent and quickly take you to any one of them directly.

In combination with Errors, Logs and Inspect Entity round out the Debugger for several scenarios during build and save you hours in building an app end-users love. Try out the Debugger and let us know how you like it, what it's missing, and what we can improve. Our Discord is the best place for that feedback.

Debugging your app in Appsmith with the Appsmith Debugger, Part 1

Debugging your app in Appsmith with the Appsmith Debugger, Part 1

Debugging your app in Appsmith with the Appsmith Debugger, Part 1
Ayush Pahwa
 minutes ↗

That title is a tongue twister, innit? Almost.

Here’s a meme that isn’t. It’s just the painful truth.

Debugging_is_like_being_lost_in_a_deser.jpg (749×500)

There is no perfect code, so you know debugging is inevitable, but it’s still a chore and is as crushing often times as the meme claims it is.

But, while debugging is inevitable, making it painful is optional, especially when you have the Appsmith Debugger. We have claimed we champion developer experience as many times as we could before without being brazen about it. We think. So, we thought some more and said, “Let’s prove the claim, too.”

“Wait, wait. What is the Appsmith Debugger?”

In 2021, we shipped the Appsmith Debugger, a set of Chrome DevelTools-like features that have helped you investigate and resolve errors in Appsmith.

We recorded a video for it in a series about the Debugger, talked about it in our docs, and referenced it enough times to make you groan about our obsession with errors. If this is the first you are hearing of it, get on our Discord so we can tell you some more about it.

Why we did this

Browser dev tools are as helpful as a magnet when looking for iron fillings in a pristine haystack. To the untrained eye, they can be downright criminal, too.

Browser_debugger.jpeg (960×506)
Source: Reddit

Sure, sure, they nest groups of errors and there are separate tabs for the console and the debugger, but meh! There’s a sea of error messages, system logs, console logs, and then there’s you swimming in it.

Before we shipped the debugger, you saw,

  • errors inside a widget's Property pane that floated on your canvas which probably already had several widgets
  • the Editor’s Response pane, which clubbed legit responses with errors

The Debugger solved several of those problems.

Post_8.jpg (1920×1080)

What’s the Debugger have

Available on and our self-hosted release images, it can be called by toggling the debug icon—the one that looks like a bug—on the bottom-right corner of your Appsmith screen or with CTRL/CMD +D.

Inside the Debugger, live three panes, Errors, Logs, and Inspect Entity, each with their own uses. In the first part of this two part post, we will break the Error pane down for you and see how it can save you hours over browser dev tools in debugging.

If you would much rather just learn about Logs and Inspect Entity, bookmark this post. We will link to Part 2 in five days. :-)


Borrowing from a browser’s dev tools sub-window but improving on it radically, the Error pane lists all errors that we see when you are building inside Appsmith. Familiar examples include syntax errors from JavaScript bindings, reference errors from queries, and datatype mismatch errors.

Errors in the pane are specific to an Appsmith entity. Translated from Appsmithlish, it means you see helpful error messages about a faulting widget, a rogue query, or a stubborn JS Object.

Untitled.gif (1440×810)
Example of a faulting widget and the error beaconing it
Untitled.gif (1440×810)
A JS Object error

  • These errors get logged to the pane in lockstep with the sequence of code execution in Appsmith.
  • The Error pane is the default view when working with widgets—most noticeable if you have the Debugger sub-window resized as in the pictures in purple—so you know what’s going wrong and where in real-time.
  • The Editor's Error Pane is smarter. It doesn’t automatically switch to the Error pane—Response is the default on this screen—when an error occurs. Instead, the Debug icon lights up in red with a numeric notification that’s like a running ticker for the number of errors the Debugger sees with your queries or JS Objects. Click it to open the Error pane.
  • Every error you see in the pane follows a template with a few helpful pieces of info to help you debug.
image_high.jpeg (1920×1080)
Numbers on this image correspond to bullets below. Images in sub-bullets below show what the sub-bullet talks about.

The timestamp

Logged as your code executes or a value evaluates with your widgets, these little breadcrumbs help you track back from when the error occurred to when last it was A-Okay.

The issue

Depending on the error type, you will see a couple different kinds of issues.

  1. With widgets, you’ll see the faulting widget property’s name. An example of this is the commonplace The value at tableData is invalid, occurring when the property tableData expects an Array<Object> datatype but you have an Array<List> instead.
  2. With queries, you see more specific errors, often specific to the datasource you are running your queries to, often indicated by status codes returned by your failing requests.
  3. With JS Objects, we straight-up level with you about the parseability of your functions. Parseability probably isn’t a word, but you know what we mean.

The source

This has two parts to it—the entity’s name.the type of entity the troublesome one is, e.g., SELECT1.WIDGET. As is obvious and has been to you, SELECT1 is the entity’s name and WIDGET is the entity type.

👌🏾 Appsmith Experience plug: Clicking the source takes you to the faulting entity anywhere in Appsmith, be it a widget, a query, or a JS Object. Noice!

The message

This is the most helpful part of the message, beginning with Error and ending with a helpful bit of text or a number.

  1. Because widgets bind to queries or JS Objects using JavaScript, quite a few errors you see are the same as familiar JavaScript errors like SyntaxError or TypeError. Some other errors show is not defined. This is when a variable, a query, or a JS Object isn’t defined, but you have specified it in the Property pane.
  2. In the Editor, these messages go a step further and call out the line number in the editor that has the faulting code. For example, Line 2: Unrecognized token '$'. This type of message has three parts to it.
Post_9.jpg (1920×1080)

1. The type: Error

2. The string: relation “public.user” does not exit

3. The line number: Position 15

😻 Appsmith Experience plug: Clicking the message will open our in-app docs finder and run a helpful search to show you top docs matching the error.

Response from queries or bindings

This doesn’t always show, but when it does, it can show you helpful responses with query params or evaluated values of data bindings.

Post_10.jpg (1920×1080)
  1. With widgets, you’ll see the evaluated value from the bindings.
  2. With queries, you’ll see the payload from the API you are querying.

“How does all of this help?”

Consider two situations we have painfully drawn for you.

State #1

You have several queries and widgets on your way to a complete build.

Condition #1

You have nested queries inside JS Objects. Meaning, these queries are binded to multiple widgets via JavaScript transformations and have dependent parameters with each other.

Scenario #1

A query fails and returns an error.

Without the Appsmith Debugger

You decide to sift through the browser dev tools sub-window, trying to locate the faulty query in something that looks like ↓.

The_browser_console.png (1920×1080)

When you find the first problem query, you’re hoping against hope this is your patient zero.

  1. If so, congratulations aren’t quite in order yet. You’re still going to have to surgery the query to see what went wrong where.
  2. With browser tools, may you be lucky and find a fix in the first hour.

Most times, though, Murphy’s Law applies.

  1. Meaning, you will need to find the last problem query.
  2. Repeat steps #1 and #2 with all the sub-steps in between

If you have a friend who’s on Appsmith, you hear them say, “Good morning. Do you have a ready app? No? Try the Debugger. 🙄”

With the Appsmith Debugger

You see all the errors from all the failed queries In the Error pane and nothing else to crowd your investigation.

  1. You quickly scan by the type of errors.
  2. Errors are listed in the sequence of query execution.
Post_11.jpg (1920×1080)
So you can simply scroll to the first failed query, and investigate further.

  1. The error message tells you what failed with the params in which line, neatly indented neatly for you.

Don’t remember the query’s name? Pfft! We got it. Click the error message, and go right to the error source.

Trouble troubleshooting? Click the error message and find super-relevant docs in Appsmith’s doc finder.

At the end of it, you save a whole night’s hair-pulls, wake up bright and fresh, sip your coffee, and wonder why some people still use browser dev tools. 🤔 Maybe you should refer them to us.

State #2

You have the data from a REST API and the table for your dashboard, but you have left the chart for the very end. You are sensible like that. Charts are tricky things in general.

Condition #2

You have to bind the chart widget from Fusion Charts or one of our defaults with a query that should output the format Array<{ x: string, y: number Required }> as input to the widget. This will need JavaScript transformations.

Scenario #2

You get a datatype mismatch error.

Without the Appsmith Debugger

You toggle around the floating EXPECTED STRUCTURE, EXPECTED STRUCTURE - EXAMPLE, and EVALUATED VALUE panes to understand the chart widget’s configuration.

You have a JS Object for the transformation, so you now switch back and forth between the canvas and the JS Editor for each possible fix in the JS code.

  1. By now, you have console.loged your way to the browser tools sub-window. Magnet, meet Iron Fillings In A Haystack.
  2. Forgot the change you made to the JS Object five tries ago? Yeah, well, no System Logs, so what can you do, right? Maybe note each change on Sublime or VS Code from this point on.

With the Appsmith Debugger

Post_12.jpg (1920×1080)

Right after you run the transformation, you see the floating-pane-that-we-don’t have-a-name-for-yet show you some red and the Error pane light up with all your errors, timestamped and sequenced by the order of code execution.

  1. You see the type of error and the evaluated value for the faulting entity. Stick to this without worrying about the unnamed floating pane.
  2. Your query has trouble getting a response from your datasource, so you see that error, but hey, you also see the binding failure of that same query with the widget.
  3. No hunting for the query or the widget you want to troubleshoot. One click from the Debugger and you are transported to the associated entity.
Debugger_with_click-actions__JS_Editor.jpg (1920×1080)

You see all the errors from the transformation in one pane with click-actions for each one of them.

Docs_finder_from_Response__Appsmith.gif (1440×810)

Error messages not enough? Click the error and choose, Browse code snippets, and voila! You now now search for the chart + the query right there and see some of our helpful docs.

Made it to here? Your life inside Appsmith is going to change.

Also, this is just part one of this two-part breakdown. What’s next?

Better than post-credits.

In part two, you'll meet the sidekicks, Logs and Inspect Entity

Meanwhile, here’s a few things you can do.

P.S.: We love you.

Appsmith hits 20000 Stars. How did we get here?

Appsmith hits 20000 Stars. How did we get here?

Appsmith hits 20000 Stars. How did we get here?
Rishabh Kaul
 minutes ↗

Day before yesterday we reached 20,000 Stars on Github. 

We’re excited by this number because of what it represents. 20,000 Stars is a milestone that puts us in the company of other exciting open source projects that we all use and love. 

It’s been a steady rise. Since our launching on Github in mid 2020, it’s taken us a little over 2 years to reach this milestone. In June last year, we wrote about our learnings while hitting 4500 Stars. Since then, we’ve gotten a 4.4x jump since. 

How did we get here?

There’s a big debate in the open source community around the value of Github Stars. One Stack Overflow question laments "GitHub Stars" is a very useful metric. But for *what*?

We look at Github Stars as an informal measure of popularity of an open source project. And so while there might exist popular projects with low Stars, projects with high Stars more often than not command some mindshare. 

So while we keep an eye on this metric, it’s definitely not something we lose sleep over. 

Our philosophy has been to focus on things that add value to developers worldwide and focus methodically initiatives that further that cause. And so here are the things we’ve been doing (with pride)

Committing (Code)

We’ve been shipping. A LOT. And it's getting noticed. The folks at OSSInsight have been tracking and ranking various open source projects. We've submitted the highest number of pull requests among all low code development platforms. What makes this more interesting (and exciting) is that the definition of a low code platform according to OSSInsight is quite broad, including companies like Hasura, Supabase, Strapi.

And Appsmith continues to lead this chart month over month. 

Our users are noticing this too.

In addition to new users discovering us from word of mouth, we’re also seeing a lot of existing users returning back to Appsmith citing how much better the platform has gotten since they last tried it.

Even though our primary aim has been to educate our users about new features releases, bug fixes and helping users create bettet software, we started noticing that a lot of developer media began picking up our updates. This was very exciting to observe. covered our version control, New Stack highlighted our OSS approach, JAXenter covered our JS Editor launch, and SD Times featured us not once, but twice as their Project of the Week (the second time was probably due to our fundraise). 

Retention over Acquisition

We made a conscious call in 2020 to focus on retention and user education over user acquisition. The good folks at Threado covered our early community-building efforts some time back

We believed as long as we served users via solving bugs, prioritizing features they asked for, and making ample content to help people get the most out of the platform, word of mouth would take care of acquisition. 

We launched our discourse community to create a Q&A type knowledgebase. In addition to helping our existing users and reducing load on our support team, it’s also becoming a growing source of organic traffic and bringing in new users (plausible data only from Apr 22) 

To increase retention, we also created Sample Apps, and Templates to help users understand product features better. While Templates enable a user to see a fully functional application that’s ready to be forked (like a dashboard or admin panel), Sample Apps have a narrower scope to help users perform a specific functions like How to implement a Search / Filter functionality in a Table with MongoDB as a datasource. This is in addition to the videos and blogs we’ve been regularly publishing around use-cases and investing in robust documentation. We’re slowly seeing the fruits of this from a new user acquisition perspective kick in because this type of content is also great for SEO. 

Highlighting Self Hosting

One of the early calls we made was to ensure that we made it easy for people to self-host Appsmith because that's how a lot of our users preferred using the platform. This is also reflected in our outreach efforts; you might see us plugging in links to our Github repo often (more so than website). The self host option is also prominently featured on our website's “hero section”.

Communicating across channels: Feature Updates, Opinions and Engaging Developers

We've been actively answering questions and sharing our feature releases on Reddit, Twitter, HackerNews and community forums of our integration partners. None of these channels individually bring a massive spike to traffic, but instead send a steady stream of consistent traffic to us every month and brings in a lot of new users to our Github repo. Like our July updates which is being received well from the Reddit community.

Word of Mouth 

While our team continues to actively monitor and post our opinions on these platforms, increasingly we’ve started noticing that our users have started talking about us. For example, user comments on HackerNews like these make our day. All in, across Github and our website, 3rd party forums are increasingly contributing anywhere from 4-6K unique hits a month across our websites and Github. 

A lot of our users are also writers, empowered by platforms like Medium or or Hashnode and many of them have started featuring us in tutorials or listicles. This has lead to a massive spike in traffic, and my hunch is increasingly becoming a big contributor to our star growth. 


For awareness, we had to be surgical. Instead of spending effort on SEO or ads, we decided to go after podcasts. Why? Laser focused target audience that resonates with the problem. Check. Organic backlinks. Check. Ample time to go deep into product, technology and how/why we’re building. Check. People who know what they’re talking about (our founders basically). Check. Till date we’ve recorded 15 podcasts (with 11 of them live) with an estimated cumulative 100K listens. All this in less than a 6 months. Check out Nikhil on JAMStack Radio or Arpit on Hanselminutes.  

Github Juice

Github is possibly the last true organic platform. We’ve benefitted immensely from Github’s organic traffic. We’re not quite sure how Github’s “trending” algorithm works, but we’ve been consistently been “trending” in a bunch of sub-topics like JavaScript, TypeScript, Projects from India. But this often ends up becoming a domino effect, where because we’ve been doing a lot of the things above, there are people who discover us and star us, which in turn makes us trend, bringing in further Stars.  

As a parting note, this is just the start. And we can’t wait to see what the future holds and we’ve got so many exciting features we’re working on (and yes bug fixes too). We’ll keep executing and serving our users. Do try out Appsmith incase you haven’t already or share it with developers in your team. Want to get more involved? Maybe contribute to the project or better still, join us if you want to be a part of an organization that is building something meaningful for developers worldwide.

February Round-up: Helm Charts, Product Updates, and Collabs
Monthly Round-up

February Round-up: Helm Charts, Product Updates, and Collabs

February Round-up: Helm Charts, Product Updates, and Collabs
Vihar Kurama
 minutes ↗
Monthly Round-up

If you’ve followed Appsmith for a while, you know that we can do a lot in 30 days! In the second month of 2022, we cleared a few bugs and created an all-new event called How Do I Do X, where many frequently asked questions live.

I am here to give you more deets; follow along!

Appsmith Support on K8s with Helm Charts

We’ve added support to deploy Appsmith on K8s using Helm charts. Deploying Appsmith on Kubernetes clusters has now become super-easy with Helm charts. If you have a cluster ready, you’re three commands away from your own Appsmith on k8s.

Read the complete documentation here!

To explain this feature in detail, we had Shri, one of our engineers, join us on a community call. Take a look:

Product Updates

New Entity Explorer**: We’ve shipped an all-new entity explorer that’ll help you navigate to any query or widget and give you an entire overview of all the application data. Here are the changes we’ve made:

  • We no longer show the entities from all the pages. Only entities pertaining to the specific page that the user is currently on will show up—performance improvements by writing better selectors and memoizing components.
  • Queries now have the same icon as the datasource and are sorted under the datasource.
  • We have a new section that shows all the queries and JS Objects. They are grouped and sorted by default.
  • The widgets section is expanded only on demand.
  • Action creation will now go via the Omnibar.
  • Bindings are no longer under the entity but are shown in a separate popover.

Here’s a screenshot:

pasted image 0.png
Mobile Responsive UI

Appsmith application dashboard, settings, and configurations are now mobile-compatible. With this, you can share apps, manage members and view your applications through any mobile device.

Here are a few screenshots:

CleanShot 2022-03-07 at 14.45.54@2x.png
New S3 Command

We added a new query to our S3 datasource that lets us delete multiple files at a time in given bucket storage. All you’ll need to do is input the bucket name and send the file names in an array separated by commas. Note that these inputs will also allow dynamic binding using the moustache operator from appsmith.

CleanShot 2022-02-28 at 12.06.52@2x.png
More keyboard control in Widgets

Internal tools usually deal with a massive amount of data. Hence having more keyboard control over all the widgets will save a considerable amount of time, especially while working with forms, widgets, and select-dropdowns.

With this update, you can navigate options inside the multi-select widget using general keyboard shortcuts.

  • Use Tab to focus the dropdown.
  • Enter Space key to open the dropdown
  • ArrowUp ArrowDown keys to navigate
  • Enter or Space to select an option
  • Enter or Space or ArrowRight to open submenu
  • ArrowLeft to close sub menu

Additionally, you can use these on input widgets as well:

  • Tab to focus
  • Enter to switch to editable mode
  • Esc to move out of editable mode
Support Body in GET API Requests

Now all HTTP methods support a body in the HTTP request. This feature adds another tab in the Rest API plugin called None. Users can use this to define HTTP requests that don't have a body. In the Body field, clicking on None will remove the content-type header, while clicking on RAW will keep any existing content-type header.

We also refactored the ApiEditorConstants to use enum values instead of arrays. It makes the code more readable and understandable in various places.

New Collaborations, Technical Content, Videos & Tutorials

Last month was crazy for all of us; we’ve published seven new blog posts and have successfully hosted four live events!

  • We built admin panels on SnowflakeDB, ArangoDB, MariaDB, MSSQL, Firestore, and Redis, all on Appsmith. Not just that, we have more coming soon; if you would like us to work on any new integration, feel free to reach us on Discord.
  • We created a fully authenticated internal application without writing any code, using Xano as the backend. Check out the full tutorial here to learn how we’ve made it.
  • Sathish Gandham, a frontend engineer focusing on UI performance at Appsmith, explains to us how How 40 Lines of Code Improved Our React App’s Performance by 70%; read the full blog here.
  • That’s not everything; we’ve collaborated with Cube to build a metrics dashboard on Appsmith live using Cube’s APIs as backend. Watch the full video here.
  • Confidence, our developer advocate was invited to Hasura’s Data and API Show to demo how one can build internal tools dashboards using GraphQL API and Appsmith. Watch the entire event here.

If you're curious about what we were up to, look no further and follow this link.

If you’re interested in using a database not listed on our website as an integration, please let us know about it by raising a PR on Github, and we will do our best to include it at the earliest.

Join our growing community on Discord, and follow us on Youtube and Twitter to stay up to date.

Engineering Diaries: How We Created a Google Sheets Integration for our Product

Engineering Diaries: How We Created a Google Sheets Integration for our Product

Engineering Diaries: How We Created a Google Sheets Integration for our Product
Vishnupriya Bhandaram
 minutes ↗
engineering diaries

Everything starts with a spreadsheet. Well, almost everything. Spreadsheets are the backbone of all business operations, whether budgeting, people management, expense management, organizing lists, etc. Spreadsheets often become the first choice for fledgling businesses, mainly owing to their versatility and flexibility. Little goes a long way with spreadsheets.

For a startup, smart utilization of available funds is critical, and Google Sheets often comes in handy to plan projects, analyze risks, report metrics, generate quotes and predict financial outcomes. Start-ups even use spreadsheets to keep track of client lists, investor lists, and more. So what’s the problem? Things can get messy once you work on it collaboratively or establish strict flows around maintaining a spreadsheet database. Data can get corrupted, and not knowing the latest version, too many changes by too many people who have access to the database and no admin control.

This is where the power of low-code can be melded with the power of spreadsheets. Turning an excel sheet into a web application is a great way to contain errors due to poor data management, allow for granular control, admin and user access, and these applications scale along with your business.

Today, it’s pretty easy to make an application from Google Sheets in record time. There are many low code and no-code tools out there that can help you do this, including Appsmith. In this blog, we will talk a bit about the Google Sheets integration on Appsmith, how we built the integration and all the things you can do with it.

Behind the Scenes

One of our colleagues, Nidhi Nair, worked on making this integration a possibility. Nidhi is a platform engineer at Appsmith and she joined Appsmith a little less than a year ago, and she enjoys the creative liberty to explore her ideas at Appsmith.

“It was possible to use Google Sheets on Appsmith even without our integration. Users could do this using the REST API plugin. However, it’s not the most convenient, and I found it to be unwieldy and something that every user couldn’t configure intuitively or easily,” says Nidhi.

The Google Sheets integration was created to simplify the interaction for end users. “We identified a set of actions that users would want to use Google Sheets for and optimized the way they interact with data in their sheets,” adds Nidhi. This meant not having to deal with cells and columns, but just arrays. “We defined the scope of the integration to be similar to that of a database. A single sheet was understood to be a table that we wanted to manipulate with the integration. We identified the relevant actions for this,” she says. Implementing this integration meant doing considerable research around how users interact with sheets. For us, reducing the friction for users was a key priority. “We introduced something called RowObjects in the integrations that makes sure that users don’t necessarily have to tinker with the data themselves,” says Nidhi.

Key Challenges

“We wanted to be able to support the DB integration style interaction and also allow users that want to work on it as an excel sheet to be able to continue to do so. This was a relatively easy solution because of how flexible our logic for these integrations is,” says Nidhi, adding that a user could say ‘get me rows 1-10’ and for the next page, ‘get me rows 11-20.’ But they can also do something like: ‘Get me cells D3:J8, and on the next page, get me D11:J16’ (or whatever other logic they would like to use). While this may sound trivial, having the liberty to navigate across the sheet at will means that they can organize their data separately from how it is consumed in Appsmith.

The biggest challenge in creating this integration was to use Appsmith credentials as a provider for all instances to make it easy. With this, users don't have to set up configuration on Google; Appsmith has already done that for them. Setting up the configuration on Google comes with painful scrutiny, and it’s not for everyone, especially for people who do not deal with tech. “Appsmith’s one-click approval makes it easier,” says Nidhi.

However, this has a downside; Google Sheets on self-hosted instances cannot be used unless they connect to Appsmith’s cloud API.

The engineering team is also working on and hopes to solve shortly for storing authentication on a per-user basis. This will allow users to access the part of the sheets they have access to and limit access to those they don't.

To read more about the roadmap for features, follow this link.

How to Use Google Sheets Integration on Appsmith

With Appsmith's inbuilt Google Sheet Integration Plugin, you can use any Google Sheet as a data source or a backend to build robust applications.

Set-up Google Sheets Plugin

  1. Create a new account on Appsmith (it’s free!), if you are already an existing login to your Appsmith account.
  2. Create a new application by clicking on the Create New button under the Appsmith dashboard.
  3. We’ll now see a new Appsmith app with an empty canvas and a sidebar with Widgets, APIs, and DB Queries.
  4. Click on the + icon next to the APIs section and choose the Google Sheets option. Next, click on the New Datasource button, set the scope to Read and Write, and click Authorise.
  5. This will ask us to log in from our Google Account, choose the account we want to access Google Sheets, and log in. After successful authorization, this will redirect back to your Appsmith account.
  6. Now, you’ll find your Google Sheets Datasource under your APIs, and you can create the necessary queries by choosing this data source.

Excellent; now that you’ve completed the set-up, follow the instructions in our docs and get started on your app!

Learn How To Make An App With Google Sheets

Are you interested in learning more about our engineering processes? Follow us on Twitter and Linkedin to stay tuned!

Write to me,, and I’d love to get to know what you’re building with Appsmith!



Akshay Rangasai
 minutes ↗

Product led growth as a concept is making the rounds. Investors cannot get enough of it, Twitter is filled with threads about this topic, and many dedicated channels and podcasts are talking about this “new” growth paradigm. However, product-led growth is not something new and has existed for ages. The internet and digital products (Tech companies - Primarily SaaS and consumer internet) have brought this in focus. Growth in organizations has always been tied to marketing and sales, but product-led growth forces us to change that perspective and think about organizations differently.

In this post, we will explore the history of growth for companies, the rise of product-led growth, and why the key to driving it is to think about engineering and product teams as revenue generators rather than just cost resources that need to be allocated optimally.

How the internet changed growth for companies

Historically, the three key pillars to driving growth are Price, Product, and Distribution. Price and product dictate demand, while distribution ensures products are available to satisfy demand. The new world with digital products changes a little bit but with massive consequences. Nevertheless, to understand why we need to focus on product as the key driver of growth, we need to dive into the history of product development and how businesses monetized products.

Before the advent of computers, most of the real-world products were physical objects that needed to be manufactured, priced and distributed. Product development took ages, manufacturing took as much time, and as if this was not enough, you needed to find distributors to distribute products. Computers solved this problem by making each step easier and faster and created a whole new category of digital products.

The software was quicker to make and did not have the manufacturing overheads, but distribution was still a problem. The other big problem in both models was the product itself. You did not know if the product was good or not till you bought it. The ability to have information to make sound product decisions was again constrained by distributing a publication (Like Gartner). If you subscribed, you got it; if not, you didn’t. This meant that product development was a cost, and sales and marketing were revenue-generating functions. Distribution was key. Most companies treated engineering and product as allocated resources, and sales took a lot of the value generated from selling this product. This was just how the old world worked.

The software also hacked the working capital cycles that plague most manufacturing companies. Not only do you need to set up the infrastructure and pay wages to workers, but you also had to foot the bill for each item being made, and then you made it back when selling the product. As your company scaled, so did the requirement of capital. Scaling rapidly was not just a function of people but also a function of how much money you had, or how many loans you could get to foot this bill. Software hacked this cycle; it was infinitely distributable, without any additional cost of production. If you had enough distribution, you could scale easily. The collection cycles also made the companies cash-rich and did not need as much money as other product companies to grow.

Then came the internet. While you can claim that the internet made distribution cheaper, it isn’t really clear if it did. It made distribution faster, but discovery (of products and customers) was still an unsolved problem. Gartner subscriptions came via email and mail. Search engines made distribution cheap. Discovery, which was one of the hardest problems to solve, got solved because of the speed and reach the internet offered. AWS made software development cheaper, you did not need a boatload of capital to start a software company. Gartner is getting replaced by Capterra and G2 for the same exact reason of discovery is cheaper, as is distribution.

All the constraints that existed before to make sales the top dog in a company have been eroding over the years. These advances have made it a level playing field (for the most part). Information availability (G2, Capterra), near 0 cost of distribution and setup means that the only way a company can differentiate itself significantly from competition and win is through product.

The new role of engineering in product-led companies

Cloud computing has made CI/CD possible, and this rapid iteration helps create value immediately instead of long product cycles. Every new feature that is released is monetizable almost instantaneously. Your engineering and product organization is directly contributing to revenue in a measurable way. This is not just an account expansion, or user acquisition focused growth; Retention is also significantly affected by your product's quality. Retention is the first step to growth.

Engineering has always been an expensive talent in organizations. Whether it was for silicon chips or software, it was a scarce skill always in demand. The old paradigm of product development classified these skills as costs, making sense in that era. However, for product companies selling software and other digital goods, engineering should be seen as a lever for revenue generation.

Newer organizations, especially in software, still treat engineering as a cost and allocate resources based on the cost that is saved by deploying this skill across the organization. Thus we see 100s of companies building their own recurring subscription infrastructure when multiple SaaS companies exist to solve this problem. Non-customer facing development improves efficiencies within the organization, but allocating the same resources to customer-facing development could potentially have a significantly greater RoI if internal tooling is handled by other bought software or potentially spending as little time as possible in building internal tools (Non-customer-facing software).

What we think this means is that org and incentive structures need to change. It is not just a sales and marketing team generating revenue but also teams of product managers and engineers responsible for revenue growth. This may sound too harsh given how teams are structured now, but with better focus and newer org structures, this will only seem natural.

Our experiences and conclusion

We think it is time for companies to rethink their build vs buy decisions and consider product and engineering revenue generators. Opportunity costs in whatever form must also be taken into account while making these decisions. In the new age, the product will determine the winner, and it is essential to align your teams on this mission.

Our experience building Appsmith has yielded disproportionate returns by keeping engineering’s primary focus on customer-facing features and requests. We are seeing impressive growth over the last few months with pure product improvements and additions (support is included, of course, by our engineers!). Maybe we were lucky as we are building an internal app builder, and our team was forced to eat our dog food, but this is something that we believe has worked well for us, and we think other organizations should consider it more seriously.

If you have any questions, suggestions or feedback, please feel free to share it at

Cover Image Credits: Photo by Isaac Smith on Unsplash