El código, tal cual existe ahora, está en un lenguaje extraño para la mayoría de miembros, y posee una barrera de entrada muy alta!

Es importante generar documentación al respecto, y explicar partes de la API que no resulten claras en documentos que se mantengan relativamente al día, cosa de que este proyecto pueda ser mantenible con el tiempo.

Esto no solo se refiere a escribir comentarios en el código, pero es cierto que es algo que deberíamos hacer pronto!

Ahora que ya tenemos un CRUD inicial y funcional, creo que es buen momento para empezar a incluir testing. Si seguimos expandiendo el código sin crear esta costumbre, probablemente este proyecto se vuelva inmantenible más temprano que tarde.

En este sentido, se adjuntan un par de recursos para poder implementar y decidir la mejor manera de agregar estas pruebas:

1. Este video por parte de Roberto Huertas, parte de una serie de videos sobre Actix en español. Quizás esté desactualizado! debido a que lleva más de dos años arriba.
2. La sección de pruebas en la documentación oficial de Actix.

Tu propuesta es relacionada a un problema? describe
Actualmente el funcionamiento de la API se hace sin autenticación de ningún tipo. El primer paso debería ser implementar una autenticación simple y uniforme. Es probable que prontamente se necesite complejizar de alguna u otra forma el proceso de autenticación para soportar distintos niveles de permisos, pero creo que en lo pronto no es necesario!

Describe la solución que te gustaría
La solución debería probablemente involucrar la creación de un API-TOKEN manualmente para cada usuario a utilizar la API, y no un método de autorización extraordinario como usuario y contraseña hacia un JWT.
Los detalles que considero actualmente son:

• Los tokens deben, si o si, ser encriptados.
• Los tokens deben estar acompañados por un nivel de autorización arbitrario. Probablemente se respete la misma mecánica de encargado y miembro de club, al menos en un principio. A nivel de implementación, esto puede tratarse con un Enum y ya, en caso de necesitarse nuevos roles, se pueden agregar al enum y jugar a recompilar.
• El middleware debería simplemente rechazar el request si no existe la autorización, en vez de mostrar 404 o algo similar. Da igual ocultar información en principio.

Describe alternativas que hayas considerado
Pensé en un inicio el proceso de JWT, pero creo que habilitar endpoints para crear cuentas, recuperar contraseñas y quien sabe que otra cosa, lo hace muy difícil de manejar.

Tu propuesta es relacionada a un problema? describe

El proceso de montar la API no es tan directo como me gustaría.
Debería haber una forma de montarla de forma más sencilla a través de Docker / Docker compose.

Describe la solución que te gustaría

En vez de pasar por la cantidad de comandos necesarios, simplemente hacer algo tipo docker run en la terminal debería bastar para armar la API.

Describe alternativas que hayas considerado

Ninguna en particular

Contexto adicional

Ningún contexto adicional.

Tu propuesta es relacionada a un problema? describe

El club está en proceso de crear una nueva plataforma, vista en este repositorio. Parte importante de la funcionalidad de este repositorio será provista por la API, según entiendo. Aún falta discusión, pero me gustaría empezar a ver historias de usuario que crear acá.

Describe la solución que te gustaría

Existen dos cosas importantes: un repositorio donde los alumnos suben archivos relevantes; por ejemplo, archivos en formador PDF; y un foro de discusión a nivel de curso y de archivo.

Describe alternativas que hayas considerado

El repositorio creo que debería ser indexado con el algorito TF-IDF para proporcionar una forma de búsqueda por términos.

Los comentarios debería tener las siguientes propiedades:

• Autor
• Creación
• Contenido (formato Markdown)
• Curso donde se comentó
• Archivo donde se comentó (nulo en caso de ser un comentario sobre el curso).
• Comentario al que está respondiendo (genera una especie de árbol de comentarios).

Contexto adicional

Ver las reuniones en Notion.