This blog post comes from Devangelist, David Stancu. Check out his work on GitHub or hit him up at Awesome IT.
Here at Dwolla we are building an innovative way to move money. However, thinking differently poses a challenge: we need to also create unique solutions that are best suited to our mission critical objectives. How can we do this in a time effective manner while still reaching all of our goals? The answer lies in open source software.
API V2 and SDK Support
The API team took a very data-centric approach in their decision to use the Swagger ecosystem. This let our internal engineering team focus on the API’s data and behavior first before forcing them to make considerations with regards to implementation. After they were finished, the Developer Relations team was handed the task of designing end-user SDKs for this version of the API (aka ‘V2’).
Exploring
As the Developer Relations’ engineering lead, I researched the Swagger ecosystem and quickly came across the swagger-codegen project, which would use templates to generate end user SDKs in over 10 languages for any API modeled in accordance to the Swagger Spec. I immediately cloned the project and attempted to generate some SDKs for a few languages popular with Dwolla developers; namely, Ruby, Python, PHP, and Java.
There were a variety of problems with generating SDKs using swagger-codegen. To highlight a few:
- Generated code often included syntax errors
- Data in nested containers could not be or was improperly serialized
- HTTP 201 requests displayed no data to the user
- Requests that replied with an HTTP 200 and no data would throw exceptions even if the request would complete
- No implemented OAuth stubs for Ruby or Python
Problems Shouldn’t Discourage
It is easy to see why it may have been more simple for me to just say, “well, this is going to be hell to fix, I’ll just write the SDKs individually myself.” I thought this same thing, but after taking a step back, there was no good reason as to why I couldn’t use the building blocks available to me. The strategy was to review, fix, and improve more than it was to reinvent.
Developers often feel intimidated when they read another person’s code — and even more so when they have to use that code for their own production purposes.
Even very good changes can be scary at first.
Doing two good things at once
As a developer, your problem may feel unique unto yourself, but that does not mean that the problem doesn’t share components with solutions being attempted by others. Simply put, if something is useful for you it may be useful for many.
By submitting fixes to the swagger-codegen project I’ve helped not only Dwolla, but the other organizations using this software.
For example, OAuth is one of the most popular authorization standards for RESTful services. By adding support to this project for OAuth to certain languages, I enabled that software to help more people than it did before — it’s about community
It’s an interesting time for programmers in the workplace. The ‘open source movement’ has produced a smarter developer; one that is not afraid to look around, ask questions, and share their knowledge. This “intellectual crowdsourcing” is essential to writing robust, stable and well-audited software — and this is what we do at Dwolla every day.
Excited by what we’re talking about? Head over to our developer portal and play around.
Originally published at blog.dwolla.com on December 29, 2015.
