Contenido del curso
Modelos y repositorios
Mensajes y eventos
Indexación mediante Elastic Search
Feed Service
Query Service y Pusher
Últimos pasos
Creando el Servicio Pusher
Àlex Grau Roca
Estudiante
Christopher Vilches
EstudianteContenido del curso
Creando el Servicio Pusher
Àlex Grau Roca
EstudianteChristopher Vilches
Estudiante
Cristóbal Contreras
EstudianteConsejo: en lugar de nombrar helper.go, lo mejor es nombrar el fichero a partir del nombre del struct, ya que es más explícito su contenido. Nombrar los ficheros con nombres abstractos no es una buena práctica, igual como ocurre con las variables, funciones, clases... ya que al final te puedes volver loco tratando de buscar y entender como funciona el código. :) . Otra cosa que no termino de ver es dejar para el final el testeo de todo. Estamos hablando de servicios que son independientes, ya que el nexo común entre ellos es nats, por lo que lo suyo hubiera sido ir validando cada servicio al terminarlo. Es mejor ir haciendo validaciones poquito a poquito (además de implementar TDD), que no hacer una megavalidación final, donde pueden empezar a aparecer miles de errores por un montón de sitios y puedes perder la cabeza.
No estoy 100% de acuerdo con lo de nombrar el archivo usando el nombre del struct que haya dentro. En Go no hay ninguna restriccion de que poner dentro de un archivo, puedes poner multiples structs, funciones, etc, y eventualmente alguien podria agregar mas cosas de las que inicialmente pusiste, por lo tanto crear una dependencia entre nombre y contenido y asumir que esa dependencia esta correcta (lo cual tendrias que validar manualmente, ya que Go no te arrojara warnings por tener structs con nombres distintos al archivo) hace que sea mas confuso. En mi opinion lo mejor es poner un nombre generico y abstracto sobre el topico o tematica del archivo (en modo general), no de funciones o structs especificos.
go get github.com/gorilla/websocket