Mostrando entradas con la etiqueta grpc. Mostrar todas las entradas
Mostrando entradas con la etiqueta grpc. Mostrar todas las entradas

viernes, 27 de marzo de 2026

Programando en C# no. 14: gRPC con .NET

 

En el post pasado vimos cómo crear un sencillo proyecto tipo cliente-servidor con .Net y gRPC.

Continuando con el tema vamos a recordar un poco.

  • gRPC es una tecnología moderna ideal para microservicios de alto rendimiento, escalables y seguros. 
  • Protobuff es el mecanismo de serialización que usa gRPC
  • HTTP/2 como protocolo de comunicación, el cual prioriza solicitudes, permite la comprensión de encabezados, multiplexación (múltiples llamadas simultáneas) y tiene mayor seguridad.

Creando un proyecto cliente-servidor en .Net (C#)

Crearemos un proyecto cliente-servidor en el cual el cliente mandará un número entero y el servidor evaluará si es mayor o no a 100.

1. Creamos nuestro proyecto servidor:

$ dotnet new grpc -o GrpcServer

2. Entramos al directorio creado y agregamos los siguientes Nuget:

Por línea de comandos:

$ dotnet add package Grpc.AspNetCore
$ dotnet add package Google.Protobuf
$ dotnet add package Grpc.Tools

Desde el archivo ``GrpcServer.csproj``:

<ItemGroup>
  <PackageReference Include="Grpc.AspNetCore" Version="2.60.0" />
  <PackageReference Include="Google.Protobuf" Version="3.25.0" />
  <PackageReference Include="Grpc.Tools" Version="2.60.0" PrivateAssets="All" />
</ItemGroup>

Ejecutar esto para descargar paquetes:

$ dotnet restore

3. Crearemos un archivo *.proto, el cual tendrá el un servicio llamado Validar y un método llamado EsMayorQue100 que recibirá un NumeroRequest y devolverá un NumeroResponse.

Protos\validar.proto

syntax = "proto3";

option csharp_namespace = "GrpcDemo";

package validar;

service Validar {
  rpc EsMayorQue100 (NumeroRequest) returns (NumeroResponse);
}

message NumeroRequest {
  int32 valor = 1;
}

message NumeroResponse {
  bool es_mayor = 1;
}

4. Editamos el archivo ``GrpcServer.csproj`` para agregar el archivo *.proto:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <ItemGroup>
    <!--<Protobuf Include="Protos\greet.proto" GrpcServices="Server" />-->
	<Protobuf Include="Protos\validar.proto" GrpcServices="Server" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Google.Protobuf" Version="3.34.1" />
    <PackageReference Include="Grpc.AspNetCore" Version="2.76.0" />
    <PackageReference Include="Grpc.Tools" Version="2.78.0">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>

</Project>

5. Creamos el servicio:

ValidarService.cs

using GrpcDemo;
using Grpc.Core;

public class ValidarService : Validar.ValidarBase
{
    public override Task<NumeroResponse> EsMayorQue100(NumeroRequest request, ServerCallContext context)
    {
        bool resultado = request.Valor > 100;
        return Task.FromResult(new NumeroResponse { EsMayor = resultado });
    }
}

6. El programa principal del servidor será el siguiente:

Program.cs

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddGrpc();
var app = builder.Build();
app.MapGrpcService<ValidarService>();
app.Run();

Ahora vamos por el proyecto cliente.

7. Creamos el proyecto:

$ dotnet new console -o GrpcClient

8. Nos ubicamos en el directorio creado. Y configuramos el archivo ``GrpcClient.csproj``:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  
  
  
  <ItemGroup>
  <Protobuf Include="..\GrpcServer\Protos\validar.proto" GrpcServices="Client" />
</ItemGroup>
<ItemGroup>
  <PackageReference Include="Grpc.Net.Client" Version="2.60.0" />
  <PackageReference Include="Google.Protobuf" Version="3.34.1" />
  <PackageReference Include="Grpc.Tools" Version="2.78.0" PrivateAssets="All" />
</ItemGroup>


</Project>

Ejecutar esto para descargar paquetes:

$ dotnet restore

9. El programa principal del cliente será este:

Program.cs

using Grpc.Net.Client;
using GrpcDemo;

class Program
{
    static async Task Main(string[] args)
    {
        using var channel = GrpcChannel.ForAddress("http://localhost:5203");
        var client = new Validar.ValidarClient(channel);

        Console.Write("Ingrese un número: ");
        int numero = int.Parse(Console.ReadLine());

        var response = await client.EsMayorQue100Async(new NumeroRequest { Valor = numero });
        Console.WriteLine($"¿Es mayor a 100? {response.EsMayor}");
    }
}

10. Ejecutamos el servidor:

$ dotnet run --project GrpcServer

11. Ejecutamos el cliente:

$ dotnet run --project GrpcClient

Si todo va bien veremos esto en el servidor:

info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5203
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]

