¿Cómo implementar un nuevo servicio en el servidor gRPC?
En el emocionante mundo del desarrollo de servicios con gRPC, dar vida a un nuevo servidor puede parecer un desafío, pero con una guía clara, estarás en camino de crear servicios robustos y eficientes. Aquí exploramos cómo implementar un nuevo servicio, el servidor gRPC, paso a paso, desde la estructura de la base de datos hasta la implementación final en Go.
¿Cómo se define la nueva tabla en la base de datos?
Para iniciar, se debe crear una nueva tabla en SQL. Esta tabla se denominará test y se compondrá de un ID tipo Varchar que actuará como llave primaria y un nombre que no puede ser nulo. Antes de construirla, es esencial asegurarse de eliminar cualquier existencia previa de la tabla para evitar conflictos.
DROPTABLEIFEXISTS test;CREATETABLE test ( ID VARCHARPRIMARYKEY, nombre VARCHARNOTNULL);
¿Cómo se estructuran los modelos en Go?
En Go, los modelos se definen usando structs. Un nuevo struct llamado Test se creará con los campos ID y nombre, ambos de tipo string.
type Test struct{ ID string Nombre string}
¿Cómo se modifica el repositorio para soportar el nuevo modelo?
Se deben agregar métodos al repositorio para manejar las operaciones del nuevo modelo:
getTest: recibe un contexto y un ID, y devuelve un modelo Test y un error.
setTest: recibe un contexto y un Test, y devuelve un error.
Estos métodos deben implementarse tanto a nivel abstracto como en la especificidad del repositorio, por ejemplo, en PostgreSQL.
func(r *Repo)GetTest(ctx context.Context, id string)(*models.Test,error){// implementación}func(r *Repo)SetTest(ctx context.Context, test *models.Test)error{// implementación}
¿Cómo crear el nuevo servidor gRPC?
En el directorio server, se crea un nuevo archivo test.go para manejar el nuevo servicio. Aquí se define el TestServer usando composición sobre herencia para implementar el UnimplementedTestServiceServer del archivo testpb.
type TestServer struct{ repo Repository
testpb.UnimplementedTestServiceServer
}funcNewTestServer(repo Repository)*TestServer {return&TestServer{repo: repo}}
¿Qué funciones manejarán las solicitudes gRPC?
Es fundamental implementar las funciones getTest y setTest para el servidor.
La etapa final consiste en registrar tu nuevo servidor con gRPC. En un nuevo directorio server_test, crea el main.go que instanciará el servidor en un puerto único. Activa la reflexión para facilitar la interacción con herramientas como Postman.
funcmain(){ server := grpc.NewServer() repo :=// crear e inicializar repositorio testpb.RegisterTestServiceServer(server,NewTestServer(repo))// otros detalles de inicialización}
¿Cómo se ejecuta y prueba el nuevo servidor?
Una vez compilados los cambios, inicia el nuevo servidor y verificar con Postman o cualquier cliente gRPC configurado para interactuar con él. Realiza pruebas para los métodos setTest y getTest, asegurando que la interacción y la gestión de datos sean fluidas y efectivas.
Con todo esto implementado, no solo has añadido un nuevo servicio a tu servidor gRPC, sino que has incrementado la robustez y flexibilidad de tu aplicación. Prepárate, porque el mundo del streaming de gRPC es el próximo paso hacia un desarrollo aún más innovador.
La verdad que esta clase me parece bastante mala, nos aparece un server/tests.go por arte de mágia y el levantamiento del docker lo hace saltándose pasos que los estudiantes tenemos que hacer.
.
Si alguien tiene problemas a la hora de hacer los tests, el tema está en que el up.sql está incluido dentro de la imagen que se utiliza para levantar el contenedor. Para hacer que el nuevo servidor de postgres se levante con el nuevo up.sql, se tiene que volver a generar el build.
.
Una alternativa puede ser la de utilizar bindmounts (es lo que yo he realizado). Para esto he movido el database/up.sql a database/initdb/1.sql. Luego he elminado el COPY del Dockerfile, lanzando de nuevo el build para tener una nueva imagen. Finalmente, a la hora de levantar el contenedor hay que utilizar el siguiente comando:
docker run -p 54321:5432-v {{AbsolutePathToProject}}database/initdb:/docker-entrypoint-initdb.d platzi-grpc-db
Donde {{AbsolutePathToProject}} es el path absoluto a vuestro proyecto. Con el flag -v se realiza el binmound de PathLocal:PathContenedor, de modo que el contenido de la carpeta local estará disponible en el contenedor y viceversa.
Me he dejado añadir que con este comando, cada vez que se levante un nuevo servidor se utilizará la versión actual del 1.sql, de modo que no hay que rehacer la imagen constantemente. También tened en cuenta que con cada run estamos generando un contenedor completamente nuevo.
La verdad que sí, intenté fixear el problema de la manera que sugeris y no pude.. Pienso avanzar dejando solo students funcionando. Veré más adelante, complementando con algun curso de docker como buildear esos nuevos cambios. Porque errores de compilación no tengo.
Muchas gracias!
Hola, les dejo el tests.go base que se supone que hemos realizado en alguna clase que yo no he llegado a ver...
Básicamente es lo mismo que el servidor que ya levantamos, pero apuntando a TestServer, así como los pb de test.
Una recomendación para minimizar la posibilidad de confusión en un futuro con los test de Go, es nombrar la tabla de exámenes como Exam en vez de test.
Que clase tan confusa. Parece que cortaron un pedazo al inicio.
¿No falta una clase por medio? xD Al principio indica "ya creamos nuestro servidor de test" pero solamente definimos el Proto y por arte de magia aparece el server/tests.go definido...
Está perdido este Néstor lo único que hace es leer código
¿Porque se crea un nuevo servidor para "Test" en vez de usar el mismo que se tenia para "Students"?
En caso de que alguien este perdido con el server/test.go les dejo el mio
Les dejo el docker compose file que use para no tener que hacer build cada vez que se cambie algo en el archivo sql, me es mas facil asi que usando el comando completo del run