Supabase Integration

[Maniga]

Hi there!

I would love to create a Supabase integration for Aspire. I've already started, but I think the approach I took might not be the right one.

Looking into the Supabase documentation, for a local environment running in Docker, you need to clone the Supabase repository, set some environment variables, and start the Docker Compose file. This file launches all the necessary components of Supabase, including:

• Kong: API Gateway
• GoTrue: Authentication service
• PostgreSQL: Database
• Studio: The Supabase dashboard
• PostgREST: For turning the database into a RESTful API and providing a GraphQL API
• Realtime: For real-time updates
• Storage API: For S3-compatible object storage
• Deno: For edge functions
• Postgres-meta: For managing PostgreSQL
• Supavisor: For multi-tenant PostgreSQL connection pooling

How would you approach this? Would you use the Docker Compose file from Supabase and create an integration for each module with the necessary configuration and resources to start Supabase? Then, would you have a Supabase hosting integration that combines them all?

This was my initial idea, but perhaps there's a better way to handle it.

Thank you!

[aaronpowell]

Supabase was proposed in dotnet/aspire#4271 (and it was brought up #58 as a candidate to migrate in original planning).

I'll admit to not having any familiarity with Supabase or how to run it, so I had a quick look through https://supabase.com/docs/guides/self-hosting/docker and that really does look complex 🤣.

An approach to tackling this would be to use the Supabase CLI and just have the assumption that supabase is in PATH so that it can run, but that would be limiting in a post-local dev scenario.

If you want to have an integration that can tackle local dev and deployment scenarios, you are going to need to create multiple integrations that allow you to run each of those containers. I'm not sure how many of those are required vs nice-to-have (especially locally), so it may take some experimentation.

Here's a very rough thought on how it could look from an app host perspective:

var builder = DistributedApplication.CreateBuilder(args);

IResourceBuilder<SupabaseResource> supabase = builder.AddSupabase("supabase");

if (builder.Context.IsDevelopment()) // it's something like this, I'm writing from memory 🤣
{
    supabase.WithEmulator(); // use the Supabase CLI
}
else
{
    var pg = builder.AddPostgres("pg");
    IResourceBuilder<PostgRestResource> pgrest = pg.WithPostgRest("postgrest");

    supabase
      .WithReference(builder.AddKong("kong"))
      .WithReference(pg)
      .WithReference(pgrest)
      .WithReference(builder.AddDeno("edge-functions"))
      // and so on
}

(I partially did the code, it should give you the idea though)

Generally speaking, each of these would be their own hosting package, the Postgres stuff like PostgREST and Postgres-meta could be in an extensions package for Postgres (like we do with Node.js and Python), and on the Supabase integration the WithReference would take the explicit type:

public static IResourceBuilder<SupabaseResource> WithReference(this IResourceBuilder<SupabaseResource> builder, IResourceBuilder<KongResource> kong)
{
    builder.Resource.AddKong(kong);

    // set any explicit environment variables or whatnot from the kong resource using an event

   return builder;
}

Hopefully that gives you an idea and starting point on how this could be tackled.