Hola no me conoces pero he estado viendo varios videos tuyos que me han sido de mucha utilidad, como este. El contexto es una de esas cosas que me había costado bastante entender y con este video logré comprenderlo, mi único feedback sería que dieras el contexto de lo que significa el context.Background ya que personas como yo que desconociamos totalmente este concepto nos perdemos un poco. Encontrar información de go en video es algo que la verdad cuesta bastante y por eso mismo te agradezco mucho por sompartir tus conocimientos con los demás. Si algún decides hacer un curso completo desde lo más básico hasta lo más complejo sin duda seré una de las primeras personas en inscribirme. Nuevamente muchas gracias por compartir con nosotros tus conocimientos y espero que sigas haciendolo a futuro.
Gracias por tu comentario y por tu feedback! lo aprecio mucho! En siguientes videos vamos a usar el context en el proyecto de arquitectura hexagonal! Y el curso es un proyecto que tengo pausado! Nada me gustaría más que tener el tiempo y recursos para crearlo, esperemos que siga creciendo el canal para justificar la inversión de tiempo, que una hora de video son como 5 horas de trabajo jeje
Gracias a ti por tu tiempo! no olvides suscribirte, darle like, activar campanitas y todo lo de costumbre jaja estamos tratando de llegar a 1000 seguidorcitos para poder justificar la existencia del canal. Algún tema que te gustaría que tratáramos?
@@seniorgoespanol Se que la cultura que propone go es no usar frameworks pero estoy empezando a usar fiber por su rapidez. Por esa razón me gustaría un vídeo de este framework orientado a micro servicios de ser posible.
Duda, ¿Por qué no es recomendable pasar parámetros? Ejemplo, tengo una API Rest con el framework GIN, esta dependencia por defecto trae los parámetros en el contexto. Yo recibo el ID de un objeto por ruta (/api/:id) para poder buscar en la db el contenido del registro, ¿Es factible pasar por contexto este parámetro? ó ¿Es mejor mapearlo en una variable y luego pasar a la función (usando punteros)?
Esa es una excelente pregunta! Cuando se trata de frameworks sí hay que apegarse a lo que el framework indica. Y en este caso al ser un "named parameter" de un request es muy comun que los frameworks proporcionen el acceso por medio del contexto por dos razones: - el framework es el que controla el mecanismo de obtener el named parameter (en tu caso :id) - los named parameters son, por así decirlo, "indefinidos". Y con esto me refiero a que tu handler generalmente no los puede recibir directamente como parámetros porque la mayoría de las veces requieren una firma específica que el framework necesita (en el caso de gin creo que es func(c *gin.Context)), no puedes modificar esa firma para recibir directamente un parámetro "id string" porque entonces tu handler ya no sería "compatible" con el framework. Cuando no es recomendable usar el contexto para pasar parámetros es en funciones que tú mismo definas, donde sí puedas agregar los parámetros directamente. Imagínate (es un ejemplo inventado) que tienes una función SaveEmployeeService(ctx context.Context, name string) que dentro manda llamar SaveEmployeeToDB(ctx context.Context, name string) que dentro manda llamar HashEmployee(ctx context.Context, name string). Y de pronto tienes un nuevo requerimiento de que aparte del name tienes que procesar el email y que es indispensable que siempre proceses también el email. Podría darnos flojera tener que agregar un nuevo parámetro a las tres funciones y podríamos pensar "ah pues lo meto en el contexto y así está accesible para todas". Eso es lo que sería un error, porque estarías pasando un parámetro indispensable para la función por un medio muy flexible como es el contexto. Nuevos usuarios de tu función SaveEmployeeService no tendrían forma directa de saber que necesitan, por fuerza, mandar un email. Espero haberme dado a entender, una disculpa por la carta jaja
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
exclente explicacion se me hacia muy dificil de entender hasta que vi este video muchisimas gracias por este aporte saludos.
Gracias por tu comentario! Algún otro tema con el que necesites ayuda?
La mejor explicación que he visto del tema. Gracias
Que honor saber eso hermano! muchas gracias!
Hola no me conoces pero he estado viendo varios videos tuyos que me han sido de mucha utilidad, como este. El contexto es una de esas cosas que me había costado bastante entender y con este video logré comprenderlo, mi único feedback sería que dieras el contexto de lo que significa el context.Background ya que personas como yo que desconociamos totalmente este concepto nos perdemos un poco.
Encontrar información de go en video es algo que la verdad cuesta bastante y por eso mismo te agradezco mucho por sompartir tus conocimientos con los demás. Si algún decides hacer un curso completo desde lo más básico hasta lo más complejo sin duda seré una de las primeras personas en inscribirme.
Nuevamente muchas gracias por compartir con nosotros tus conocimientos y espero que sigas haciendolo a futuro.
Gracias por tu comentario y por tu feedback! lo aprecio mucho! En siguientes videos vamos a usar el context en el proyecto de arquitectura hexagonal!
Y el curso es un proyecto que tengo pausado! Nada me gustaría más que tener el tiempo y recursos para crearlo, esperemos que siga creciendo el canal para justificar la inversión de tiempo, que una hora de video son como 5 horas de trabajo jeje
gran contenido super recomendable, con el tiempo me los vere todos!
un honor! gracias por el comentario!
Tremendo video! Muy bueno! Sube una serie explicando el paquete context con cada una de las funciones porfa!
Agregado a la lista hermano! espéralos tan pronto como nos sea posible!
Súper bien explicado, muchas gracias
Gracias! que bueno que te fuera útil!
buenos videos comp@ enhorabuena !!
Gracias! saludos!
Excelente!! Lo mejor de Go en español. Si pudieras dejar links con los códigos sería óptimo. Muchas gracias por tu tiempo y dedicación. Saludos
Dejaré el link al repo en los comentarios! Gracias por la sugerencia!
Excelente video hermano! como siempre. 👍
Gracias por tu apoyo! que bueno que te fuera útil!
Excelente explicacion.Gracias!
Gracias por tu comentario!
Excelente contenido gracias por compartir el conocimiento :)
Gracias a ti por tu tiempo! no olvides suscribirte, darle like, activar campanitas y todo lo de costumbre jaja estamos tratando de llegar a 1000 seguidorcitos para poder justificar la existencia del canal. Algún tema que te gustaría que tratáramos?
Excelente video
Gracias por tu comentario! Que bueno que te fuera útil!
Claro que sí. El contenido es excelente, directo y conciso. Muy bien explicado. Continua creando contenido. Gracias
Algún tema en especial del que te gustaría un video hermano? 🤓
@@seniorgoespanol Se que la cultura que propone go es no usar frameworks pero estoy empezando a usar fiber por su rapidez. Por esa razón me gustaría un vídeo de este framework orientado a micro servicios de ser posible.
@@nathenn Agregado a la lista mi estimado!
Gracias! Me sirvió mucho
Que honor que te sirviera amigo! Saludos!
buena explicacion!!!
Excelente canal 🦾💪
Gracias! desde dónde nos ves?
@@seniorgoespanol Paraguay
gran video!!!
que bueno que te agradara! algún tema que te interese que cubramos?
Duda, ¿Por qué no es recomendable pasar parámetros?
Ejemplo, tengo una API Rest con el framework GIN, esta dependencia por defecto trae los parámetros en el contexto. Yo recibo el ID de un objeto por ruta (/api/:id) para poder buscar en la db el contenido del registro, ¿Es factible pasar por contexto este parámetro? ó ¿Es mejor mapearlo en una variable y luego pasar a la función (usando punteros)?
Esa es una excelente pregunta! Cuando se trata de frameworks sí hay que apegarse a lo que el framework indica. Y en este caso al ser un "named parameter" de un request es muy comun que los frameworks proporcionen el acceso por medio del contexto por dos razones:
- el framework es el que controla el mecanismo de obtener el named parameter (en tu caso :id)
- los named parameters son, por así decirlo, "indefinidos". Y con esto me refiero a que tu handler generalmente no los puede recibir directamente como parámetros porque la mayoría de las veces requieren una firma específica que el framework necesita (en el caso de gin creo que es func(c *gin.Context)), no puedes modificar esa firma para recibir directamente un parámetro "id string" porque entonces tu handler ya no sería "compatible" con el framework.
Cuando no es recomendable usar el contexto para pasar parámetros es en funciones que tú mismo definas, donde sí puedas agregar los parámetros directamente.
Imagínate (es un ejemplo inventado) que tienes una función SaveEmployeeService(ctx context.Context, name string) que dentro manda llamar SaveEmployeeToDB(ctx context.Context, name string) que dentro manda llamar HashEmployee(ctx context.Context, name string). Y de pronto tienes un nuevo requerimiento de que aparte del name tienes que procesar el email y que es indispensable que siempre proceses también el email. Podría darnos flojera tener que agregar un nuevo parámetro a las tres funciones y podríamos pensar "ah pues lo meto en el contexto y así está accesible para todas". Eso es lo que sería un error, porque estarías pasando un parámetro indispensable para la función por un medio muy flexible como es el contexto. Nuevos usuarios de tu función SaveEmployeeService no tendrían forma directa de saber que necesitan, por fuerza, mandar un email.
Espero haberme dado a entender, una disculpa por la carta jaja
@@seniorgoespanol
Muchas gracias por la explicación (lamento responder apenas, jajaja).
estado global, igual que context api de react, pdta estoy aprendiendo backend
Tal cual
si estoy en 2024 casi 2025 aun me sigue funcionando este video o llegue tarde? XD Nota: toy repasando
@@Golandia claro que te sirve! Son cosas básicas pero elementales :D saludos!