Comments (5)
I intend to cover Helix, TMI, PubSub data structures (no client), extensions, and (possibly) GraphQL. I do not intend to cover twitch irc (cough twitchchat ), Drops, or other third party APIs.
I'm unsure about undocumented features on endpoints, they would be good to have, but as expected they are not 100% reliable inregard to stability, currently the only undocumented feature is in the pubsub branch, but I think I want to implement some more helix endpoints that are used on the website.
I'm open to adding anything though, as long as it is directly affiliated with twitch.tv APIs :)
from twitch_api.
... I do not intend to cover twitch irc (cough twitchchat ), ...
Yeah, basically no one should bother tackling chat at this point since museun's got it covered better than any of us could 😆
I'm unsure about undocumented features on endpoints, they would be good to have, but as expected they are not 100% reliable inregard to stability,
Yeah, it would probably be good to have some sort of marker to make it obvious to users that a given endpoint is unofficial and may technically break at any moment, especially if you decide to start supporting more of them. Might actually be good to hide them behind a feature flag as well.
currently the only undocumented feature is in the pubsub branch
Aren't all of the TMI endpoints technically undocumented? Unfortunately there are basically no alternatives to get_chatters
and get_hosts
, and basically every bot in existance uses get_chatters
, so hopefully they'll add them to Helix before decommissioning those... But AFAIK they're not officially documented anywhere.
I'm open to adding anything though, as long as it is directly affiliated with twitch.tv APIs :)
Cool. Just for reference, what about WebHooks or v5 (Kraken)? I know Kraken is deprecated, and it seems like Helix is getting much closer to covering everything that was missing so far, and there are a couple other crates that seem to cover it, though they are less maintained and currently the versions on crates.io seem to not even be building.
from twitch_api.
Oh, and should something be added to the README to make the planned scope more clear?
from twitch_api.
I'm unsure about undocumented features on endpoints, they would be good to have, but as expected they are not 100% reliable inregard to stability,
Yeah, it would probably be good to have some sort of marker to make it obvious to users that a given endpoint is unofficial and may technically break at any moment, especially if you decide to start supporting more of them. Might actually be good to hide them behind a feature flag as well.
Sounds good, one possible solution is to use deprecated tag or perhaps doing some css trickery (which would only be visible in docs). Gating them sounds fair.
currently the only undocumented feature is in the pubsub branch
Aren't all of the TMI endpoints technically undocumented? Unfortunately there are basically no alternatives to
get_chatters
andget_hosts
, and basically every bot in existance usesget_chatters
, so hopefully they'll add them to Helix before decommissioning those... But AFAIK they're not officially documented anywhere.
true :D
I'm open to adding anything though, as long as it is directly affiliated with twitch.tv APIs :)
Cool. Just for reference, what about WebHooks or v5 (Kraken)? I know Kraken is deprecated, and it seems like Helix is getting much closer to covering everything that was missing so far, and there are a couple other crates that seem to cover it, though they are less maintained and currently the versions on crates.io seem to not even be building.
Webhooks are part of Helix, so yes. For v5 Kraken, I guess this crate can provide some abstractions for it.
from twitch_api.
For v5 Kraken, I guess this crate can provide some abstractions for it.
Hey there,
hatmatter stopped maintaining his twitch_api
crate/repository and I was somehow there in time, because I needed a crate, so I took over the of maintenance. I'm an beginner in regards of Rust, though coming from C/C++. But I started actively maintaining the crate again in my fork: https://github.com/age-rs/libtwitch-rs
I updated the outdated dependencies and changed the http client from hyper to a more high level one - reqwest, for easier maintenance.
As I saw you repository here, I was lowering the scope of the before mentioned repository to just maintaining the older Kraken API as long as it's needed/used. I think yours here and @Waridley effort to unify the Twitch API crates under ttv-rs
is kind of interesting and I would like to contribute with parts(?) of the twitch_api
/libtwitch-rs
crates - if that's possible.
In the end I would like to mirror the ttv-rs
main crate on the twitch_api
crate on crates.io for easier discoverability - if that makes sense.
EDIT: Ah what I forgot: It might make sense to create an organisation here on github solely for this twitch api effort and all repositories or should it be managed from one repository overall? I think collaboration makes really much sense here. =]
from twitch_api.
Related Issues (20)
- Impossible to use requests / body with DeserializeOwned HOT 5
- EventSub Over WebSocket HOT 3
- Why can't I put multiple broadcaster_id in GetChannelInformationRequest? HOT 2
- Games: Get Games and Get Top Games IGDB Field
- Help appreciated (get_followed_streams) HOT 2
- Getting a backtrace with a specific broadcaster id 418158680 HOT 2
- introduce `beta` feature for public betas instead of `unsupported`
- Make `helix::client::custom` first-class
- another bug while decoding teaminfo HOT 4
- Add way to mock responses
- Investigate querying twitch docs HOT 1
- sprinkle more must_use on all structs
- Bors deprecation - remaining
- Clarify how or make it easier to pass in collections that are T: Iterator<Item=D> in builder functions for helix requests HOT 4
- Create a tower rate limiter for helix which respects twitch headers
- use `async fn` and return-position `impl Trait` in trait HOT 1
- Enum twitch_api::eventsub::Status unknown variant `websocket_failed_to_reconnect` HOT 2
- reqwest 0.12 upgraded hyper, http, and http-body to v1, causing build failures
- Update to reqwest 0.12 make error "trait `twitch_api::HttpClient` is not implemented for `reqwest::Client`" HOT 8
- Future incompatibility with Rust RFC 3373: Avoid non-local definitions in functions HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from twitch_api.