There are times when you choose to use a certain web based tool because it offers you everything you need and want.
Over time, your needs might change, but migrating to another tool could mean losing other features that made you choose the tool you are using in the first place.
If the tool has an api, as most, if not all, web based tools have nowadays, you could build your own tool which communicates through an api to the third-party tool of your choice.
When we, at AppSaloon, were faced with such a challenge, we decided to dive in and expand the functionality of our third-party tool.
We basically use the tool’s api combined with our own database as our data layer.
Of course we need to add a layer that will provide the business logic for handling data from both sources, thus an interface, to our data layer.
For easy understanding, we call it our backend (actually part of the backend is our third-party tool but that would just make this post confusing and we will only use it’s api).
A backend is pretty useless without a frontend, which means another layer needs to be built.
Since we love stuff that simply works, we made the following choices for our layers:
datalayer -> mySQL + third party api
backend -> Yii framework
In this blogpost, we will discuss the backend, since the technology used for the datalayer and frontend are commonly known by webdevelopers.
The choice for Yii was, to us at least, an obvious one.
Yii is a very well documented framework with great support from both developers and the community.
But mainly, we chose it because Yii uses lazy loading, which makes it outperform most php frameworks.
Yii being a MVC framework ended the decision process.
Since Yii usually uses a database to store its data and feed it to its views, we searched for an extension that gave us models that would offer us all the benefits of ActiveRecord (relations between models) while using an api as its data source.
This was found in the form of ActiveResource, a nice extension written by Yii community member Haensel. It’s still in alpha phase, but to be honest, we didn’t really notice that.
We changed some things, like not letting ActiveResource throw an error when the api request gave back an error header, instead we gave our models an extra attribute.
This attribute, conveniently called “error”, is an array which contains the error code and message from the api’s response to ActiveResource’s request.
This way, the frontend knows when it has made an invalid request without having to deal with http status codes.
Our own data which we wanted to add, was put in regular ActiveRecord models, and we defined relations between those and the ActiveResource models where needed.
After all that data juggling, we wrote an api to access all our models, from listing all to CRUD on single records. This api enables the frontend to handle our data and present it in a neat design.
At the end of this ride, we turned Yii into a framework that stands between two apis, juggles data but never drops a single record and maintains the performance it has when simply dealing with a single database.