Del lado del cliente:

Ingrese un número: 23
¿Es mayor a 100? False

Podemos modificar el programa cliente de tal manera que solicite salir o continuar.

using Grpc.Net.Client;
using GrpcDemo;

class Program
{
    static async Task Main(string[] args)
    {
        using var channel = GrpcChannel.ForAddress("http://localhost:5203");
        var client = new Validar.ValidarClient(channel);

        string continuar;
        do
        {
            Console.Write("Ingrese un número: ");
            int numero = int.Parse(Console.ReadLine());

            var response = await client.EsMayorQue100Async(new NumeroRequest { Valor = numero });
            Console.WriteLine($"¿Es mayor a 100? {response.EsMayor}");
            Console.WriteLine();

            Console.Write("¿Desea continuar [s-n]? ");
            continuar = Console.ReadLine()?.Trim().ToLower();
            Console.WriteLine();

        } while (continuar == "s");

        Console.WriteLine("Adios");
    }
}

Salida:

Ingrese un número: 23
¿Es mayor a 100? False

¿Desea continuar [s-n]? s 
Ingrese un número: 200
¿Es mayor a 100? True 

¿Desea continuar [s-n]? n 
Adios

¡Hemos creado un proyecto cliente-servidor con gRPC y .NET!

Continuaremos con este tema en próximas entregas.

Enlaces:

https://codemonkeyjunior.blogspot.com/2026/02/grpc-una-alternativa-para-servicios-de.html
https://alquimistadecodigo.blogspot.com/2026/03/grpc-con-go.html
https://alquimistadecodigo.blogspot.com/2026/03/grpc-con-python.html


martes, 24 de febrero de 2026

gRPC: una alternativa para servicios de alto rendimiento

gRPC (google Remote Procedure Calls) es un framework que nos sirve para realizar llamadas a procedimientos remotos.

Es de alto rendimiento. Multilenguaje (clientes y servidores). Además de tener un Streaming avanzado, lo que permite comunicaciones tipo: unary, server streaming, client streaming y streaming bidirectional.

Es ideal para microservicios gracias a su alto rendimiento, tipado fuerte y soporte multiplataforma.

Ya hemos hecho una comparativa entre otras alternativas como GraphQL:

gRPC y GraphQL

Usa Protocol buffers (*.proto) como mecanismo de serialización (y deserialización); el cual es un formato binario, más pequeño, rápido y sencillo que XML y JSON. Además de soportar diversos lenguajes como: Java, Python, Go, etc.

También usa HTTP/2 como protocolo de comunicación, el cual es una mejora del HTTP clásico. El cual prioriza solicitudes, permite la comprensión de encabezados, multiplexación (múltiples llamadas simultáneas) y tiene mayor seguridad.

Empezando con gRPC y .NET

Crearemos una aplicación Cliente-Servidor para mostrar el uso de gRPC. Como lenguaje base usaremos C# y la herramienta dotnet para crear los proyectos.

Quien ha trabajado con aplicaciones Cliente-Servidor podrá entender el flujo. Una aplicación Cliente hará solicitudes y el Servidor las atenderá.

Para este ejemplo necesitaremos crear:

  • Un proyecto servidor. 
  • Un proyecto cliente.

Empecemos con el Servidor

Creamos el proyecto servidor con soporte a gRPC:

$ dotnet new grpc -o GrpcServer
$ cd GrpcServer

Una vez ubicados en el directorio podemos ejecutarlo:

$ dotnet run

Abrimos el navegador en la ruta: http://localhost:5057

Si todo va bien, veremos un mensaje.

Continuemos con el Cliente

Creamos el proyecto cliente de tipo consola:

$ dotnet new console -o GrpcClient
$ cd GrpcClient

Una vez ubicados en el directorio del Cliente, copiamos el directorio y archivo Protos\greet.proto del proyecto Servidor al Cliente.

Editamos el archivo GrpcClient.csproj de para agregar el archivo copiado. De tal manera que quede de esta forma:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Google.Protobuf" Version="3.33.5" />
    <PackageReference Include="Grpc.Net.Client" Version="2.76.0" />
    <PackageReference Include="Grpc.Tools" Version="2.78.0">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
	
	<Protobuf Include="Protos\greet.proto" GrpcServices="Client" />

  </ItemGroup>

</Project>

El archivo Protos\greet.proto es el siguiente:

syntax = "proto3";

option csharp_namespace = "Greet";

package greet;


service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}


message HelloReply {
  string message = 1;
}

Este archivo *.proto define el contrato de comunicación entre Cliente y Servidor en gRPC, y permite a un Cliente enviar un nombre y recibir un saludo como respuesta.

