Pros/Cons of client-side vs server-side database requests

[seb-lewis]

Just wondering, is there any particular benefit/security concerns that would make it better to have server routes fetch data from the database before serving it to the client? Or is it fine to use something like Supabase on the client to fetch and process database data?

Thanks in advance for the clarification!

[MentalGear]

You'd need to check with the db provider and their SDK what mode of operation (and exposition) is safe, along with your database auth setup.

For supabase, if you want to have the client communicate directly with your supabase instance, you must set a RLS policy as your anon key will be exposed client-side.

Please check the supabase SDK/js/auth-helpers docs for more details.

[david-plugge]

SEO is really important for me. I assumed, that for google there is no difference. If Search Console reads page properly (checking URL inspection) with all data, then there is no difference. If there is I definitely need to keep +page.server.js

You don´t necessarily need the +page.server.js as +page.js load functions are executed on the server and the client (docs).
I´m not an seo expert at all so i may be mistaken, but i think you are good when all publicly available data is server rendered. User specific data can´t be indexed anyway so you should be good loading that on the client only. There are some docs about seo in sveltekit you may want to take a look at (they actually seem to be outdated, you can´t disable ssr within handle anymore i think).

You can also modify the code i posted to enable ssr and fall back to lazily loading data on the client

export async function load(event) {
	const posts = writable([]);

	const { supabaseClient } = await getSupabase(event);

	const postPromise = supabaseClient
		.from('posts')
		.select()
		.then(({ data }) => {
			posts.set(data);
		});

	// await the promise if we are on the server to enable ssr
	if (!browser) {
		await postPromise;
	}

	return {
		posts
	}
}

[david-plugge]

That would be awesome. I'm also curious about best practices for things like pagination and keeping client data up to date after there's been an update from the frontend and/or backend.

Pagination with supabase or in general with sveltekit?

[RykGitProjects]

Tried loading data lazily on front (so front is not waiting for data to be gathered). Seems like supabase is unable to understand this type of connection. My code gets me an TypeError, tried following 1:1:

// src/routes/postlists/+page.js
import { writable } from 'svelte/store';
import { browser} from '$app/environment';
import { getSupabase } from '../../supabaseImport'

export async function load(event) {
	const posts = writable([]);

	// only call the api on the client
	// but dont await the promise so the page is instantly shown
	// and the store is lazily updated with the latest data from supabase
	if (browser) {
		const { supabaseClient } = await getSupabase(event);

		supabaseClient
			.from('my_table')
			.select('column_with_posts')
			.then(({ data }) => {
				posts.set(data);
			});
	}

	return {
		posts
	}
}

// src/routes/postlists/+page.svelte
<script>
	export let data;

	$: posts = data.posts
        console.log(posts)
</script>

//supabaseImport.js
import { createClient } from '@supabase/supabase-js'

const supabaseUrl = import.meta.env.VITE_SUPABASE_URL
const supabaseAnonKey = import.meta.env.VITE_SUPABASE_ANON_KEY

export const supabase = createClient(supabaseUrl, supabaseAnonKey)

[david-plugge]

In the example i gave i assumed you were using the supabase auth helpers

[RykGitProjects]

Thx, will try it !

[seb-lewis]

I guess in general works also, but supabase specifically would be great.

[david-plugge]

You probably want to edit that message and remove the unsubscribe link