One of the things we find important as a company, is giving back to the community. We (get to) devote some time during office hours to contribute to open source software by working on existing projects, or by open sourcing our own libraries.

Our frontapp gem is one of those projects. While we initially wrote the frontapp Ruby client to interact with the Front API for ourselves, once published it took on a life of its own. Contributions by GitHub users @techpeace, and more recently @tatey, make working on it all the more worthwhile.

About the project

We wrote about our tuning of Front before, where we improved spam handling. We use Front extensively to handle email communication for everything related to sales, account management, support, general inquiries, etc etc. Needless to say we're very invested in the tool and our library.

The frontapp gem was first created as a wrapper to make interacting with the Front API as easy as possible. It was initially used by our in-house developed CRM, enabling us to sync contact requests, upgrade requests, and support tickets across our systems.

The power of community

Being content with our little library because it has helped them make a speedy integration with Front, Tatey added a patch supporting custom fields when creating and updating a contact. Tatey also added custom error subclasses. Inspired by the Octokit gem, which follows a similar pattern, this patch is useful if you need to handle errors differently or if you want to silence specific errors in your exception tracker. Tatey noticed the tests on master were failing, because the gem's mocking framework expected the data in a request to be ordered the same as in a stub, even though order shouldn't matter for a hash/JSON object. That's now fixed.

Lastly, Tatey - who is also fortunate enough to be allowed open source play time during office hours - introduced functionality where integrators can set a custom user agent that identifies their user agent, and defaults the user agent for the gem to "Frontapp Ruby Gem x.x.x" (v0.0.5 at the time of writing).

Next steps

Next, we're looking to implement support for uploads. Currently, it looks like we'd need to support multipart requests in order to upload attachments. When you want to send files through the API, your request needs to be sent using the Content-Type HTTP header set to multipart/form-data. However, this will cause our tests to fail, a known shortcoming of WebMock which we use to simulate http calls during tests. Any pointers? Please let me know.