Add tryGetSession (or getSessionOrNull) to SessionStorage interface to make user-land code simpler and reduce the chance of session-fetching queries

[tats-u]

getSession always runs createSession when readData cannot find a corresponding entry.
Another method that does not run createSession in such a case is required when you develop a member-only application and expose its login page to the public.
If createSession is called too many times (e.g. by DoS attack), the performance of a database could be degraded by helpless and meaningless read queries to the session table/storage (e.g. SELECT * FROM session WHERE id = ''). You have to add if (!id /* or id === "" */) return null at the beginning of readData to prevent invoking such extra helpless queries. Also, you have to add .id() to the predicate in the if statement to determine whether a session definitely exists.

const session = await sessionStorage.getSession(request.headers.get("cookie"));

// Why the hell do we have to add the extra `.id()` here just to check if a session exists?
if (!session.id()) {
  throw redirect("/login", { status: 303 });
}

It should be if you do not touch the session when the user does not have a cookie:

// Just "if session does not exists". Clearer. Less noise.
if (!session) {
  throw redirect("/login", { status: 303 });
}
// process using the session. TypeScript has erased `| null`.

We want to prevent extra execution of tryRead(""):

const sessionStorage = createSessionStorage({
  // *snip*
  async readData(id) {
    // It's a pain in the neck having to insert this line as a part of the boiler plate every single time.
    if (!id) return null;
    const data = await tryRead(id);
    return data ?? null;
  },
  // *snip*
});

We want make if (!id) return null; unnecessary by preventing extra execution of readData when the user does not have a cookie.

API:

  getSession: (
    cookieHeader?: string | null,
    options?: ParseOptions
  ) => Promise<Session<Data, FlashData>>;

vs

  tryGetSession: (
    cookieHeader?: string | null,
    options?: ParseOptions
  ) => Promise<Session<Data, FlashData> | null>;

react-router/packages/react-router/lib/server-runtime/sessions.ts

Lines 266 to 270 in 255ac96

	async getSession(cookieHeader, options) {
	let id = cookieHeader && (await cookie.parse(cookieHeader, options));
	let data = id && (await readData(id));
	return createSession(data || {}, id || "");
	},

The current getSession will perform a wasteful operation and force adding the wasteful check even if an user has no merit to receive a session data.

vs

 async tryGetSession(cookieHeader, options) { 
   let id = cookieHeader && (await cookie.parse(cookieHeader, options)); 
   let data = id && (await readData(id)); 
   return data ? createSession(data, id) : null;
 }, 

As you might notice, it returns just null without creating new one when no entry.

const session = await tryGetSession(
  request.headers.get("Cookie"),
);
if (session == null) {
  return redirect("/login");
}

// Login page
const session = await tryGetSession(
  request.headers.get("Cookie"),
);
if (session != null) {
  return redirect("/");
}

This will not be a breaking change unless you use third party session libraries. However, an author of a third party session library have to modify their library to implement this method. Unfortunately JavaScript/TypeScript cannot provide default method implementations in an interface unlike Java or C#.

[tats-u]

Implementation:

dev...tats-u:react-router:session-get

[tats-u]

Creating a session when the user has no intention of logging in is a waste of resources.

[brophdawg11]

createSession does not touch the session backing store, it just creates a JS object implementing the Session interface:

react-router/packages/react-router/lib/server-runtime/sessions.ts

Line 93 in 6e0deab

export const createSession: CreateSessionFunction = <

I think what you're probably running into is calling commitSession on these "empty" sessions when you don't need to - that is what would create a new session in your DB:

https://github.com/remix-run/react-router/blob/6e0deabca97fc4816f0ad13d359bf316e04e500f/packages/react-router/lib/server-runtime/sessions.ts#L271-287

You can check session.id to see if it's a new session (id === "") or existing session (id is populated) and potentially use that along with a check on session.data to see if any data has been added to the session before calling commitSession.

[tats-u]

Exactly. I did not thoroughly analyzed the implementation in RR. I will change the approach; The current implementation cannot avoid running getSession("") when the user does not have a cookie. Unless you add if (!id) return null; at the beginning of getSession, RR will issue a search query where id is "" (e.g. SELECT * FROM session WHERE id = ''). Also we have to add the extra .id() to check whether a session exists. (!session.id())
The current circumstances are not ideal or intuitive. Adding the new method will prevent the extra .id() and if (!id) return null. User-land code will get shorter and simpler thanks to it.

I updated the the top content.

[sergiodxa]

You can avoid the DB query by using the cookie. When you create a session storage you always have to pass a cookie object created with createCookie.

Many people just do createSomethingSessionStorage({ cookie: createCookie(opts) }) but you can define the cookie outside and export it.

export const sessionCookie = createCookie(cookieOptions)
export const sessionStorage = createDatabaseSessionStorage({ cookie: sessionCookie, db: YOUR_DB })

Then instead of using sessionStorage.getSession which as you said will try to do a SELECT from your DB, you can use sessionCookie first.

export async function loader({ request }: Route.LoaderArgs) {
  let sessionId = await sessionCookie.parse(request.headers.get("Cookie"))
  if (!sessionId) {
    // user has no session
  } else {
    // user has session, use sessionStorage.getSession here
  }
}

You can put this in a middleware, and store the Session object in the router context if there's a sessionId, this way it will run on every request but only for users with a session.

[brophdawg11]

I am going to need to see a minimal reproduction to provide further insight, I don't understand the issue you are having.