go get github.com/gorilla/websocket
Introducción
¿Qué estaremos construyendo en el curso?
Microservicios y arquitecturas basadas en eventos
CQRS: Command Query Responsibility Segregation
Modelos y repositorios
Creando modelos y repositorios
Implementando repositorio
Mensajes y eventos
Agregando NATS
Definiendo mensajes y eventos
Implementado interfaces para mensajes y eventos
Reaccionando a eventos
Indexación mediante Elastic Search
Agregando indexación
Implementando indexación mediante Elastic Search
Búsqueda mediante Elastic Search
Serialización de resultados de Elastic Search
Feed Service
Creando Feed Service
Creando Handlers para Feed Service
Agregando Feed Service como Command
Query Service y Pusher
Creando Query Service
Creando Handlers para Query Service
Creando el Servicio Pusher
Últimos pasos
Agregando NGINX
Probando nuestra aplicación de Feeds
Conclusiones
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Aportes 2
Preguntas 0
go get github.com/gorilla/websocket
Consejo: 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.
Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Regístrate o inicia sesión para participar.