Closed mdelapenya closed 5 years ago
Ummmm en realidad no estamos completando la funcionalidad del endpoint no? simplemente estamos añadiendo el endpoint con la funcionalidad para respuesta si no hay plants. No sé si no deberíamos detallas mas nuestras issues en las descripciones, así como unos títulos mas acordes con la funcionalidad que se describe posteriormente.
En otro orden de cosas creo que podríamos adoptar el modelo de descripción de tu PR como una template de pr. Creo que se pueden crear en github.
Voy a crear una issue para el github template: https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository
En cuanto a la implementación del endpoint, por eso la PR está en DRAFT :trollface:, voy a ir subiendo commits progresivamente
El tema es que si pones revisores y la PR está en draft, cada vez que subas un commit el revisor como sabe si ya esta definitivo el estado y debe revisarla?
Cuando el author quita el estado de DRAFT, pero es cierto que mientras tanto, se puede dar feedback de lo implementado. Mientras no se hagan push-force de lo anterior a una posible revisión, no veo problemas
¿Qué hace esta PR?
Esta PR iniciar un proyecto Go utlizando Go modules como sistema gestor de dependencias.
Además, instala las dependencias de Gin-Gonic, un framework para crear APIs REST de una manera muy sencilla, y añade un primer endpoint para el método /GET/plants
¿Por qué es importante?
Es importante porque sienta las bases del stack del proyecto (Go + Gin), de modo que el resto del backend se debería continuar utilizando este stack
Issues relacionadas
Closes #5
Consideraciones
Si alguno piensa que pudiéramos tirar por otro stack, lo discutimos en esta PR (o en la issue #5)