dogfooding (computing - informal) - to use a product or service developed by that company so as to test it before it is made available to customers.
We have now got to the stage where we have launched our latest web app, HR Partner. Though we have reached launch stage, there are still a few things about the development of it that I'd like to share with you.
One of the things that we deemed was important to have from the outset, was an API (Application Programming Interface) that our users could use to query their employee data in HR Partner and integrate it with other systems. This was slated as a 'Phase 3' project, which was to be commenced well after initial launch and we had a solid base of customers on board already.
However, one of the other things that we wanted to have in HR Partner was an extremely flexible reporting system. Basically, we wanted our users to be able to query their data and filter (and sort) the data by any database column, including custom fields that the user can create within HR Partner.
When designing the architecture of the reporting engine, we realised that it would have to be quite complex, with a ton of checks and meta programming to enable the user to specify just about any query they wanted across the main employee file, plus the related lookup files.
We realised that we would essentially be duplicating the 'engine' for the reporting side, along with the engine that would drive the API later. So we decided, why not kill two birds with one stone here - and we temporarily shelved the reporting engine development to sit down and build version 1 of our API engine.
Version 1 was basically purely a 'read only' API engine that allowed us to query the database tables and return the results as a JSON data stream.
THEN, we went ahead and started building the front end for the reporting engine, which directly used our API engine to pull and sort the data we needed for the reports. All transparent, and invisible to the end user.
As you can imagine, this was a major change to our development timelines, but at the end of the day, it actually saved us time later on down the track. The bonus is that we get to see our API being used under real world stress conditions. We still haven't released the API specs publicly, but plan to do so in the coming months once we have completed stress testing and built the read/write components.
Building the API first also allowed us to start writing other apps for integrating various legacy payroll systems to HR Partner. One of the payroll systems we support is Attache, which is a 30 year old Windows based system that uses the old Microsoft ODBC method to extract data. We have designed a 'gateway' Windows app which uses a combination of ODBC and JSON API to pull data from Attache and upload to HR Partner in the background.
We used the Padrino framework to build HR Partner, which is based around Ruby/Sinatra. Padrino allows us to mount separate apps within the same server easily, so we essentially have one app for the main HR Partner app, and another separately loaded app for the API, which allows us to still host on one AWS Elastic Beanstalk instance, yet be able to separately upgrade and take apps online/offline.
I am glad we made the design decision to shift our build targets around and get the API built first. I can appreciate now what a lot of other startups are trying to do, by building the API, then designing their app around the API. It makes for a far more robust and solid system.