Alex Berg

Uninterrupted Workflows with Open Source Tools

A few weeks ago, I wrote about a multi-file upload tool for Visualforce pages that a member of the Force.com community had written. In a lengthy blog post, he summarized the challenges involved with designing and implementing his Javascript upload tool. I found it to be quite an interesting read, so interesting, in fact, that I promised myself to return when I had free time to clean up the code. I finally found free time last weekend, and when I finished refactored the code and reflected on the experience, I saw a huge benefit when using an open source code tool.

First, some backstory. One of the features I wanted to contribute was REST support. In it’s original design, the component sends chunks of each file to the Salesforce backend using an Apex controller to receive them. While this works well, I was curious to experiment with adding functionality to instead send the file to a Salesforce Apex REST endpoint. Since the normal domain name and the REST services domain name are different, the same-origin policy, which protects users from Javascript attacks, blocks the request. To solve this problem, we need to use the Force.com Javascript REST Toolkit, which re-directs these REST requests through a Salesforce proxy before hitting the user’s REST endpoints. Changing the tool to utilize this library won’t be too difficult, so I’ve started to utilize it in my re-designed file upload code.

This is where the benefit of open-source has become apparent. Because the library I am utilizing is permissively open sourced, I am able to copy it into my org without worrying about copyright infringement. Even better, when I find a small bug in the open source library I am using, I am able to make the fix myself, without interrupting my workflow. This happened to me when using the Force.com REST Toolkit. I found a problem with the ‘apexrest’ method. While this method allows the user to set the HTTP request body, it doesn’t provide a means for setting custom headers, which is a key function of REST. It was a pretty simple bug to fix, so I quickly fixed it in my local copy of the library. To help others avoid hitting the same silly problem, I decided to contribute this fix back to the original project by submitting a pull request to the project maintainer, who was quick to respond.

Now consider the other case, in which the library is proprietary. In a case like this, developers would potentially have no visibility into the code behind the API, forcing them to submit a bug report to the project maintainers, who likely have other priorities and would not be able to investigate for several hours. I would then have to wait for them to release the updated version of the library. This workflow has a significant amount of downtime compared to that of an open source library.

While it may not be the best choice to use a community open source library or platform for every project, the benefits of using one can be quite great.

Posted in: Programming, Software Development