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.
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.
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.
You have a button to reload a table, presumably to refresh the data from your datasource.
You use the Button property, onClick, which runs the query to fetch the latest data into the table.
Your query fails.
- On just the Error pane
- On the Error Logs pane under Logs
The triaging in our example above is especially useful when you have nested queries, several dependent bindings, and a more complex workflow overall.
Set points in your code that you want to log statements at, view tabular data, or see groups for repeated errors.
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
With actions, you see them when you
With JS Objects, you’ll see system logs when you
Just like errors, system logs are native to entities and have four parts to them.
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.
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.
Like errors, a system log has two parts to its source—the entity’s name.the type of entity, e.g., SELECT1.TABLE1.WIDGET.
👌🏽 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!
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.
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.
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.
That title is a tongue twister, innit? Almost.
Here’s a meme that isn’t. It’s just the painful truth.
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.”
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.
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.
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,
The Debugger solved several of those problems.
Available on app.appsmith.com 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. :-)
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.
Depending on the error type, you will see a couple different kinds of issues.
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!
This is the most helpful part of the message, beginning with Error and ending with a helpful bit of text or a number.
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.
Consider two situations we have painfully drawn for you.
You have several queries and widgets on your way to a complete build.
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 ↓.
When you find the first problem query, you’re hoping against hope this is your patient zero.
Most times, though, Murphy’s Law applies.
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.
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.
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.
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.
With the Appsmith Debugger
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.
You see all the errors from the transformation in one pane with click-actions for each one of them.
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.
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.
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)
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. Devops.com 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).
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.
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”.
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.
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 Dev.to 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.
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.
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!
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:
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:
Here’s a screenshot:
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:
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.
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.
Additionally, you can use these on input widgets as well:
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.
Last month was crazy for all of us; we’ve published seven new blog posts and have successfully hosted four live events!
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.
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.
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.
“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.
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
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
Write to me, email@example.com, and I’d love to get to know what you’re building with Appsmith!
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.
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.
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.
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 firstname.lastname@example.org