With this one simple trick we got 5 more API clients

We believe that in order to provide a good API service you will need sensible API endpoints, but more importantly you will also need well-tested, supported and easy-to-use API clients. With this in mind we were motivated to provide API clients for the programming languages most likely to be used, and being used, when integrating with us.

Over the past few months we have released five new Twingly Search API clients, supplementing our already existing Ruby client. Check them out at GitHub.

But how did we do it? Are we proficient in C#, Java, Ruby, Python, PHP and Node.js? We wish. Inspired by the likes of Diffbot we decided to use Upwork to help us find freelancers which would make our vision come to life.

Our process was something along these lines:

1. Improve the Ruby client so that it could be used as a reference implementation
2. Decide upon on which freelancer platform to use, we evaluated a handful of them
3. Determine a maximum cost per client
4. Write a job listing for one of the programming languages, this included researching things such as: which packaging systems are there? CI services? Which versions should we support?
5. Post the job listing and wait a few days for the job applications to drop in
6. Choose among the candidates, usually more than 10 persons applied for each job
7. Hire the most suitable candidate, for example we looked at references from earlier freelancing jobs, example projects, GitHub profile and so on. We noticed it was quite common with empty, or skeleton, repositories on GitHub, requiring some efforts on our part to find actual code 🙂
8. Review the work, repeat until both parties are satisfied
9. Accept the work/API client, including source code in a GitHub repository
10. Repeat steps 4-9 for every programming language, for each iteration improve the job listing with lessons learned and links to the newly implemented client

It is worth mentioning that we spent plenty of time reviewing the work for a few reasons:

• We want consistent behavior for all of our clients.
• We want our customers to have a good user experience.
• We need to understand the code in order to be able to maintain it.
• We are curious creatures and are always eager to learn new things.

For others venturing into the freelancing world, here are some of the most important things we learned from this experience:

• Be explicit with the requirements. We discovered that for some freelancers a vague “point at an existing implementation” would work just fine and lead to the expected outcome but for others it would not turn out the way you anticipated.
• If you are using GitHub and pull-requests, do not create the GitHub repository and let the freelancer submit a large initial pull-request, those are impossible to review (or well, they are hard to give feedback on). Rather, either let the freelancer start out in an own repository or invite them to collaborate on your repository. It is much easier to review and provide feedback when using GitHub’s issues as opposed to comments on a large pull-request.
• Depending upon your use-case, you might not need to spend as much time reviewing the work as we did. Remember that curiosity is a double-edged sword.

If you are interesting in more information, please leave a comment and we’ll make sure to respond!

By Robin Wallin