One of the biggest questions I get when talking with CityGrid developers are around storing our data. Everyone wants to store the 15 million businesses CityGrid has in their own database. My response is really? You do?
This type of thinking comes from legacy thoughts around database driven applications and concerns about network latency. I counter these with a couple of points:
- You don’t want to be in big data business, we have teams of engineers working to ingest, clean, optimize and serve up this data. Do you really want to assume these responsibility.
- Our places, images, reviews, offers and other content is updated in real-time. If you store the data, you’re missing out on a lot of content that may change frequently.
- Speed is getting to be less of a concern when making calls to our APIs–you are looking at millisecond responses and in some worst case scenarios, 1 or 2 seconds.
Usually I can convince most developers about points 1 and 2. But speed is still an ongoing battle. We are working all the time at CityGrid to improve our API response times. But there are things you the developer can do to improve response times also.
One tactic that isn’t available in our documentation, is the use of GZip. With each API request you can set a HTTP header as Accept-Encoding: gzip, and the CityGrid will compress the responses for you, significantly reducing your round-trip time (RTT). Once you receive the response from CityGrid API you can uncompress using the GZIP decoding functionality available in any programming language.
Reducing the size of the data being transmitted is a great way to increase your RTT, which makes relying on any API for real-time calls, much more realistic. I recommend giving it a try when integrating your web or mobile app with the CityGrid Places, Reviews and Offers APIs.API / Compression / GZip / Latency / Round-trip Time / RTT / speed