Contenido del curso

Introducción

REST

WebSockets

Cierre

Tomar examen

Struct de Hub para conexiones

Comentarios

Carlos Nexans

student•

Creo que para este ejercicio en particular, un array no es la estructura de datos mas apropiada. Siendo que el caso de uso de guardar todos los clientes en una estructura de datos es poder hacer broadcast, creo que un mapa nos ayudaria más. Podemos recorrer el mapa al igual que el array y, agregar y eliminar registros es mucho más eficiente y rápido que con un slice. Insertar y eliminar en un mapa es O(1) amortizado, mientras que Copy es O(n)

Àlex Grau Roca

student•

Puede ser, pero ten en cuenta que el acceso a un slice es MUCHO más eficiente que el acceso a un map. Con mi corta pero intensa experiencia con Go, en caso de gran volumen de datos, procesos u operaciones siempre me ha compensado muchísimo más utilizar slices que no utilizar maps. Para tener un orden de magnitud pasé de realizar 3.500M de operaciones en 8 minutos a realizarlas en 8 segundos, solamente convirtiendo maps a slices. Para este caso concreto debería realizar un stress test para ver realmente si es más eficiente o no, ya que quizás para el uso que se le da si resulte mejor utilizar map. . Internamente, aunque nosotros estemos realizando un acceso directo al map, esto realiza más funciones internas distintas para encontrar esa posición en el map (especialmente con strings), mientras que recorrer un slice y acceder a una posición determinada es extremadamente eficiente (ahora no me acuerdo como operaba internamente).

Carlos Nexans

student•

Buen comentario, Alex, estoy muy agradecido que agregues insight valioso en este hilo.

Coincido que se puede tomar un approach más científico y hacer un stress test. Por otro lado, habría que analizar si el servicio se orienta a muchas escrituras en la ED ó a muchas lecturas.

El mapa es O(1) amortizado, aunque es cierto que los strings producen complejidad añadida, dado que se debe hashear y manejar la colisión (elementos con el mismo hash).

Con el el slice entiendo que debes poder llegar a la dirección de memoria más directamente, sin embargo, al agregar un elemento nuevo, es posible que debas reservar otro bloque de memoria más grande y copiar todo lo que tenías (aumentar el capacity), lo mismo sucede cuando eliminas.

Otra opción que, a priori, me parece apropiada, aunque debe someterse a pruebas, es usar una estructura de arbol binario de búsqueda. De esta forma, agregar y eliminar un elemento debería ser O(log2 n) en lugar de O(n), sin necesidad de manejar hashes y colisiones.

Estaría bueno hacer un curso donde se vaya más a detalle con estas cuestiones de Go, estudiar y aplicar optimizaciones en aplicaciones y servicios. Para ahorrar en infraestructura y producir servicios más rápidos en pos de la experiencia del usuario, todo esto suma muchísimo.

De nuevo, muchas gracias por agregar feedback, me sirve mucho. Te mando un saludo.

Camilo Andres Agudelo

student•

Siento que hay partes que aun que lo explica, lo hace para el.. no siento que las explique para personas que apena están aprendiendo..

Edwin García

student•

¿Para remover un cliente del slice de clientes no es más fácil así?

Victor Baruch Pazaran Jaimes

student•

La parte donde remueve el cliente de la lista de clientes me parecio demaciado compleja sin sentido

Yo la refactorice de la siguiente forma para hacerla un poco mas simple y entendible a simple vista

// Removing the client from the clients slice
	var clientIndex int
	for index, client := range hub.clients {
		if client.id == client.id {
			clientIndex = index
			/* 
			↓ Se re-crea el slice SOLO con los elementos que estaban antes y despues
			(esto elimina solo ese cliente al no incluirlo en el nuevo slice) 
			*/
			hub.clients = append(hub.clients[:clientIndex], hub.clients[clientIndex+1:]...)
			break
		}
	}

Leonardo Aranguren

student•

que ocurrio aqui? alguien podria explicarlo detalladamente

copy(hub.clients[i:], hub.clients[i+1:])
	hub.clients[len(hub.clients)-1] = nil
	hub.clients = hub.clients[:len(hub.clients)-1]

Juan David Sierra

student•

