Esta clase explica como codificar el servidor, las siguientes notas te pueden ayudar:
Estructuras:
Config: tiene las caracteristicas del servidor. El puerto en el que se va ejecutar, la clave secreta para generar tokens y la conexion a base de datos.
broker: Nos ayuda a tener varias instancias de servidor corriendo. Esta estructura a su vez tiene la estructura Config y el metodo Config, para ser de tipo Server.
Interface:
server: esta interface implementa el modelo de datos o estructura de config.
Gracias!! Directo a mis apuntes 👍🏼
2 preguntas:
cual extension del IDE utilizas? que te marca en gris claro lo que sigue para autocompletar?
que es binder()? porque se utilizo
Tengo la misma inquietud, Que extension utiliza el profesor?
Durante todos los cursos se viene trabajando con la de Go v0.33.1 que seria la oficial, (Rich Go language support for Visual Studio Code).
Veo un comportamiento distinto en el editor del profesor, le autocompleta cosas diferentes.
La extension de auto completar es Github Copilot
que es binder? porque se utiliza
Algo que no me queda claro es porque en la funcion Start() recibe otra funcion , y porque binder? por convencion? o solo es manera del desarrollador organizar el codigo?
Una alternativa mejor a gorilla es fasthttp:
- Evita asignaciones de memoria "allocations" y el garbage collector. Reutiliza buffers de memoria.
- Reemplaza la estandar net/http y construye con su propia implementacion, a diferencia de gorilla
Explicacion de la funcion binder.func main() { config := &Config{ Port: "8080", JWTSecret: "mysecret", DatabaseUrl: "postgres://...", } server, err := NewServer(context.Background(), config) if err != nil { log.Fatal(err) } server.Start(func(s Server, r *mux.Router) { r.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) { w.Write([]byte("Hola Mundo")) }) }) }
La función binder en este código tiene como propósito configurar las rutas del servidor, pero de una forma flexible y externa a la lógica principal del servidor, Es como una especie de "callback" para configurar las rutas antes de que el servidor inicie.
La idea de pasarlo como parámetro es darle flexibilidad al servidor para que otra parte del codigo se quien decida cómo configurar las rutas, sin tener que modificar el código del servidor en sí. Es como si te dieran una casa (el servidor) y te dijeran: "Configura las habitaciones (rutas) como tú quieras, aquí tienes los planos".
Ejemplo Sencillo:
func main(){config:=&Config{Port:"8080",JWTSecret:"mysecret",DatabaseUrl:"postgres://...",} server,err:=NewServer(context.Background(), config)if err != nil { log.Fatal(err)} server.Start(func(s Server, r *mux.Router){ r.HandleFunc("/hello",func(w http.ResponseWriter, r *http.Request){ w.Write([]byte("Hola Mundo"))})})}
¿Por qué usamos b.config.Port y b.Config().Port para acceder al puerto? ¿Cuál es la diferencia? si ambos acceden igual... Entiendo que se usa el método Config para implementar la interfaz y así pasar como parametro Server en la funcion Binder, pero realmente es necesario implementar la interfaz así?.
Quiero pensar que la respuesta se encuentra en las clases siguientes.
En esta parte el parametro de ctx no se usa aun, creo que faltó esa parte
No es aporte sino comentario:
Bastante difícil de digerir, no se sabe cuando se usa NewServer, que es context.Context, se me dificultad ver el uso de binder.
Hola Clever, el NewServer es el constructor, el binder es explicado más adelante
Hola espero respuesta, si es que se sigue respondiendo, mi pregunta: en el constructor del server (NewServer) hay algun problema porque no se utiliza el parametro ctx?
llega este a las llamadas a r.Context() luego?
gracias.
donde me puedo bajar los archivos de este curso ???
Revisa la sección Recursos debajo del vídeo o comunícate vía email con team@platzi.com en caso no los encontraras. 🙆♂️
La clase munero 6 es la que sigue despues de la 4 y luego sigue esta clase
En este ejemplo se observa que se está utilizando un struct Server junto con un constructor NewServer y un método Start que recibe una función para configurar rutas. Esto permite centralizar la configuración y la ejecución del servidor en una sola instancia, lo que se parece a un patrón Singleton, ya que se crea y maneja un único servidor que controla toda la aplicación y sus rutas. Además, el uso de Config dentro del struct refuerza la idea de encapsular la configuración en un solo objeto, siguiendo principios de organización y modularidad en la arquitectura del servidor.
