Skip to content
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

API proposal: plugin actions #3434

Open
Derkades opened this issue Aug 29, 2023 · 4 comments
Open

API proposal: plugin actions #3434

Derkades opened this issue Aug 29, 2023 · 4 comments

Comments

@Derkades
Copy link
Member

The plugin can push events to the website by making an HTTP request, but there is currently no way to send an event from the website to the plugin. We solved this in Nameless-Link by running a second HTTP server on the other side, but I don't think this is feasible in the plugin. It would require users to understand having a second port open on their Minecraft server, and ideally put it behind a reverse proxy for HTTPS.

The best solution I think would be a polling system, like Websend and the Store module already use. But instead a different of a poll system for every feature, it would be nice to have one that can be used by everything, including third party modules. This is why I think it makes sense to use a namespaced type value, just like API errors.

We need an endpoint for requesting pending events:
GET ..?route=/api/v2/plugin-action&server-id=x (name is just an example)

{
  "pending-actions": [
    {
      "id": 123,
      "type": "nameless:group-sync",
      "data": {
        // e.g. player uuids and groups to be added or removed
      }
    },
    {
      "id": 124,
      "type": "store:command",
      "data": {
        // store module command data
      }
    }
  ]
}

Also an endpoint is needed to mark a pending action as completed (by id), so it is no longer listed by the endpoint above.

@partydragen
Copy link
Member

partydragen commented Aug 30, 2023

Yea then its the question we discussed before to use Queue system as it kinda belongs in there, But at the same time it don't and might be better with a own system for that idk

Also by type wont that be messy as then you need to check if its a command to avoid hard coding each type so you don't need to add support for new modules like

  • store:command
  • forms:command
  • trophies:command

unless you check after : is "command" idk

@samerton
Copy link
Member

samerton commented Sep 1, 2023

Something to consider with this approach would be how we store these "actions" that haven't been synced yet, and also how we know if we should store them or not (i.e. if there is no plugin set up storing them would be pointless)

@Derkades
Copy link
Member Author

Derkades commented Sep 1, 2023

Also by type wont that be messy as then you need to check if its a command to avoid hard coding each type so you don't need to add support for new modules like
* store:command
* forms:command
* trophies:command

We could add a generic type for command, good idea.

Something to consider with this approach would be how we store these "actions" that haven't been synced yet, and also how we know if we should store them or not (i.e. if there is no plugin set up storing them would be pointless)

I assumed we'd just store it in a database table. You do make a good point about actions piling up when no plugin is set up. Perhaps pending actions should be removed after a certain timeout, like a month?

@partydragen
Copy link
Member

partydragen commented Sep 2, 2023

Something to consider with this approach would be how we store these "actions" that haven't been synced yet, and also how we know if we should store them or not (i.e. if there is no plugin set up storing them would be pointless)

Could add last ping colum to servers table like i do with Store connections, Then we know if server is setup correctly and we know its active or not

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants