ljoonal
commented
1 year ago Including more Q&A's for completeness sake
1. How is this different to vrchatapi/vrchatapi-rust?
VRChatAPI is generated from OpenAPI specification files (maintained by the people behind that project). Whilst there's nothing wrong with that in itself, it leads to less rust idiomatic code (I'm guessing due to the code generator not being able to infer things humans can with manual inspection). Some examples of what I mean by it not being idiomatic rust;
- It's using strings instead of newtypes (comparisons of differing IDs can happen easily by accident)
- It uses automatic derive of
Debugfor structs containing secret tokens, meaning the tokens may get logged in debug logs, whereas I'll try my best to customize theDebugand such implementations to not log the tokens - Not using enums with data (it does seems to generate enums with no data "inside", which is common in other programming language's enums, but in rust they can be made so much more powerful...)
- Missing proper documentation in the rust crate (see how bare the index docs.rs page for it is)
- The API call interface is ugly to me (as in, they require you to pass in a configuration struct to each api call function, instead of just implementing the function calls on the configuration struct)
Secondly, this project intends to be API client neutral.
If you take a look at chilloutvr_rs, you can hopefully get a general idea of what that means;
Providing a reference API client implementation, sure, but model the requests and responses in a declarative way where anyone can just implement their own small API client layer on top of the Queryable trait.
I tried to find a generic crate for it, the closest I found was pretend but it seems unmaintained and doesn't support all the things I want, which sadly does mean consumers will need to implement the client abstraction layer themselves.
But it's way less code than re-doing all the API calls, if for exampel you don't like the blocking reqwest calls which the vrchatapi crate is married to.
Which is also a part of the reasoning for this, I wanted the API client to be async.
And finally, this is still WIP, whereas the vrchatapi project is mature. But it also means that this project can make breaking changes and have an easier time being flexible. Also means that more contributors would be more than welcome & appreciated 😄
2. Why does the repo for a vrc api client mention abi?
chilloutvr_rs, explains the mention of ABI. The base files for this repo were sloppily copied from that one. The mention has now been removed.
For more context: onlivfe is my actual reasoning for starting a new API client project. I thought about just moving all the API clients to a mono repo as well to avoid this kind of sloppy copy-pasting issues, but decided against it so that the API clients would be clearly separate projects, without seeming like they're tied to onlivfe.
3. Why this is already published without implementing pretty much anything?
We do not have any policies to define 'squatting', and so will not hand over ownership of a package for that reason.
The effect of which can for example be seen with the vrchat crate.
I wanted to reserve a name for the project before working a lot on docs and such only to have to rename it by someone else taking the name in a similar fashion. If I somehow don't end up implementing this and years later someone is reading this issue, they can send me a message and I'll happily give up the name.
1, how is this different to vrchatapi/vrchatapi-rust