Compilamos y ejecutamos el proyecto Cliente:

$ dotnet build
$ dotnet run

Si todo va bien, veremos algo como esto en el Cliente:

Respuesta del servidor: Hello Code Monkey Junior

Y en el Servidor:

Usando la configuración de inicio de C:\Users\HP\Documents\pruebasCSharp\pruebasGRPC\GrpcServer\Properties\launchSettings.json...
Compilando...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5057
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: C:\Users\HP\Documents\pruebasCSharp\pruebasGRPC\GrpcServer
info: GrpcServer.Services.GreeterService[0]
      The message is received from Code Monkey Junior

Este solo es un ejemplo de gRPC. Aún falta saber más de Protobuf y HTTP/2 a profundidad.

Como mencionamos con gRPC podemos crear aplicaciones con diversos lenguajes de programación.

Por ejemplo, si tenemos un servidor creado en lenguaje de programación C# no habrá problema que clientes hechos en otros lenguajes como Java, Python, Go, etc. puedan realizar solicitudes y recibir respuestas.

Continuaremos con este tema en próximas entregas.

Enlaces:

https://grpc.io/
https://protobuf.dev/
https://dotnet.microsoft.com
https://alquimistadecodigo.blogspot.com/2024/05/grpc-protobuff-protocol-buffers.html
https://alquimistadecodigo.blogspot.com/2024/05/grpc-en-java-y-protobuff.html

domingo, 25 de enero de 2026

gRPC y GraphQL en una comparativa

gRPC y GraphQL son dos de los protocolos de comunicación más utilizados actualmente en el desarrollo de APIs.

GraphQL es ideal cuando el cliente necesita controlar qué datos obtiene, evitando cargas innecesarias. Consultas flexibles y un solo endpoint para múltiples recursos.

gRPC destaca en rendimiento, streaming y comunicación entre microservicios gracias a su formato binario y contratos estrictos. Con una comunicación bidireccional y streaming.

Comparativa entre gRPC y GraphQL

He aquí una tabla comparativa entre estos dos protocolos de comunicación:

Aspecto GraphQL gRPC
Modelo de comunicación Basado en consultas declarativas; el cliente define qué datos necesita. Basado en llamadas a procedimientos remotos (RPC) con contratos definidos en archivos .proto.
Formato de datos JSON, fácil de leer y depurar. Protocol Buffers (binario), más eficiente en tamaño y velocidad.
Orientación Optimizado para APIs orientadas a frontends y aplicaciones con múltiples vistas. Optimizado para comunicación entre microservicios y sistemas distribuidos de alto rendimiento.
Similitudes Ambos buscan mejorar la eficiencia respecto a REST, soportan tipado fuerte y facilitan la evolución de APIs.
Pros - Flexibilidad en consultas.
- Evita el overfetching y underfetching.
- Gran ecosistema y soporte en frontend.
- Alto rendimiento y baja latencia.
- Streaming bidireccional.
- Contratos estrictos con Protobuf.
Contras - Mayor complejidad en servidores.
- Problemas de caché.
- Curva de aprendizaje para consultas avanzadas.
- Menos legible para humanos (binario).
- Requiere más configuración inicial.
- Ecosistema más orientado a backend que frontend.
Casos de uso ideales Aplicaciones web y móviles que requieren flexibilidad en datos. Microservicios, sistemas distribuidos y aplicaciones de tiempo real.


GraphQL en un ejemplo

Miremos la siguiente imagen que muestra un ejemplo del uso de GraphQL.

El flujo nos dice que:

  • El cliente (una app web o móvil) envía una consulta específica. 
  • El servidor GraphQL responde solo con los datos solicitados, evitando el overfetching
  • Además se usa JSON como formato de respuesta, y el cliente controla qué campos necesita.

gRPC en un ejemplo

Ahora miremos un ejemplo de uso de gRPC.

El flujo nos dice que:

  • El cliente (normalmente otro microservicio) realiza una llamada RPC. 
  • El servidor gRPC responde con datos serializados en Protocol Buffers, optimizados para velocidad y eficiencia. 
  • El contrato entre ambos está definido en archivos .proto, lo que garantiza tipado fuerte y evolución controlada.

Lenguajes de programación más utlizados para ambos protocolos

