Competitors?

[ijansch]

“ If you're worried about competitors messing with your priority list, maybe use something else.”

It’s probably not (just) competitors that you should worry about here. It’s more that a user that really wants a feature is easily able to outvote the other features as the limit of 1 per user is client-side enforced only.

Maybe use a real api behind it? (Or change the readme so users are made more aware to not use this for roadmaps where commercial interests are at play).

[jordibruin]

Made the readme more clear to address this. Would be nice if there’s another api we can use for this that handles this better yet is still easy to set up. Any thoughts?

[Sherlouk]

Unsure what options CountAPI has, as I can't actually even load the website (making this library not work for me) but gating options could include one vote per IP, or the optional ability to provide the Roadmap library with a user identifier -- where this comes from depends on the user but could be identifierForVendor or a custom login solution.

Probably makes sense to abstract the CountAPI solution from the library so plugins can be provided? (As long as it sits behind an interface, the user could override it with their own backend with auth etc). I could be tempted into open-sourcing a backend for this lib to handle these reqs.

[jordibruin]

Strange that it doesn't work for you @Sherlouk , any idea why that could be? https://countapi.xyz

We've definitely gotten some feedback on making the backend more flexible. I'm a novice on that stuff so would love to hear opinions on how best to approach it.

[Sherlouk]

Strange that it doesn't work for you @Sherlouk , any idea why that could be? https://countapi.xyz

I've always had problems with the .xyz TLD - no idea why, my local network just refuses to connect and I've heard of others with the same experience.

I think this library, as is, would benefit from being able to customise the backend by providing your own - while still using CountAPI as the default and embedded solution. I'm happy to raise a PR with this, it should just be a case of adding a new protocol to act as a middleman between the library and the backend, and adding a new configuration item for it.

[AvdLee]

I think this library, as is, would benefit from being able to customise the backend by providing your own - while still using CountAPI as the default and embedded solution. I'm happy to raise a PR with this, it should just be a case of adding a new protocol to act as a middleman between the library and the backend, and adding a new configuration item for it.

If you could, that would be great! Something like a FeatureVoter protocol that comes with the vote() method which is called from the vote button should be sufficient