We've been busy improving our APIs based on your feedback, and I'm excited to announce a few additions we've just shipped. Versioning The biggest change is the addition of versioning to our APIs. We use a date based version which you can pass through in a API-Version header when making API requests. curl 'https://email@example.com' \ -H 'API-Version: 2015-05-11' All of our clients support setting a version. For example with our Ruby library: Clear
Versioning APIs is never fun but if you provide a public API it's something you'll almost certainly run up against eventually. At Clearbit we've just started adding breaking changes to our API and have had to start thinking about how we're going to approach versioning. There seems to be a few main approaches that people have tried: Use the URL This is a fairly straightforward solution - simply add an incrementing version number in the URL and route different API versions to different endpoints
Heroku [http://heroku.com] is an awesome component to the developer toolchain and lets you get something up and running easily. For me at least, it's transformed how I think about and architect applications. However, there are also a lot of reasons why you might choose an alternative. Maybe it's speed, control, or maybe you just like tinkering. For us, the reason was cost--pure and simple. Clearbit has a huge cluster of machines crawling the web, and Heroku would have been prohibitively expensi
Streaming to browsers has got a lot easier with the advent of APIs like WebSockets [https://developer.mozilla.org/en-US/docs/WebSockets] and Server-sent Events [https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events] . However the server-side aspect is often trickier to setup--many servers and runtimes are not tuned for long-lived requests. There's a much simpler approach to 'realtime' updates which can be applicable in some situations; polling the page's endpoin
PostgreSQL is notoriously bad at performing well with high offsets, mainly because it needs to do a full table scan and count all the rows up to the offset. This can be a problem is you want to paginate over a full table without holding all the rows in memory. On the surface of it PostgreSQL Cursors [http://www.postgresql.org/docs/9.2/static/plpgsql-cursors.html] may seem like a good solution to this problem--rather than executing a whole query at once a cursor encapsulates the query allowing y
Engaging stories and exclusive data, designed for our best customers. One useful issue each month.