En pocas palabras, desplazo el elemento al anterior, desde el indice que se encontro, eso fue el copy, ejempl, 1,2,3,4 -> 2,3,4,4. El valor del ultimo, al ya estar en el penultimo, lo convierte en null, ej:2,3,4, nil y toma todos los valores que no sean nil, para eso es el -1, ej: ub.clients = 2,3,4

Victor Baruch Pazaran Jaimes

student•

Aqui está eliminando el client con el indice "i" del slice de clientes, el slice se llama "hub.clients" y el elemento que se desea eliminar está en la posición "i".

Paso a paso, lo que sucede es:

La función "copy" está copiando los elementos desde la posición "i" hasta el final del slice "hub.clients", y los está pegando en la misma posición "i" del slice, reemplazando el elemento en "i". Después, se establece el último elemento del slice "hub.clients" como "nil". Por último, se está redefiniendo el tamaño del slice "hub.clients" a "len(hub.clients) - 1", eliminando el último elemento.

Àlex Grau Roca

student•

Cuando se asigna el i = j, es decir, cuando encontramos al cliente, lo suyo es hacer un break para salir del for y no consumir unos recursos innecesarios.

Jhordy Miguel Caceres Guerra

student•

Deben arreglar el audio, no esta sincronizado correctamente. ya van varios días así y nadie del equipo de platzi se anuncia por acá, pareciera que no les interesa, espero equivocarme.

Fernando José Aguilar Rivas

student•

El audio de esta clase no esta bien

Jesus Camacaro

student•

El audio se encuentra desfasado

Carlos Nexans

student•

Es necesario cerrar el candado para escribir el id del cliente? Se podria trasladar esa operacion al constructor.

Carlos Eduardo Magallon Zepeda

student•

El audio de la clase está desfasado, de todas formas se entiende perfectamente en cuanto aparece el código porque la imagen del profesor queda super pequeña, de cualquier forma estaría genial que lo corrigieran.

func (hub *Hub) onDisconnect(client *Client) {
	log.Println("Client Disonnected", client.socket.RemoteAddr())
	// Remember to prevent race conditions
	client.socket.Close()
	hub.mutex.Lock()
	defer hub.mutex.Unlock()
	i := -1
        // itera hasta que la id del cliente sea igual que el client.id
	for j, c := range hub.clients {
		if c.id == client.id {
			i = j
		}
	}
       // en el punto en el que las id son iguales, creamos un array que lo excluya
	copy(hub.clients[i:], hub.clients[i+1:])
	hub.clients[len(hub.clients)-1] = nil
	hub.clients = hub.clients[:len(hub.clients)-1]
}

// Removing the client from the clients slice
	var clientIndex int
	for index, client := range hub.clients {
		if client.id == client.id {
			clientIndex = index
			/* 
			↓ Se re-crea el slice SOLO con los elementos que estaban antes y despues
			(esto elimina solo ese cliente al no incluirlo en el nuevo slice) 
			*/
			hub.clients = append(hub.clients[:clientIndex], hub.clients[clientIndex+1:]...)
			break
		}
	}

func (hub *Hub) onDisconnect(client *Client) {
	log.Println("Client Disonnected", client.socket.RemoteAddr())
	// Remember to prevent race conditions
	client.socket.Close()
	hub.mutex.Lock()
	defer hub.mutex.Unlock()
	i := -1
        // itera hasta que la id del cliente sea igual que el client.id
	for j, c := range hub.clients {
		if c.id == client.id {
			i = j
		}
	}
       // en el punto en el que las id son iguales, creamos un array que lo excluya
	copy(hub.clients[i:], hub.clients[i+1:])
	hub.clients[len(hub.clients)-1] = nil
	hub.clients = hub.clients[:len(hub.clients)-1]
}

Introducción

Introducción al curso

¿Qué estaremos construyendo?

HTTP y REST

CRUD

REST

Inicialización de módulo e instalación de dependencias

Struct Server

Nuestro primer endpoint

Definiendo el modelo de usuarios

Patrón repository

Registro de usuarios

Implementando el registro

Probando los registros

Autenticación de usuarios

Probando el login

Middleware de validación de autenticación

Implementando el middleware

Modelo Posts

CRUD para Posts

Paginación para Posts

WebSockets

Websockets

Upgrader y Endpoint para Websocket