Plugin Website Comments/Ratings Implementation

Overview

Usually a plugin site or an extension store has features allowing users to comment and rate a specific item. This kind of interactive feature requires a backend to provide data dynamically. Normally, for dynamic sites, they can use their own API and backend to do that. But for static websites like Plugin Website for Joplin, we have to borrow the power from an existing API provider such as Github API or Discourse API.

The general idea is that, when a user visits the website, the website will send an asynchronize request to the API to pull data dynamically. And when a user writes a comment or submits a rating to a plugin, the website will create a request to the API to update the data.

UPDATE:
After further investigating how other static websites(like blogs, product promotion sites, etc)(example) did, I found that most of them only display the comments. And you have to go to places like GitHub issues or the forum to post a new comment.

I think this makes sense since it's dangerous to let users put content directly from front-end without an authorization system. And for these two APIs, you have to have a API KEY to post thing to it which can be dangerous if we coded it into the front-end without proper permission control, too.

So maybe embed the Discourse Comment Embeds into the website is the better way for us now.

Original Content

Choice of API

Potentially, I have two options in my mind. The first one is the Github API. Github API has the power to perform CRUD operations on repos, issues, gists and etc. For example, we can store the comments and rating data inside a gist, and using Github API to retrieve and update these data.

To get a gist simply send a GET request to /gists/{gist_id} endpoint. It will return the file in files field. And to update a gist, send a PATCH request to /gists/{gist_id} with a body contains the file.

The downside of using Github API is that

  1. It has limitations on requests per hour. For anonymous users, it is 60 times per hour. And for authorized users, it is 5000 times per hour.
  2. It might be unstable for users in specific regions, like China.

The second one is Discourse API. The idea is basically the same as the Github API, the difference is we are creating a post in this forum to keep track all the data.

We can retrieve post from https://{defaultHost}/posts/{id}.json and update post by sending a PUT to https://{defaultHost}/posts/{id}.json.

There are also downsides to this one:

  1. API key required, it is generated from the admin pane. I don't know if there is permission control on this, if not then it might be dangerous to use this API on the front end.

Let me know if you know better ways to implement interactive components on a static website. Any discussion is appreciated!

2 Likes

that may simplify it: https://utteranc.es/

I guess this is preferred as it would keep all information within the forum. Is there an action you can reference the related GH Issue / PR

1 Like

That makes it easier!

I don't know if there is anyone has done this before. But I think the main problem is that if you want to use this API, you need an API key generated by admin which might causes permission leaks.

It looks like you wouldn't the first one

1 Like

It seems that Discourse Embed is the way to go. But it requires users to navigate to the forum to post comments, is that acceptable?

I guess so, read some conversation and it seems that direct answer won't come

Hi PackElend,
Can you set up Discourse as Embedding Discourse Comments via Javascript - developers - Discourse Meta so I can embed it into the Plugin Website? We can have all the comments posts under the plugin category or we can have a new category for this.

With these two approaches how do you deal with race conditions (multiple users commenting or voting at the same time)?

After further investigating how other static websites(like blogs, product promotion sites, etc) did, I found that most of them only display the comments. And you have to go to places like GitHub issues or the forum to post a new comment.

I think this makes sense since it's dangerous to let users put content directly from front-end without an authorization system. And for these two APIs, you have to have a API KEY to post thing to it which can be dangerous if we coded it into the front-end without proper permission control, too.

Building an authorization system is barely impossible for a static website (at least for me). So I believe embed the Discourse into the website is the better way for us now.

How do you handle a case like this?

  • User 1 download the post
  • User 2 download the post
  • User 1 adds a comment
  • User 2 adds a comment

In that case the changes from user 1 will overwritten by the changes from user 2, and one of the comment will be lost. I don't think any of your solutions handle this at the moment.

Also most of this logic is client side - how do we handle someone purposely deleting the complete content or replacing it with broken content?

Thanks for explaining what race condition is, but my point is we don't have to deal with these issues ourselves because Discourse and Github handles them. As I said earlier, we might need to let users to go to places like Github Issues or this forum to post new comments. And in that way we only display comments in the Plugin Website and not allowing them to post comments directly under Plugin Website.

BTW, excuse me for my bad grammar, please let me know if you have trouble understanding my wording.

That's why I'm suggesting to embed Discourse in the site.

@Retr0ve you may share some references where it is implemented, that probably makes all easier

1 Like

Sure! Here is an example(a blog) that uses Discourse Comment Embed.

What you say now is in contradiction with what you said in your initial post. So did you make a mistake or were you completely unclear?

It is something we discover while investigating how others did this. You can say it's a mistake.

may you want to update the OP to avoid anyone has to read through all posts to get the clue out of it

1 Like