Pretty much everyone who works with kdb+ will be familiar with the standard kdb+tick setup (and usually enhanced frameworks such as TorQ with additional functionality). This system allows a tickerplant to receive data e.g. from a market data feed & disseminate this data to subscriber processes, such as a realtime database (RDB). And of course, other processes can subscribe e.g. a realtime metrics process.
In my previous post I discussed using Let’s Encrypt to generate a CA-signed certificate for use in q to run an HTTPS server. At the tail end of that post, I mentioned redirecting HTTP requests to run over HTTPS. Since then, I have written & published a small package to do exactly that.
In a previous post I discussed creating an HTTP API in q. Back then I mentioned that I may explore adding HTTPS support at a later point; I’ve recently had a chance to give this a try, and thanks to Let’s Encrypt it’s very easy to do!
One thing I’ve always envied in other languages is package management. Python has
pip, Node.js has
npm, R has CRAN, ruby has gems…the list goes on. For a kdb+ dev, the situation is a little different. For a start, there’s much less open source (or closed source, for that matter) code available to be used in our projects. And when there are bits and pieces available, they’re not always written in a way that easily integrates into other code. We end up copying & pasting code into our code base, making it trickier to get (or contribute) upstream changes.
In previous blog posts, both here and on the AquaQ blog, I have mentioned the reQ HTTP library that I’ve been working on. And the time has come for an “official” release! reQ has reached a point where I think it can be quite useful, particularly for interacting with web APIs from q. You may be wondering what’s wrong with
.Q.hp, the built in HTTP request functions in q; reQ has a few nice additional features over these…
WebSockets are a technology enabling two-way communication between a client and server over a single TCP connection, defined in RFC6455. Essentially an initial “handshake” HTTP request is sent from client to server, requesting an upgrade from HTTP to WebSocket protocol. The server responds with an Upgrade message, and communciation begins.
A few weeks ago I published a post on the AquaQ Analytics (my employer) blog regarding using REST APIs in kdb+. You can read that blog post on the AquaQ blog. Just for fun, I decided to try building the “other side” - creating a REST API powered by kdb+. The result is found in my GitHub repo, qwebapi.