Lenguaje Uso en GraphQL Uso en gRPC
JavaScript / TypeScript Muy popular en frontend y backend con frameworks como Apollo Server y Express. Soporte limitado; se usa más en clientes que en servidores.
Python Usado con librerías como Graphene y Ariadne. Bien soportado con gRPC Python; útil en ciencia de datos y microservicios.
Java Compatible con librerías como graphql-java. Muy usado en backend empresarial con soporte oficial de gRPC.
Go Menos común en GraphQL, aunque existen librerías como gqlgen. Uno de los lenguajes más eficientes para gRPC; ideal para microservicios.
C++ Raramente usado en GraphQL. Alto rendimiento en sistemas embebidos y backend con gRPC.
.NET (C#) Compatible con HotChocolate y GraphQL.NET. Soporte oficial de gRPC en .NET Core; muy usado en entornos Windows.
Ruby Popular en startups con graphql-ruby. Soporte limitado para gRPC.

Como se puede observar:

  • Go, Java y .NET son excelentes opciones para gRPC
  • JavaScript/TypeScript y Python son ideales para GraphQL.

Conclusiones:

Ambos son alternativas modernas a REST, pero su elección depende del contexto: GraphQL para flexibilidad en frontends y gRPC para eficiencia en backends distribuidos.

Enlaces:

https://alquimistadecodigo.blogspot.com/2024/04/un-vistazo-grpc-una-alternativa-soap-y.html
https://alquimistadecodigo.blogspot.com/2024/05/graphql-en-un-vistazo.html
https://unpocodejava.com/2019/01/23/que-es-grpc/
https://alquimistadecodigo.blogspot.com/2024/05/grpc-protobuff-protocol-buffers.html
https://learn.microsoft.com/es-es/dotnet/architecture/cloud-native/grpc
https://learn.microsoft.com/es-es/dotnet/architecture/cloud-native/grpc



lunes, 1 de enero de 2024

Cosas por aprender... cosas nuevas por aprender

 

Quien se dedique a la programación debería saber que SIEMPRE HAY ALGO NUEVO QUE APRENDER.  Quien ose de creer que lo sabe todo en un futuro estará obligado (quiera o no) a demostrar que así es. Lo que antes era moda hoy es casi "obsoleto" (VB .Net, PHP, Delphi, Informix, etc.). Cosas como Docker, Kubernetes, Terraform, gRPC y demás cosas son lo de hoy. Y llegará un futuro en el que vendrán otros a decir "Esto es lo de hoy, olvídate del pasado". 


El programador incipiente dirá cosas como: "¡No puede ser! ¡Apenas estoy aprendiendo a programar en Angular y ya salió su reemplazo!"

Y es que las cosas son así: Evolucionas o te estancas

"Pepepero, ¿Debo aprender todo lo que salga? ¿Debo convertirme en un Todologo?

Dirán tanto el programador incipiente y como experto. Y la respuesta más discordante y neurótica será: Si y no. Si, porque debes familiarizarte con lo actual. No, porque es imposible saber al 100% algo. Es bueno saber que existe X o Y cosa, y mejor si se puede especializarse en algo. Muy difícil sería saberlo todo (nadie lo sabe todo aunque así lo crea).

Y no todo es sobre programación

También debemos aprender a comunicarnos. Saber escribir, saber leer correctamente. Saber como comunicar nuestras ideas. Saber como resolver cosas antes de que éstas ocurran.

El modelado de sistemas, procesos, etc. también es muy útil. El programador debe saber modelar, esto para evaluar si la organización para la que trabajas está logrando sus objetivos y si está satisfaciendo las necesidades de sus clientes.

En está época donde las IAs están siendo cada vez más populares el programador o quien trabaja con grandes cantidades de información debe familiarizarse con ellas o comenzar a pensar a que se dedicara en un futuro, pues nada se detiene, todo avanza y cambia. El que no vaya a la misma velocidad quedará atrás de todos.



¿Y qué con otros idiomas?

En este post ya hablamos un poco de la importancia de los idiomas (entre otras cosas).  Saber más de un idioma es indispensable en el mundo de informática. Ya sea para leer y entender documentación o hablar con clientes o usuarios. Incluso para exponer proyectos, crear manuales, o resolver incidencias.

Saber un idioma extra al que ya hablas es una ventaja. Saber más de 3 idiomas te pone arriba de otros. Y si hablas más de 3 o 6 podrías trabajar en cualquier parte del mundo, sobre todo si entre éstos son Inglés, Alemán , Koreano o Mandarín.

Certificaciones

Una certificación no te hace experto en algo. Indica que sabes ciertas cosas, solo eso. La experiencia muchas veces es lo que te ayuda a resolver problemas, no un papel. 

Es bueno tener certificaciones si tu trabajo lo requiere. Si eres programador Backend una certificación en Consumo y creación de APIs es un plus para tu carrera. Y si eres más de administración, tener certificaciones en Gestión de proyectos te abrirá otras puertas.

Todos los días podemos aprender cosas nuevas o reforzar lo que ya sabemos (o creemos saber).

Solo basta abrir un poco los ojos y ver en qué podemos mejorar. 

Jai un lenguaje de programación inspirado en C++

Hoy hablaremos de un nuevo lenguaje de programación llamado Jai . Se trata de un lenguaje de programación que está desarrolland...

Etiquetas

Archivo del blog