Open BusinessDuck opened 8 months ago
By the way, if you have beta, let me try i'll test it and send you a report asap. And may be fix in MR
Hey, thanks for the kind words! The library will be published this week with full coverage of the trading and market data APIs, including crypto. Just need to clean up the types and set up the build process. The core logic is all done. Will tag you first thing 😉 when its out.
Ok, I have a deployment action setup, it is now being published to NPM. I have tested a good amount of the trading API endpoints, market data next. Types are a bit brutal to cleanup but i'm getting there. Feel free to install and test at will while I develop further.
Also the WebSocket is functional but the types are .. in progress to say the least.
Good news, i'll start with btc now, because stocks are out of market time. I Will send to this thread everything what i can find. Also after migration (from master chief's library) i can make a PR
Doc:
By default, the client will make requests to the paper trading environment (https://paper-api.alpaca.markets). This is a safety measure to prevent accidental trades.
Real one:
Parameter baseUrl
is required and have no default value
Expected:
After the first look at the client i guess i need two different clients with same credentials: One for the market access and another for the data stream, is that right?
once
event subscription (default for EventEmiiters
today) its a bit friendly.Also regarding with connection. Can you please clarify how it works now, i need answers to the following questions:
I need an example with this call:
const res = await this.api.v2.assets.get({ symbol_or_asset_id: ticker }); // looks wrong
const res = await this.api.v2.assets[':symbol_or_asset_id'].get({ symbol_or_asset_id: ticker }); // looks right but not clear
Also i need example with market data subscribtions channels - How to subscribe to quotes and bars and handle it?
Also i dont see the Bar
or RawBar
types or something similar for incoming data in npm module exports, where it is?
Is that right? May be unlisten
here? Same for other subscribe removers in market and data
A default baseURL
would mean that you must know in advance whether to provide either paper or live keys. I wanted to go for a more explicit approach, maybe that's worth re-thinking 🤷🏻 .
I'll add source, good catch. WebSocket is very unfinished right now, I will do that tomorrow before I cleanup/add the types for the market data endpoints.
Now as far as the below is concerned..
const res = await this.api.v2.assets.get({ symbol_or_asset_id: ticker }); // looks wrong
const res = await this.api.v2.assets[':symbol_or_asset_id'].get({ symbol_or_asset_id: ticker }); // looks right but not clear
The idea here was to mimic the path of the endpoint. I don't know what to do about those types of endpoints.. if I break convention with something like a getById
that would make it more clear I suppose. What do you think?
I could also just say screw it and go back to .getAccount
, .getAsset
, .getOrder
😕 lol
- [ ] Add
once
event subscription (default forEventEmiiters
today) its a bit friendly.Also regarding with connection. Can you please clarify how it works now, i need answers to the following questions:
- All connection keep alive logic is under the hood and i don't need to do anything with handle connections loses on my side?
- Will subscriptions are restored after reconnect?
Yes I intend to add reconnect options to the client params, maxRetries
, backOff
etc. I will also add a .reconnect()
in the context if you wish to do that manually.
Honestly, going back to the camel case getters would make my life a lot easier as far as the types are concerned. Compiling a list of all this, keep it coming 😄.
The idea here was to mimic the path of the endpoint. I don't know what to do about those types of endpoints.. if I break convention with something like a getById that would make it more clear I suppose. What do you think? I could also just say screw it and go back to .getAccount, .getAsset, .getOrder 😕 lol
I like an idea to use v2
as versioning parameter that's super good for default REST versioning and back compatibility. So and relates to call method style i think its default to have a different methods like getAssets
and etc many other financial SDK also on that way. When we are in default that mean its easy to migrate to that SDK from another one.
Yes I intend to add reconnect options to the client params, maxRetries, backOff etc. I will also add a .reconnect() in the context if you wish to do that manually.
I wont do :) I want to have a stable access to market and data, and that is everything what i really need :)
Yes I intend to add reconnect options to the client params, maxRetries, backOff etc. I will also add a .reconnect() in the context if you wish to do that manually.
I wont do :) I want to have a stable access to market and data, and that is everything what i really need :)
will update this all tomorrow 👍, late here at the moment.
an unstable websocket is very annoying ill make sure it stays connected within the client
Ok just powered through refactoring all of the trading api methods https://github.com/alpacahq/typescript-sdk/tree/main?tab=readme-ov-file#methods. How do we feel about that? I like it, maybe all of the crypto ones need "crypto" in the method names though.
Build will be failing, I have to refactor the createClient
and market data next. I am going to make the baseURL
auto-detect based on either paper or live keys, it will use the right URL for the given method you call.
You can see the re-written code here.
Taking a break today, will get the build working and trading api methods consumable so you can test it a bit later.
---- base ----
getAccount ✅
createOrder ✅
getOrder ✅
getOrders ✅
replaceOrder ✅
cancelOrders ✅
cancelOrder ✅
getPosition ✅
getPositions ✅
closePosition ✅
closePositions ✅
exerciseOption ✅
getCalendar ✅
getClock ✅
getAsset ✅
getAssets ✅
getWatchlist ✅
getWatchlists ✅
createWatchlist ✅
updateWatchlist ✅
deleteWatchlist ✅
getPortfolioHistory ✅
getConfigurations ✅
updateConfigurations ✅
getActivity ✅
getActivities ✅
---- options ----
getOptionsContract ✅
getOptionsContracts ✅
getStocksCorporateAction ✅
getStocksCorporateActions ✅
---- crypto ----
getCryptoWallet ✅
getCryptoWallets ✅
getCryptoFeeEstimate ✅
getCryptoTransfer ✅
getCryptoTransfers ✅
createCryptoTransfer ✅
getCryptoWhitelistedAddress ✅
getCryptoWhitelistedAddresses ✅
requestCryptoWhitelistedAddress ✅
removeCryptoWhitelistedAddress ✅
---- all ----
getNews ✅
getStocksLogo ✅
---- stocks ----
getStocksCorporateActions ✅
getStocksMostActives ✅
getStocksMarketMovers ✅
getStocksQuotes ✅
getStocksQuotesLatest ✅
getStocksBars ✅
getStocksBarsLatest ✅
getStocksSnapshots ✅
getStocksAuctions ✅
getStocksConditions ✅
getStocksExchangeCodes ✅
getStocksTrades ✅
getStocksTradesLatest ✅
---- forex ----
getForexRates ✅
getForexRatesLatest ✅
---- options ----
getOptionsBars ✅
getOptionsExchanges ✅
getOptionsSnapshots ✅
getOptionsTrades ✅
getOptionsTradesLatest ✅
---- crypto ----
getCryptoBars ✅
getCryptoBarsLatest ✅
getCryptoQuotes ✅
getCryptoQuotesLatest ✅
getCryptoSnapshots ✅
getCryptoTrades ✅
getCryptoTradesLatest ✅
getCryptoOrderbooksLatest ✅
Working on websocket now.
Can you create a beta release? I will try to use
Use the npm publish --tag beta
Check latest, added method examples to README too. https://github.com/alpacahq/typescript-sdk?tab=readme-ov-file#methods
Doing WebSocket now.
So far https://github.com/alpacahq/typescript-sdk/blob/main/factory/createStream.ts, types and auxiliary functions next.
import { createClient, Client } from '@alpacahq/typescript-sdk';
client is not exported from sdk, that needs for usage like:
...
protected api: Client;
...
this.api = createClient({ key, secret });
Hacky way working now:
...
protected api: ReturnType<typeof createClient>;
...
Typings wrong in 0.0.24-preview
Not same with described here
missed "types" field in package json
node -v
v18.19.0
npm -v
10.2.3
missed "types" field in package json
node -v v18.19.0 npm -v 10.2.3
added
Hi! I see that the project is almost ready. Let me express my gratitude for your contribution to the algo trading community. I'm really looking forward, like many others, to the latest version of the typescript API for alpaca. Thank you for creating this project.
I would like to know if there will be crypto support out of the box in the first release? This is very important because it is difficult to test real positions because we immediately run into daily trading limits, and there are no such limits on crypto assets. I'm really looking forward to the appearance of crypto assets in the API so that I can work and study the behavior of transactions in the real market.