The API has always had issues. Whether its a lack of data, too much data, incorrect data, and even data outdated by nearly a year. This entire approach has been "bad" imo. So, I've decided to change the approach. Plugin Portal will now rely more on other apis instead of caching everything in our database.
Solution Description
We will store only the name, id, logo, server type, etc. This will be used for displaying content about the plugin. We will store multiple plugins under a single ID when ever they are detected to be the same.
Options:
Fetch the plugin data on the server side, cache that response, and respond using that data to the client.
Fetch the plugin data from our server, then get more in depth info directly from the source.
I prefer option 2 due to rate limiting, less issues on our side, etc
Alternatives
No response
Additional Info
Please share feedback if possible, this will be made in 1-3 months. This is planned to be the final version of the API.
Stack: Golang, Gin, Mongo, dedicated server hosting
Problem Description
The API has always had issues. Whether its a lack of data, too much data, incorrect data, and even data outdated by nearly a year. This entire approach has been "bad" imo. So, I've decided to change the approach. Plugin Portal will now rely more on other apis instead of caching everything in our database.
Solution Description
We will store only the name, id, logo, server type, etc. This will be used for displaying content about the plugin. We will store multiple plugins under a single ID when ever they are detected to be the same.
Options:
I prefer option 2 due to rate limiting, less issues on our side, etc
Alternatives
No response
Additional Info
Please share feedback if possible, this will be made in 1-3 months. This is planned to be the final version of the API.
Stack: Golang, Gin, Mongo, dedicated server hosting