La compañía publica la versión 8.0.0 de su cliente para .NET con un paquete específico para ASP.NET Core. La serialización pasa a System.Text.Json y los paquetes dejan atrás .NET Framework.
Supabase ha publicado la versión 8.0.0 de su SDK para .NET, el cliente en C# que agrupa Auth, base de datos, Storage, Realtime y Edge Functions en una sola API. El lanzamiento incluye un paquete nuevo, Supabase.Extensions.DependencyInjection, diseñado para proyectos de ASP.NET Core, según publica ecosistemastartup.com. La compañía afirma que más de 13 millones de desarrolladores utilizan su plataforma, lo que convierte esta actualización en una vía de entrada ordenada al ecosistema .NET, el stack donde reside buena parte del software corporativo y de las aplicaciones internas de las empresas.
Los cambios de esta versión afectan a la integración con el framework. La serialización ha pasado de Newtonsoft.Json a System.Text.Json, cada cliente de servicio acepta ahora un HttpClient inyectable y soporta reintentos con backoff de forma opcional. Los paquetes apuntan a .NET Standard 2.1, lo que deja fuera a .NET Framework.
Para los equipos que migran desde una versión anterior, hay dos frentes de trabajo. El primero es la serialización: los convertidores personalizados y los atributos [JsonProperty] que usaban con Newtonsoft.Json necesitan su equivalente en System.Text.Json. Este cambio no rompe la compilación pero sí el comportamiento en tiempo de ejecución, con campos que llegan vacíos, nombres de columna que no mapean o fechas que se deserializan de forma distinta. La recomendación es cubrirlo con tests de integración contra una base real antes de tocar producción.
El segundo frente es el target de los paquetes. Al apuntar a .NET Standard 2.1, el SDK deja atrás .NET Framework, que llega como máximo a .NET Standard 2.0. En la práctica se necesita .NET Core 3.0 o superior, o .NET 5 o superior. Si se mantienen servicios legacy en .NET Framework, este SDK no es una opción sin migrar el runtime primero. La documentación de Supabase incluye una guía de migración con cada cambio de ruptura y las notas de la release con el listado completo.
La instalación se realiza con el comando dotnet add package Supabase. Ese meta-paquete arrastra los cinco servicios (Auth, Postgrest, Storage, Realtime y Functions). Si solo se necesita uno, se puede referenciar por separado, por ejemplo Supabase.Gotrue para autenticación o Supabase.Postgrest para la base de datos.
En ASP.NET Core el flujo recomendado pasa por el paquete de inyección de dependencias. Se registra el cliente una vez con AddSupabase y se inyecta donde se necesite: un endpoint minimal API, un controlador o un servicio propio. AddSupabase registra Supabase.Client como servicio scoped y también expone cada sub-cliente por separado (IPostgrestClient, IGotrueClient, IStorageClient, IFunctionsClient, IRealtimeClient), de modo que una clase que solo toca Storage puede depender únicamente de eso.
Un detalle crítico que suele pasarse por alto: un Supabase.Client construye su propio HttpClient al instanciarse. Si se registra como scoped o transient a mano, cada resolución crea un HttpClient nuevo (y un socket nuevo), lo que bajo carga agota el pool de conexiones. AddSupabase resuelve esto enlazando el cliente a través de IHttpClientFactory, de modo que el handler se reutiliza. Para mantener la coherencia, hay que reemplazar cualquier HttpClient que se pase por configureOptions; las opciones de proxy, reintentos y Realtime siguen aplicándose.
Fuera de ASP.NET Core, en apps de consola, escritorio, móvil o Unity, el cliente se construye manualmente y se inicializa una sola vez con InitializeAsync. Aplica el mismo principio: un cliente por operación implica un HttpClient nuevo cada vez. Además, el manejador de sesión por defecto no guarda nada, así que para restaurar un inicio de sesión tras reiniciar la aplicación se necesita implementar un SessionHandler propio.
Las operaciones básicas siguen un patrón claro. El SDK mapea una tabla a una clase de C#. El modelo deriva de BaseModel y usa atributos ([Table], [PrimaryKey], [Column]) para vincular propiedades con columnas. Para leer, From<T>() abre la consulta, Where filtra y Get la ejecuta devolviendo un ModeledResponse<T> cuyos registros están en Models. Para escribir, Insert acepta un modelo o una lista. Para actualizar y borrar hay dos caminos válidos: si ya se tiene el registro en mano, se cambian sus propiedades y se llama a Update o Delete.
La documentación oficial de Supabase detalla cada uno de estos pasos y ofrece ejemplos para los distintos escenarios de integración.
También te puede interesar
