-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Port link resolver responses to JSON #498
Comments
Doing this would make the project into, although Twitch-flavored, a general purpose link resolver. 😍 A very dank resolver. Also opens the repo for use in projects other than Chatterino (inb4 braize becomes paid API, because why host one on my own? |
In theory, this is possible already by parsing the returned HTML responses. But a change to JSON would certainly make it easier for other projects to consume the API. Whether that's a good thing or not, I'm not entirely sure yet. It would be interesting to hear from stakeholders (i.e., people hosting well-known c2/api instances or developers that might want to consume the APIs) on this issue. I can think of @pajlada, @zneix and @Leppunen on the server side. Possible consumers include @flex3r and @rod41732. |
A JSON response endpoints (maybe controlled by headers? idk) is fine by me. Ideally, we should not see this as a port or a migration, we should see it as adding another way for clients to get information about links, now in JSON instead of HTML. |
I'm a little concerned about the maintenance overhead in this case (having to indefinitely support both formats). Also, what use case would HTML responses address once the C2 client makes use of JSON responses? |
I'm not necessarily saying we need to indefinitely support both formats, but more that there should be a lot of time inbetween JSON support being implemented & considering HTML deprecation The overhead shouldn't need to be big, HTML outputs on a per-resolver level right now is a HTML tooltip: youtubeChannelTooltip = `<div style="text-align: left;">
<b>{{.Title}}</b>
<br><b>Joined Date:</b> {{.JoinedDate}}
<br><b>Subscribers:</b> {{.Subscribers}}
<br><b>Views:</b> {{.Views}}
</div>
` with the struct containing that data. In a world where we output JSON, I imagine for youtube channels we'd want to output something close to {
...,
"fields": [
{
"label": "Joined Date",
"value": "RFC-COMPLIANT_DATE",
"type": "this is an rfc-compliant date, parse it as such",
}
]
} so the work of transforming the HTML template to support whatever underlying struct shouldn't be too big, nor should it require much maintenance afterwards |
This issue is intended to gather feedback and implementation ideas.
Currently, responses by the link resolver are raw HTML which is sent to clients with the intent to be rendered directly without any additional logic performed by the Chatterino client. This approach has pros and cons.
Pros & Cons
Pros:
Cons:
(I probably missed some important aspects in this section, feel free to expand on these in the comments.)
Migration
Ideally, we would like to migrate without crippling older versions. The easiest approach would probably be serving the new responses over a separate API endpoint.
a. How does this impact caching of responses in the database?
b. Can we share cached responses between both endpoints?
c. Would it even be a problem to duplicate the data during the migration period?
How can we share JSON schemas between the server and clients in a reliable manner?
a. Do we even want to?
b. Can we share schemas for the possible link info responses via an API endpoint as well?
At the client, "views" for the different response types must be implemented.
a. What would be a good approach to keep code duplication and boilerplate to a minimum?
b. Can we even provide a rendering information via the API as well (e.g. by exposing QML over a separate endpoint)? If implemented properly, this might allow us to provide link info for new providers without user interaction.
Migrating to JSON responses would require us to impose stricter requirements on the response schemas than what was necessary for HTML responses. Specification of such guidelines would be a good first step towards the implementation.
The text was updated successfully, but these errors were encountered: