💬 Open Source App Framework to build streaming apps with real-time data - 💎 Build real-time data pipelines and make real-time data universally accessible - 🤖 Join historical and real-time data in the stream to create smarter ML and AI applications. - ⚡ Standardize complex data ingestion and stream data to apps with pre-built connectors
The idea is to extract the code we use to communicate with the api into its own library so that, soon enough, we can ship a NPM package in sync with the version of core (and add a clients section to the api reference of docs.airy.co).
Important bits of information:
HttpClient may not be the best name but it's practical and keeps the door open for WebSocketClient. We will rename the go library as well (and call the java one the same when we introduce it)
We place it in lib/typescript/httpclient or lib/typescript/clients/http (but I think we have to keep the name to HttpClient either way). The placement under lib/typescript is part of the larger effort of introducing clients in different languages. A bit more about that in the next point.
We put all the payloads in the name directory (say lib/typescript/httpclient/payload, one payload per file. I understand it's a little tedious to do this manually, but the idea is exactly we won't do this over time. We plan to generate the payloads with bazel (haven't gone over the details yet so there's no issue in github. But there's multiple ways to achieve this)
The idea is to extract the code we use to communicate with the api into its own library so that, soon enough, we can ship a NPM package in sync with the version of core (and add a clients section to the api reference of docs.airy.co).
Important bits of information:
HttpClient
may not be the best name but it's practical and keeps the door open forWebSocketClient
. We will rename the go library as well (and call the java one the same when we introduce it)lib/typescript/httpclient
orlib/typescript/clients/http
(but I think we have to keep the name toHttpClient
either way). The placement underlib/typescript
is part of the larger effort of introducing clients in different languages. A bit more about that in the next point.lib/typescript/httpclient/payload
, one payload per file. I understand it's a little tedious to do this manually, but the idea is exactly we won't do this over time. We plan to generate the payloads with bazel (haven't gone over the details yet so there's no issue in github. But there's multiple ways to achieve this)