If you have read our previous blog post, you would have learned that we have recently released Typetalk’s API to developers.
Many developers make use of API to develop programs to solve problems. Though in Typetalk, you are actually using its API on an everyday basis even if you are not a developer or don’t develop your own programs. The Typetalk web application is completely based on its API, which means that you are calling the Typetalk API whenever you use Typetalk on your web browser.
It is common practice to separate the API and functionality of a web application in most web services. That is, most web services don’t call their API directly from their web applications. However, Typetalk functions differently in that the Typetalk API is called directly through AJAX on our web application.
So, why did we select such a design?
1. Reduce implementation cost on development
When you separate an API from its web application while their functionality is identical, you are actually implementing similar codes for both the API and the web application. Copying snippets of code from one place to another and modifying it not only consumes extra time but is also a dull task that has plenty of room for errors and bugs. Using API directly from the web application reduces time wastage and the risk of generating bugs, which in turn reduces the resources and implementation cost required.
We have been offering the Typetalk API and adopted this architecture since its preview beta launch, and it has helped us save an immense amount of time and cost.
2. Constant testing and improving
Here’s my favorite quote in The Golden Rule of API Design, a contribution article by Michael Feathers in the famous book 97 Things Every Programmer Should Know:
It’s not enough to write tests for an API you develop; you have to write unit tests for code that uses your API.
If you have never used your own API before delivering it to users, you would never know if the API design is good or bad. Consequently, there would be little or no improvements made to your API at all, and chances are, it would not be good enough for anyone to use it.
As I mentioned above, Typetalk’s API is the core of the web application and almost all its features are provided via API. This means that we first have to implement the API when we want to add features to our web application. So we, Typetalk developers, are actually the first users of our own API, which allows us to constantly fix and improve on our API if there is a problem or if we are not satisfied with it.
3. Open and flexible integration
Just as how we appreciate the principles and spirit of open source, we want to provide Typetalk with an open API so that a broad spectrum of developers can easily integrate and optimise its features to the fullest. All features of Typetalk can be accessed through its API which is also publicly open to developers. This means that even if you are not a Nulab developer, you can create your own Typetalk client with the same important features. This architecture of Typetalk’s API has also simplified the development process of its mobile versions for us.
What do you think of such a design? Share your thoughts with us in the comment section below. In one of the coming posts, I will demonstrate how we realize this design in code.