Is Supabase a good fit for Remix?

[binajmen]

Hi,

I'm picturing my needs and the steps I would need to switch from Next to Remix on my current project to give it a try in a real world situation. I'm currently using Supabase as my auth + database + storage backend.

As I understand all the data interactions are server-sided (to fully exploit Remix), I feel I'll loose the Supabase capabilities regarding the row level security (RLS) offered by Postgres that allows to restrict access to the data based on the user's id and role that initiated the request.

It all started from this discussion here:

The bigger question is whether Supabase is a good fit for Remix...? Because it's designed to work from the client, Supabase seems to me to suit SPAs and mobile apps, while the happy path with Remix is more like a Rails or PHP app. So for instance with SB how do we do authentication on the server? And we'd only use the SB JS lib if we were doing real time stuff on the client (where it would be super useful). SB has storage, but then so does AWS or CloudFlare.
I think SB is great, I'd like to use it on a mobile project I'm working on, but for Remix apps I'm just not sure anymore.. I wonder what you think?

Anyone having experience with that and/or a smart way to keep using the best of these both worlds, that is Remix & Supabase?

[binajmen]

Some additional thoughts coming from a thread in Discord:

I think the advantage of using supabase is user can connect directly to supabase server without any intermediate server.

This is true thanks to PostgREST and the Supabase JS library on top of it. +1 point for DX

RLS will restrict user permission as needed.

Is it really? Aren't the RLS rules bypassed when using the service_role key?

since Remix easily handle both server side and client side, why restrict yourself with RLS rule, create any rule in loader & action

The question is indeed: do you want to safe guard queries in Postgres (pgplsql/sql) or in Remix (javascript). I'd say handling this in the database itself make your code less prone to error, or at least more consistent: the same rules applies wherever you call the data in your Remix app.

[ccssmnn]

Writing from a Firebase perspective here, but Firebase and Supabase aim to solve similar problems.

Supabase (as well as Firebase) allows the clients directly to communicate with the backend (auth & databases), without requiring a server in between. For (native) App developers, this mostly eliminates the need to write their own backend. But you need to be more confident on your database security, since clients are allowed to interact with your databases directly. This brings its own complexity, plus sometimes you need to find a database structure, that allows for the security settings, that you have in mind.

I remember having trouble with confusing access rights in a Firebase Database, finally ending up with cloud functions in between because it was so easy with code and so complicated with the security rules.

When you start developing a NextJS or Remix application, you're implementing your server anyway. The (recommended) NextJS approach is still client-side data fetching with swr, but with remix you can go all in on a server between your users and the Supabase backend. All the advantages of remix (UX & DX) will apply.

[binajmen]

I'm indeed applying NextJS "best practices" on my current project: client-side fetching with SWR. The advantage is that the row level security do the jobs to protect data that should not be accessible to a user (the same way security rules do the job in Firestore). I like this separation of concerns effect.

But from a Remix perspective, I indeed understand server-side is king. You would use the service_rolekey (the equivalent of firebase-admin) to access the db, leading to bypassing the RLS (if any).

My conclusion would be the RLS should be translated somehow in javascript accross the loaders/actions.

Or perhaps there is a way to "mock" the user session while using the anon_key in the loaders/actions? That would be a win-win situation from a Supabase perspective: still use RLS when you believe rules should be enforced at DB side, while taking advantages of Remix API.

[ccssmnn]

This blog post from Remix explains the disadvantages of client side data fetching from a user perspective.

You can implement the security roles via code, instead of setting them manually. But it should also be possible, to use the client SDK to make your database calls on the server.

Sorry again for describing the firebase way, but in firebase when signing in a user on the server, you can create a session token. A client could use this token, to authenticate. You can easily create a session cookie which holds this token and sign-in in the actions / loaders using that token. You need the admin-sdk only for authentication to create that session token. This way, you could keep your seperations of concerns, since remixes methods are communicating to your backend just like a client.

[binajmen]

Yes, this article is priceless!! I decided to give a try with Remix thanks to this article :)

Sorry again for describing the firebase way, but in firebase when signing in a user on the server, you can create a session token. A client could use this token, to authenticate. You can easily create a session cookie which holds this token and sign-in in the actions / loaders using that token. You need the admin-sdk only for authentication to create that session token. This way, you could keep your seperations of concerns, since remixes methods are communicating to your backend just like a client.

This is exactly what I would like to achieve. But I'm not familiar enough with this process (session token, session cookie, etc.). I believe this link is a good start as it seems to implement exactly what you suggest: https://codegino.com/blog/remix-supabase-auth

If you have an example based on Firebase, I'm more than open as it is clearly similar :)

[ccssmnn]

I've posted an example implementation of login loader and action here

There you'll find

• the session setup
• how to read it and check the token (firebase returns the UID when verifying the token)
• how to authorize a user and create the token

In the other routes, I only verify the Token, receive the UID and do all further processing with firebase-admin (server-role). But you could also use the token to sign in on the server with the client SDK. My example does the sign in with the firebase-client-sdk, since their admin SDK does not provide email+password login.

[binajmen]

Following a Discord thread, it seems there are several way to use the two of them (at least from the Postgres-RLS-stuff perspective):

1. You implement the RLS rules as usual. In the loaders/actions you would use the anon_key and mock the user rights by using JWT-token-stuff (<-- that's the part I still need to figure out 😆),
2. You forget about implementing the RLS rules, but rather choose to implement them in Remix (with plain JS). You'll still need to be able to retrieve the necessary info to ensure the user has the correct rights to access the data (<-- still need to figure out how too) while using the service_role (admin) key.

[afk-mario]

I currently save the supabase access token on a cookie session and use that to access the supabase database on the server that way I keep the RLS rules working, the only downside is that you need to create a new supabase client for each request.

import { createClient } from "@supabase/supabase-js";

const {
  SUPABASE_SERVICE_KEY,
  REMIX_APP_SUPABASE_URL,
  REMIX_APP_SUPABASE_ANON_KEY,
} = process.env;

export const serviceClient = createClient(
  REMIX_APP_SUPABASE_URL,
  SUPABASE_SERVICE_KEY
);

export function authenticatedClient({ token }) {
  const client = createClient(
    REMIX_APP_SUPABASE_URL,
    REMIX_APP_SUPABASE_ANON_KEY
  );

  client.auth.setAuth(token);
  return client;
}

[binajmen]

the only downside is that you need to create a new supabase client for each request.

Why is that? Can't you setAuth(token) on an existing client to switch from one token to another?

[afk-mario]

I'm not sure but if you are running a single instance of the remix server you could leak the authenticated client to a different user couldn't you ?

[binajmen]

Mmmh. I suppose you should always retrieve the session token from the request in the loader/action and use setAuth() before using the instanciated supabase client. You should be good to go in that case.