python-discord / site

pythondiscord.com - A Django and Bulma web application.
https://pythondiscord.com
MIT License
642 stars 127 forks source link

Backend information to fetch smarter resources filters #710

Open Bluenix2 opened 2 years ago

Bluenix2 commented 2 years ago

Summary

Following python-discord/bot#2079 it was discussed having an API allowing the bot to fetch possible filters so that implementations don't need to scrape it.

This new API could power different future bot features like having interaction-based URL builder.

Description

Currently resources are loaded from a folder of yml, then a number of different steps in processing are applied to sort out all filters and its topics. This is a highly dynamic system which will complicate this PR.

The API resides in pydis_site/apps/api whilst the resources is in its own app at pydis_site/apps/resources (the actual view is in pydis_site/apps/resources/views/resources.py) which complicates things. See, for the API backend to get access to that information there needs to be an import there or loading - which might be unwanted.

This means that the implementation might be a bit more complicated than one might first think. The easiest way to go about this would be placing the route under resources but it is still, technically, part of the API. Another option would be duplicating the processing, inside of API, but that still requires access to the folder of resources meaning that we are back at square one of having unwanted coupling.

Assignee

@iamericfletcher has asked to implement this (I couldn't assign them directly). Please note that this is still in planning.

iamericfletcher commented 2 years ago

I don't have much to contribute to the discussion since I'm still relatively new to programming. I'd rather use this opportunity to absorb what I can from those with more experience. Still, I find the API interaction with bot and vice-versa fascinating and am excited to take on this issue if approved!

PLAZMAMA commented 2 years ago

Since I am new to open source and am looking for my first contrib. I would like to try to tackle this issue with another willing person.

imbhaskarn commented 1 year ago

Is the issue still open?

PLAZMAMA commented 1 year ago

I don't know to be honest, I only see that its still open here.

jchristgit commented 1 year ago

@Bluenix2 just so I understand it correctly: is this about having an endpoint that exposes the query parameter filtering support of site endpoints?

jchristgit commented 1 year ago

Ok, it seems I missed the mark. Is this about exposing the filters in this dictionary? https://github.com/python-discord/site/blob/main/pydis_site/apps/resources/views/resources.py#L68

wookie184 commented 1 year ago

Ok, it seems I missed the mark. Is this about exposing the filters in this dictionary? https://github.com/python-discord/site/blob/main/pydis_site/apps/resources/views/resources.py#L68

Yeah I think that's the idea.

Currently if the !resources command is given an argument e.g. !resources web development, the link will filter the topic by web development (links to https://www.pythondiscord.com/resources/?topics=web-development). This would potentially allow fuzzy matching for topics, or extending it to match on things other than topics (e.g. it could tell that !resources free wanted https://www.pythondiscord.com/resources/?payment-tiers=free).

If we want to do this it would probably be worth having a bot issue with a concrete use case for the endpoint first, so we don't add something we wont use, and we can ensure the endpoint includes what is needed. I somewhat question whether it's necessary, given the person can just filter what they once when they're on the page.

mbaruh commented 1 year ago

The resources command currently does no validation for the given argument. There is this new issue https://github.com/python-discord/bot/issues/2510, which I think is very reasonable, but I would rather the bot didn't spit back arbitrary strings given by the user (both for the correctness of the provided URL and from a moderation perspective). I think that's already a solid use case for this feature.