How We Built Custom JavaScript Libraries For Appsmith — Insights From Our Dev Team

We're proud of the work we are doing alongside our users and contributors to make Appsmith the cornerstone and lead innovator of the open-source internal-tool development space. Together, we have accomplished a lot — a turnkey internal app development platform that connects to your existing data stores and allows you to start building robust applications in minutes.

With this goal realized, we are now focusing on making Appsmith even more flexible. Support for custom JavaScript libraries (we'll refer to this feature as custom JS from now on to save you some reading time) is a major new feature in our platform that allows you to use external JavaScript libraries within your Appsmith projects. This greatly expands Appsmith’s functionality and, most importantly, means that you don't have to implement the functionality from these libraries yourself.

Now that our work on this exciting new feature is completed, we thought we'd share some notes from the custom JS development process with you. We hope that by opening up and sharing how we plan and implement major features we can help you and your team augment or improve your app development workflows.

How do you use custom JS libraries in Appsmith?

Appsmith's integrations for popular tools and services make it easy to get your app connected to your data stores, communication channels, and online workspaces without fuss. This functionality is one of the biggest strengths of our platform, and we are improving on it further by extending Appsmith to be able to support any compatible JavaScript library. We want to give our users more power to build apps that do what they need rather than having to adjust their requirements to a restrictive development toolchain.

Adding a custom JS library to your Appsmith project is now as easy as copying and pasting the URL to the library — hosted on a public CDN or your own private server — into the Appsmith interface and then using it.

Why did we build it?

Developer time spent on writing boilerplate and re-implementing functionality from existing libraries is wasteful, so adding support for custom JS libraries was a no-brainer. 

In addition to this functionality being a natural progression of our platform's features, there was a lot of interest from our community — Appsmith is rapidly growing in popularity, and with more users, there are more use cases arising that require more custom functionality. 

As the stewards of a world-class open-source project, it's our job to build the core functionality that our user base can build on so that we can continue to provide the foundation for the future of internal app platforms. On top of all of this, we use Appsmith ourselves, and we need this functionality too!

How we built it: Insights into the Appsmith Engineering team’s process

It would have been very easy to get lost while building such a heavily integrated feature in consultation with our community. While we wanted to make sure our users' requirements were met, we were wary of trying to satisfy every user's requirement — support for less popular libraries’ edge cases could be handled once the majority of our user base could use the libraries they required.

Both staying in sync with our community’s needs and working as a distributed team would require diligent planning to ensure that our scope remained focused on deliverable results.

From the outset, we ensured that we planned carefully and worked methodically to address any issues that arose and developed a consultation process whereby teams would “borrow” specialists from other teams temporarily to prevent team bloat.

We identified what was required

The starting point for this project was to identify what libraries we would need to support for this feature to be useful for our users. Once these libraries were identified, we would be able to figure out the technical requirements, limitations, and security implications of allowing such libraries access to Appsmith's internal workings.

After consulting the users who had been vocally requesting support for third-party libraries, we decided that the first requirement would be support for at least 60% of the most popular use cases, with a focus on jsPDF, excelJS, Supabase, and JWT. If support for these libraries was technically feasible, the development of the feature could go ahead full steam.

The second requirement was that the end-user experience for integration of third-party libraries needed to be simple — as simple as finding the library with a built-in search tool within the Appsmith interface or copying and pasting the URL to the library on a CDN or hosted by the user. 

The user experience is always our priority. It would have been a waste of resources if we’d built a feature that went unused due to its being unintuitive or because it adds unnecessary complexity to workflows.

Planning and design — we settled on the scope

After some initial investigation so that we were (reasonably) sure that Appsmith's architecture would be able to satisfy the two primary requirements detailed above, we developed the specifics of how this new functionality would fit into the platform. 

We were working with an existing codebase, so we had to look at what APIs — from both Appsmith and the web browser — would need to be exposed to the custom JS functionality for these libraries to function unhindered. We also needed to identify any existing code that would interfere with these libraries or prevent them from working.

The final stage of our planning process was to finalize a clear scope for our work:

• The aforementioned third-party libraries would have to be fully functional when imported into Appsmith

• Only browserified libraries would be supported

• Custom JS functionality needed to be sandboxed for security reasons, with only access to a vetted list of browser and Appsmith APIs

• Libraries that modify the DOM would not be supported

These limitations ensured that no development resources would be wasted on dead ends. As custom JS libraries are executed on the front end, limiting support to those bundled by Browserify meant that we could focus our attention on packages that were more likely to work than not. Omitting libraries that manipulate the DOM also meant that we could focus on packages that do not conflict with the Appsmith interface and add practical functionality, as Appsmith already has its own robust graphing and visual elements built in.

Careful planning made implementation a breeze

Known technical hurdles can be accounted for in the development roadmap, allowing for adequate time and resources to be assigned. Conversely, unknown roadblocks can hold up development indefinitely while developers scramble to find a fix.

We think our attentive planning phase resulted in a more streamlined implementation phase. We were able to focus on delivering reasonable results with an existing codebase, as opposed to making unrealistic promises that may turn out to be impractical once implementation has begun.

One of the biggest advantages we had while working on implementing custom JS was Appsmith’s “modular monolithic” architecture. While this architecture evolved somewhat out of necessity — a monolithic codebase that needed to become more compartmentalized as the scope and number of teams working on it grew — it has lent itself incredibly well to our agile development process.

Compared to applications structured around microservices, monolithic codebases are easier to deploy, often perform better, are less complex (in terms of both overall architecture and deployment infrastructure), and are broadly easier to understand.

Figure 1: Appsmith’s “modular monolithic” architecture keeps our application components manageable while providing a single deployable Docker image.

Provided your teams are all comfortable working with the same tools and software development paradigms, the “modular monolithic” approach means that you maintain only a single codebase organized into a strict hierarchy based on the distinct functionality and the team responsible. The codebase remains a single, easy-to-deploy binary, while teams can work in pods and avoid stepping on each other's toes.

In addition to Appsmith's core development team is spread across the globe, we're open-source, so we have contributing developers in a number of time zones. The modular architecture described above enables our teams to continue working on their pet features independently of what other teams are doing. 

Collaboration is handled with industry-standard tools like Slack, Notion, and Figma, and of course through our GitHub repositories — ensuring that work can progress asynchronously.

Adding custom JS to Appsmith happened quite swiftly overall. We spent two months validating, prototyping, and testing our concept, before settling on the final scope and specification. A further two sprints were then used to polish everything into a final product, ready for you to use.

Every development journey hits some snags

Not everything was smooth sailing, of course. During the development phase, we had to test and retest the initial libraries we were targeting every time we made changes to check whether something had started or stopped working. This caused some drag but was necessary to make sure development was progressing in the right direction.

Some unexpected work was required to enable support for browser APIs with security implications. For example, the Fetch API used to make network requests, is required by many popular JS libraries to make external API calls. We had to rewrite parts of the Appsmith front end to enable this functionality while maintaining security.

One disappointment was the removal of the library search function from the initial release. In addition to being able to paste a library's URL into Appsmith’s studio for immediate use, we wanted users to have an interface for searching a database of compatible libraries. The practicalities of implementing this would have drastically increased development time. It would have been detrimental to our users to delay the release of the custom JS functionality in its entirety for the sake of including a ”nice to have” feature at launch.

The best thing we can share about our development process is the borrowed specialist

Figure 2: A team of expert hammers celebrates the arrival of the specialist screwdriver to help them complete a specialized task

We think the best thing about our development process is the efficiency of our teams. Key to this is how we structure them: we assemble a core team for each internal project, with skills oriented around the specific feature they are working on. If a task is identified that requires knowledge outside of their domain, they bring in a specialist in that area from another team. The specialist performs the required work only in that area and then leaves.

This allows us to stay focused and maintain momentum — each team member, transient or otherwise, can be constantly utilized rather than sitting idle when their particular skills are not required. This approach also prevents teams from becoming large and unwieldy, a problem popularly addressed by Jeff Bezos’s two-pizza rule.

Getting custom JS libs working with Appsmith's Git integration was one time when we required specialist knowledge. We invited one of the engineers from the Git integration team to spend a couple of days with us helping get custom JS and Git working together and then, once the code was implemented and tested, sending them back to their team.

This approach to specialization makes our teams more agile and greatly improves how we work collaboratively.

If you love it, set it free: open source has become a big part of our process

The open-source nature of Appsmith is also a huge benefit to our development process. Contributors can inspect our code and make suggestions for improvement, and the community is always willing to help us test out new features — especially when the result will benefit their own workflows as their tools continue to be improved.

Once testing versions of custom JS were rolled out, the community quickly took it upon themselves to start testing the supported libraries. This proved to be a far more robust testing process than our own internal testers could accomplish — developers could actually build apps with the libraries to test them in real-world usage scenarios. 

Community testing worked incredibly well, revealing weaknesses in the feature that we could shore up to improve compatibility (and unfortunately leading us to remove our recommendations for some libraries as they were not yet stable enough for production use). 

Figure 3: Early feedback from the community has been both encouraging and informative

Now that our custom JS feature has officially launched, we are seeing all kinds of ideas and applications from the community, even using libraries we haven't tested yet. One unexpected use case was integrating Appsmith with Web3 technologies — some of our users already have Appsmith performing operations like sending money or accessing their crypto wallets. 

We're excited to see what our community of developers builds with the almost unlimited new Appsmith features made available by custom JS libraries.

Appsmith is all about lightening developer workloads

Appsmith is an internal app platform made for developers who want to remove the toil from their lives. Central to this is removing the need to write boilerplate, manually build forms, and re-implement existing functionality.

The custom JS functionality is a massive leap forward in this area for both Appsmith and app development platforms in general, allowing you to use any compatible third-party JavaScript library in your Appsmith apps. We’re not done with it yet either – we’ve got big plans for the future of custom JS, including:

• Wider compatibility — support for more libraries and browser APIs

• Private NPM packages — the ability to import your org-specific private NPM packages

• Improved error handling — more informative errors to assist you with integrating your own libraries

• Better search and installation — an index of supported libraries for you to search and install them from within the Appsmith studio interface

Appsmith is defined by its open-source community of internal-app developers. If your team has a unique development practice you’d like to share with us, drop us a comment — we’re always looking for better ways to work! The more we share our best tools and practices, the better our collective platforms, apps, and developer experience become.

Appsmith is totally free and open source, and with our Docker image, you can be up and running in minutes. If you don’t want to self-host, try out our custom JS functionality in our free cloud-hosted Appsmith environment. 

Cover artwork by Jemma Jose