How can we improve Trakt?

Syncing edited, liked, rated comments or replies itself with API insufficient

Recently you had an all around update on comments. Great! Finally!
Yet it wasn't anything like reporting comments, or giving us a way of ignoring certain people. But at least a step in the right direction. But one thing in particular is disappointing here:
It seems you did the same mistake again as you did with last_activity.

In terms of last_activity:
If a user edits any comment, commented_at of that user would change.
But you'd have to sync ALL comments ever written by that user because you have no chance knowing what or how many comments were edited (or in this context unfortunately "commented"_at).

In terms of comments/recent:
Again, editing a comment isn't well-thought-out. comments/recent wouldn't change the position if a user edits a comment. Given the fact that last_activity changed I'd expect that comments/recent updates as well and puts the updated comment at the top.
But it doesn't, it stays where it was before, it orders by created_at only.
That means with comments/recent I can only sync comments at a specific point in time. It's basically impossible to sync once and update as needed.
If comments were changed (and I'd have to assume constantly that's the case) I'd have no idea how many comments were changed and I'd have to call all 141640 comments again (worst case) to check.

And why is it that replies aren't in this endpoint? Don't they count as comments in this instance? I feel your wording is highly inconsequential on several occasions leading to issues on where the API goes.

Then there's the issue with likes. Liking a comment changes that comment as well indirectly. But I have no way of syncing/checking that either efficiently.

You seem to create one endpoint after the other to do basically the same thing just with different responses but the same issues.
That reminds me of v1. I'm not seeing the intricate cogs of your API from within but I see it from the outside and what I see is you're doing the exact same mistakes again you did back then with v1...

All we need is a simple way of getting either all or a specific user's comment objects (where replies are considered as comments) and an endpoint to check for comment changes with the changed comment's ids returned, not the timestamp of the last change. The latter is a completely useless information.
Whereas a comment is considered to be changed when: (un)liked, replied to, edited, user rating changed (where possible), or even created.
Endpoint: comments/changed
OrderBy: updated_at
Page and Limit as usual
trakt_id: n1,
likes: m,
replies: m1,
user_rating: n2 || null,
created_at: xy1,
updated_at: xy2,
parent_id: 0 || n3
}, ... ]
(Being nitpicky as I am you could then support /comments/[:ids]/* endpoints to lessen the requests, that's what I would do in your position at least)

How would you go about syncing comments of a or all users with your own API as of now? Including updates.
I don't see how that's possible without missing some crucial information or hitting your servers with redundant requests, doing twice or more work on any side involved.

3 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
ds1 shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • AdminJustin Nemeth (CEO / Founder, trakt) commented  ·   ·  Flag as inappropriate

    Sorry you had a bad experience on the API community. That is still the best place for API discussions since most developers are members over there. The last_activities is not a useless method. It might not work specifically for your use case, but it's still very useful for most syncs.

    I'll need to think about a structure that makes sense for the global and user comment methods. The default sort will be inserted_at, but have an option to sort by updated_at. We won't be bumping up edited comments when sorted by inserted_at, it would for sure be abused.

    There is some redundancy in the API, but that is sometimes done for caching purposes. If all the methods had one general endpoint with arguments accepted in any order, that would make our caching much less effective. Also keep in mind comments are cached for 1 hour at Cloudflare. So, when a comment is edited/liked/etc it won't be immediately available until the cache expires. I'd like to cache this more effectively and in real time in the future, but its not possible right now without a performance hit.

  • ds1 commented  ·   ·  Flag as inappropriate

    Do you mean the Google+ API community? I did post about the last_activity around May 2017 there, using a very particular use-case. No one wanted to listen why last_activity is useless, not even you after I mentioned you and Sean more than once over a timespan of a few weeks.

    The only feedback I got on it was one +1 and some other random person saying "there's{{user}}/comments with all your comments, why do you use the API", not even trying to understand what I was going on about.
    That was my final clue to leave - very frustrated and after deleting my post - the imo very much pointless group that unfortunately isn't and never really was about API discussions (exceptions apply). But about questions by rookies not reading the docs, or wanting you to do all their work. So, no, quite frankly I am not going to post there ever again. I was in that group from the very beginning you started it, btw.

    Moving on from my very bad experiences with that group over a loooong time.

    An additional option to include replies wouldn't be too bad, I guess. Yet, I still wouldn't be able to order by updates and would still have to check all comments for updates manually.

    Sure, the comments/recent gives away that it is about "recent" comments, yet you can use pagination to technically sync as many comments as you like from the past. There doesn't seem to be a limitation.
    And while I understand your reasoning to not order by updated_at as is, I would still argue that an updated comment should be considered as a new comment, since you don't know how much of a comment was changed. For example added spoiler after creation, or new paragraphs after a new season, could be important as well. Yes, this can and probably would be exploited (liking and unliking or vice versa to get back to the top), as is the liking of your own comments to get in the top three spots, but you have pagination available on that API endpoint. Hence I do not see it as a crucial disadvantage. Lessen the exploitable possibilities by an optional sort order of updated_at while created_at is the default. I see the exploit as more of a third party implementational concern than an API concern itself.

    Or use another endpoint like /comments/updates with data parameter for this, that would fit, too. Buuut then again, we have a new endpoint to get "comments". Comments that have a parent...while I am not entirely sold on that it's your API.
    Just beware to not create more endpoints doing the same or in worst case return the exact same response as another endpoint. Any /updates endpoint doesn't particularly need to return the full comment either (by default not at least).

    I can't particularly name a specific API, I used too many, but usually those APIs in question give you an endpoint with some objects as response, i.e. comment or media objects, and you can use parameter to sort by specific pre-defined attributes, as in sortOrder=created_at or along those lines. I thought of this when posting this feedback but wasn't really sure whether or not to mention it as you try to re-use parameter like the extended info and this would perhaps mean very vast changes on multiple endpoints, making this rather unlikely.

    Whether you include some form of sortOrder or date(s) as parameter (preferable, imo), or any other way to get comments (incl. replies) by updates and those updates happen when (un)liked, replied to, (un)rated, or rewritten, I'd be pretty happy either way.

  • AdminJustin Nemeth (CEO / Founder, trakt) commented  ·   ·  Flag as inappropriate

    Good feedback, thanks. Do you have examples of other APIs and how they handle some of these ideas?

    I don't think we can include replies by default, since that would lose context very easily and would be unexpected for apps to handle. However, I think it makes sense to add an optional parameter to include replies in the user method.

    The /comments/recent is meant to surface newly posted comments. If updated comments moved to the top, that would be very easy to abuse. However, it does make sense to add a new /comments/updates method that works similar to /movies/updates where you can pass in a date and get anything updated after that. (makes sense for user based methods to support /recent and /updates too)

    We don't plan on batch methods (i.e. passing multiple comment ids) since that completely breaks caching. That was an issue with v1 and why we no longer support passing in a custom set of ids to most methods.

    I'd also recommend starting a discussion in the API community about this since that will get a lot more feedback and real world examples that other devs might also have feedback on. The devs are checking this support board at all.

Feedback and Knowledge Base