Web to Server communication.

Discussion in 'Spigot Plugin Development' started by Mystic_Mark_, Oct 4, 2019.

  1. What will be the best way to send commands from my website to my server without using another plugin?
  2. Either sockets or an API. Is the communication bi-directional or not?
  3. MiniDigger


    I would just setup a simple websocket server in a plugin and implement a simple protocol.
  4. It's only Web-> server
  5. I would recommend building a small web API into your plugin (something like a REST or GraphQL API).
    • Agree Agree x 1
  6. MiniDigger


    since I guess you are not dealing with hundred of thousands of requests per second, I would suggest setting up a simple REST api using spark:
  7. Sorry for my late reaction. But what I want is that I click a button on my website (This website runs on a web hosting), Then execute a command in my server.
  8. You can use Spark for that, you'll have to integrate it into your plugin so that your plugin runs a REST server. Upon a call on your endpoint, execute your command.
  9. If you want to be able to issue commands, then I would recommend using RCON
  10. Then the server needs another assigned port right?
  11. Strahan


    Yea, and you're gonna need another port regardless. You can't reuse the primary that is already in use.
  12. Is there a solution without using a additional port?
  13. Strahan


    There is always a solution, though said solutions may not be at all practical or feasible. I dunno if/how one does it in Java, but in C# I can create a FileSystemWatcher that will react if a specific filespec appears and act on it, so the web server could write a "payload" file and the server will see it and read it. Of course, that means the web server has to have file access to the MC server and if it's not on the same box then again, new port required. You could have your MC server do an outbound call to the web server to check for a payload, or outbound to a SQL database. You'd just have to poll often or warn people of an X minute delay for processing. Also it'd be hacky as hell but you could have the web server connect a bogus player to the server and send the data in a chat message. The plugin could intercept the PlayerJoinEvent and hide the message and intercept the chat and hide it from being seen.

    *shrug* Why is opening another port an issue?
  14. Its not really an issue but what we want to make is a system using an api key. And then the servers with the same api key will get the command requests. And if some hostings do not support an additional port the plugin can 't be used.
  15. Strahan


    Well, sometimes things just have to be a certain way. Like BuyCraft/Tebex for example. Gotta have that listener, it's just something people accept as necessary. If they can't open another port, they can move to a more flexible host.
  16. Why does nobody mention message queues/brokers? You publish some message (or called event) on a queue, like with apache kafka or rabbitmq. Consumers (your server) can then consume these events. Your MC server logs into the queue and pulls new messages, so theres no need for an additional port on the Minecraft side, only one for your broker obviously.

    This solution is a tad more complex, not exactly something a beginner can easily do most of the time. Especially Kafka with (at least the ones I used) Java connectors were pretty difficult to use unless you really understand how Kafka works (I don't fully understand all details either, most of it I get though).

    I do believe such solution would be your ideal outcome. A message broker is a standalone solution. Systems can connect to it and publish messages. Any system connected to it can then consume these. Think of it like a cross-system event handler.

    However, you do need enough flexibility in whatever environment you are using to implement this. If you build your own software then this shouldn't be an issue. If you have to make with pre built plugins or other systems, nothing custom, then you can probably forget this idea. I plan on using this technique to power part of my project, but that's for future plans.
    • Like Like x 1
  17. Strahan


    Never heard of it. Sounds cool, have to do some reading on it :)
  18. Yeah, you should. They're extremely powerful and very common in modern software architectures like microservices. A tad off topic but the info could be of use here.

    In a microservice architecture, you build separate components that have no direct dependency on each other. However, they still need to communicate with each other. Imagine a website, a Minecraft server, and a few other components which need to do something with some kind of purchase order from Buycraft (which sounds like what OP may be trying to achieve).

    For example, imagine the following scenario. Again, I assume OP may be referring to handling donations properly, so I've put that in a component overview below, but the practice is generic and can be applied in many cases.


    The scenario assumes that we have Tebex (previously named Buycraft) where donations come in. Buycraft has a webhook feature which you can use to send restful API messages. We can setup some tiny microservice which accepts these API requests (our REST entry point). This service would then publish an event on the message queue, which could be anything, like Kafka or RabbitMQ for example. This event would only contain our Minecraft name, since that's all that Tebex captures.

    You could directly consume this event then in your Minecraft server for example, and apply the purchased product with the data from the event. However, what about giving your product on the forums? Or on Discord? That's where an account linking microservice could kick in, for example. It could be responsible for keeping track of linked accounts over different platforms. It could then consume the Minecraft donation event, and fire new events based on linked accounts. It could publish another event for a Forum donation, and Discord donation. Those events would then be consumed by the relevant service, such as your forums or a Discord bot.

    That's how your typical microservice components can integrate with each other without having a direct dependency on each other. It makes everything scalable and easy to manage. However, as I mentioned in my previous reply, this isn't the easiest. This is absolutely custom development, so if OP has to do with pre existing tools, then this won't be an option. However, if you are able to develop this yourself for example, I'd say consider it at least. Again, this is how I plan to run quite a few things in my own project. Just one example of many cases above.
    • Useful Useful x 1