fix: Fix for Realtime Functionality in Supabase-on-AWS Description

[psyrenpark]

While implementing supabase-on-aws, I encountered an issue where the realtime functionality was not working as expected. After investigating, I found a similar issue reported on the Supabase Realtime GitHub repository supabase/realtime#372, which led me to a solution.

Changes Made
Updated Realtime Version in Supabase Stack
I updated the Docker image version for the Supabase Realtime service in src/supabase-stack.ts to resolve the initial issue with the Realtime service not functioning properly.

Before: public.ecr.aws/supabase/realtime:v2.25.27
After: public.ecr.aws/supabase/realtime:v2.25.60

This change allowed the following code to work, enabling successful subscription and message broadcast between clients:

    // client1.ts
    const channelA = supabase.channel('room')

    channelA
    .on(
      'broadcast',
      { event: '*' },
      (payload :any ) => messageReceived(payload)
    )
    .subscribe((status :any ) => {
        console.log("log -> ~ .subscribe ~ status:", status)
    })

    // client2.ts
    const channelA = supabase.channel('room')

    channelA.subscribe((status) => {
        if (status !== 'SUBSCRIBED') { return }
        channelA.send({
        type: 'broadcast',
        event: 'test',
        payload: { message: 'talking to myself' },
        })
    })

Identified Issue with API-based Messaging
However, I noticed that sending messages via the API instead of directly through WebSockets did not work. This issue was discussed in a Supabase community discussion https://github.com/orgs/supabase/discussions/18790#discussioncomment-7580134.

Configuration Adjustments in Kong Template
To address this, I made adjustments in the containers/kong/kong-template.yml to properly route Realtime and Realtime-API requests, and updated environment variables in src/supabase-stack.ts for consistency.

Updated SUPABASE_REALTIME_URL to SUPABASE_REALTIME_SOCKET_URL and added SUPABASE_REALTIME_API_URL.
Updated the Kong Docker image to a newer version with a revised kong-template.yml.

// containers/kong/kong-template.yml

  ## Secure Realtime routes
  - name: realtime-v1
    _comment: 'Realtime: /realtime/v1/* -> ws://realtime:4000/socket/*'
    url: ${SUPABASE_REALTIME_SOCKET_URL:=http://realtime:4000/socket/}
    routes:
      - name: realtime-v1-all
        strip_path: true
        paths:
          - /realtime/v1/
    plugins:
      - name: cors
      - name: key-auth
        config:
          hide_credentials: false
      - name: acl
        config:
          hide_groups_header: true
          allow:
            - admin
            - anon

  # For Realtime-API routes
  - name: realtime-v1-api
    _comment: 'Realtime: /realtime/v1/api/* -> ws://realtime:4000/api/*'
    url: ${SUPABASE_REALTIME_API_URL:=http://realtime:4000/api/}
    routes:
      - name: realtime-v1-api-routes
        paths:
          - /realtime/v1/api
    plugins:
      - name: cors
      - name: key-auth
        config:
          hide_credentials: false
      - name: acl
        config:
          hide_groups_header: true
          allow:
            - admin
            - anon
          

// src/supabase-stack.ts

- kong.service.taskDefinition.defaultContainer!.addEnvironment('SUPABASE_REALTIME_URL', `${realtime.endpoint}/socket/`);
+ kong.service.taskDefinition.defaultContainer!.addEnvironment('SUPABASE_REALTIME_SOCKET_URL', `${realtime.endpoint}/socket/`);
+ kong.service.taskDefinition.defaultContainer!.addEnvironment('SUPABASE_REALTIME_API_URL', `${realtime.endpoint}/api/`);

-  image: ecs.ContainerImage.fromRegistry('public.ecr.aws/u3p7q2r8/kong:latest'),
+ image: ecs.ContainerImage.fromRegistry('public.ecr.aws/k1e4k0b3/kong:latest'), // FIX: new kong-template.yml version

Final Outcome
After making these changes, both WebSocket-based and API-based messaging functionalities were working as expected, resolving the initial issue with the Realtime service.

// Example of client code with successful Realtime functionality

    // client1.ts
    const channelA = supabase.channel('room')

    channelA
    .on(
      'broadcast',
      { event: '*' },
      (payload :any ) => messageReceived(payload)
    )
    .subscribe((status :any ) => {
        console.log("log -> ~ .subscribe ~ status:", status)
    })

    // client2.ts
    const channelA = supabase.channel('room')
    // not subscribe
    const data = await channelA
        .send({
        type: 'broadcast',
        event: 'test',
        payload: { message: 'hi~' },
        },{

        })

Conclusion
I hope this pull request will be merged to help others facing similar issues with Realtime functionality in Supabase-on-AWS. This solution has been tested and confirmed to work, providing a path forward for those experiencing similar challenges.

[psyrenpark]

Conclusion
I hope this pull request will be merged to help others facing similar issues with Realtime functionality in Supabase-on-AWS. This solution has been tested and confirmed to work, providing a path forward for those experiencing similar challenges.

[robinpdev]

This looks good, currently having the problem of receiving 404 from the realtime broadcast endpoint, but the messages do get received on the other side. hosting locally

[psyrenpark]

This looks good, currently having the problem of receiving 404 from the realtime broadcast endpoint, but the messages do get received on the other side. hosting locally

Could you provide more details about the symptoms you're encountering, especially regarding the 404 error from the realtime broadcast endpoint, while noting that messages are still being received on the other side? It would be helpful to understand the exact behavior, any error messages, and the steps leading up to the issue when hosting locally.