How we simplified the integration with our APIs within 2 weeks
Posted under Developer on September 7, 2018
Speed is imperative for a SaaS company like ours who primarily deal with the delivery of transactional emails. Along with speed, we are also responsible for the security of the emails. Hence, while making any changes or integrating new technology, we always give utmost importance to speed and security.Considering these factors, building client-side code libraries which are highly scalable and secure in various programming languages was a tedious process for us.
Our brand motive is to improve customer experience and we strive to achieve that by constantly working with new technology. Another factor which we gave priority to was maintaining the experience we create for the 30,000+ clients using our APIs for delivering millions of their business-critical emails. Our goal was to further simplify the process of integration with the launch of client-side code libraries a.k.a “Pepipost SDKs”
Why did we decide to build SDKs?
We offer multiple APIs, not only to send emails but for accounts and sub-accounts management, extracting reports, suppression management along with other features.
While these APIs are very lucrative as to what they offer, they do require a significant amount of development efforts for implementation. So, we sought out to find methods as to cut off the extra development and testing efforts so that developers can focus on the growth of the product thus optimizing the SDK building process.
This is where our SDK building journey started…
Plan A (Failed): Let’s build SDKs from scratch… Woah! The plan didn’t even kick off due to the major roadblock- It demanded huge development efforts, 3 weeks for a single SDK and the mission was to build 7. This was working at a turtle’s pace and setting us back big time.
Plan B (Failed): Let’s outsource!! We contemplated outsourcing the SDK development so that we could be ready to go live within a limited timeframe. But, the amount of investment it required vs the returns left us thoroughly disappointed. We were quoted $21000 bucks for 7 SDKs and it wasn’t even in the time frame we required. Thus, Plan B was out of the window.
How did we finally achieve our goal?
As it is said “Ambition is the path to success. Persistence is the vehicle you arrive in”. We had become adamant at this point, so we started digging around and brainstorming ideas for methods to build our SDKs. In U.S military there is a famous saying, Plan A and Plan B are good enough- you should be ready with Plan G. This is where Plan G came into action.
The tools we used.
We started exploring for online tools which can quickly read our API specification and generate SDK with embeded documentation.
At this point, we saw our first beacon of light after a long dark tunnel where we got exactly what we wanted- Swagger (a comprehensive SDK generator, what else we need).
We implemented it within a week and started giving life to our ideas. We were able to release our SDKs for users and our fellow developers on GitHub.
But as every smooth road encounters a speed bump, over a period of time as more API and edit requests started pouring in, the maintenance became troublesome.
The core .yml files required changes. Although we were live with our SDKs, we set out once more on a journey to discover some easily usable tools which could deliver result and we came across APIMatic.
After some detailed research and analysis, we found “APIMatic” to suit our needs the best. We immediately fell in love with APIMatic as it greatly simplified our life. At this point, we were clear with the precise implementation and use of our API so our requests were smoothly handled with APIMatic.
We already had the required .yml files of our API(v1) generated by Swagger which we directly uploaded to the APIMatic platform. Their developer experience platform gave us the option to automatically generate SDKs in approximately 10 programming languages and a ready to consume README.md. Isn’t it clear why we fell in love with the tool?
What if we have only the API and need to start from scratch? Could the tool be helpful then? Do I need to create the yml file for that again? Such questions started daunting us during the implementation phase. But APIMatic helped us there too with their developer-friendly dashboard and documentation. We had implemented APIMatic as POC but it turned out to be a very good long-term option as well.
On verge of Automating
We were elated to see APIMatic publishing packages directly to an official repository for Node, Ruby Gem, and Python. We will continue on the quest to add more to this list of awesome tools that all can use. We will be demonstrating the auto-deployment of our SDKs using Git deployment and package publish using APIMatic where we just need to provide credentials and once the SDK is regenerated it can be pushed parallelly. Continuous deployment helps us in seamlessly generating and deploying SDKs of the newer versions which are tested and integrated within a couple of minutes after the alterations have been made on code-gen as a service platform.
A special thanks to team APIMatic for their quick responses on queries and constant support. APIMatic not only helped us in saving development time but also the maintenance without any cost. You guys rock! Making life simpler for enterprises like us who constantly want to deliver next-gen service/products to the community all the while maintaining smooth and continuous workflows.