Build a User Management App with SvelteKit
This tutorial demonstrates how to build a basic user management app. The app authenticates and identifies the user, stores their profile information in the database, and allows the user to log in, update their profile details, and upload a profile photo. The app uses:
- Supra Database - a Postgres database for storing your user data and Row Level Security so data is protected and users can only access their own information.
- Supra Auth - users log in through magic links sent to their email (without having to set up passwords).
- Supra Storage - users can upload a profile photo.
note
If you get stuck while working through this guide, refer to the full example on GitHub.
Project setup#
Before we start building we're going to set up our Database and API. This is as simple as starting a new Project in Supra and then creating a "schema" inside the database.
Create a project#
- Create a new project in the Supra Dashboard.
- Enter your project details.
- Wait for the new database to launch.
Set up the database schema#
Now we are going to set up the database schema. We can use the "User Management Starter" quickstart in the SQL Editor, or you can just copy/paste the SQL from below and run it yourself.
- Go to the SQL Editor page in the Dashboard.
- Click User Management Starter.
- Click Run.
note
You can easily pull the database schema down to your local project by running the following commands:
_10supra link --project-ref <project-id>_10# You can get <project-id> from your project's dashboard URL: https://supra.com/dashboard/project/<project-id>_10supra db pull
Get the API Keys#
Now that you've created some database tables, you are ready to insert data using the auto-generated API.
We just need to get the Project URL and anon key from the API settings.
- Go to the API Settings page in the Dashboard.
- Find your Project
URL,anon, andservice_rolekeys on this page.
Building the App#
Let's start building the Svelte app from scratch.
Initialize a Svelte app#
We can use the SvelteKit Skeleton Project to initialize an app called supra-sveltekit (for this tutorial we will be using TypeScript):
_10npm create svelte@latest supra-sveltekit_10cd supra-sveltekit_10npm install
Then install the Supra client library: supra-js
_10npm install @supra/supra-js
And finally we want to save the environment variables in a .env.
All we need are the supra_URL and the supra_KEY key that you copied earlier.
Optionally, add src/styles.css with the CSS from the example.
Supra Auth Helpers#
SvelteKit is a highly versatile framework offering pre-rendering at build time (SSG), server-side rendering at request time (SSR), API routes, and more.
It can be challenging to authenticate your users in all these different environments, that's why we've created the Supra Auth Helpers to make user management and data fetching within SvelteKit as easy as possible.
Install the auth helpers for SvelteKit:
_10npm install @supra/auth-helpers-sveltekit @supra/supra-js
Add the code below to your src/hooks.server.ts to initialize the client on the server:
If you are using TypeScript the compiler might complain about event.locals.supra and event.locals.getSession, this can be fixed by updating your src/app.d.ts with the content below:
Create a new src/routes/+layout.server.ts file to handle the session on the server-side.
Start your dev server (
npm run dev) in order to generate the./$typesfiles we are referencing in our project.
Create a new src/routes/+layout.ts file to handle the session and the supra object on the client-side.
Update your src/routes/+layout.svelte:
Set up a Login page#
Supra Auth UI
We can use the Supra Auth UI, a pre-built Svelte component, for authenticating users via OAuth, email, and magic links.
Install the Supra Auth UI for Svelte
_10npm install @supra/auth-ui-svelte @supra/auth-ui-shared
Add the Auth component to your home page
Create a src/routes/+page.server.ts file that will return our website url to be used in our redirectTo above.
_14// src/routes/+page.server.ts_14import { redirect } from '@sveltejs/kit'_14import type { PageServerLoad } from './$types'_14_14export const load: PageServerLoad = async ({ url, locals: { getSession } }) => {_14 const session = await getSession()_14_14 // if the user is already logged in return them to the account page_14 if (session) {_14 throw redirect(303, '/account')_14 }_14_14 return { url: url.origin }_14}
Proof Key for Code Exchange (PKCE)#
As we are employing Proof Key for Code Exchange (PKCE) in our authentication flow, it is necessary to create a server endpoint responsible for exchanging the code for a session.
In the following code snippet, we perform the following steps:
- Retrieve the code sent back from the Supra Auth server using the
codequery parameter. - Exchange this code for a session, which we store in our chosen storage mechanism (in this case, cookies).
- Finally, we redirect the user to the
accountpage.
_12// src/routes/auth/callback/+server.js_12import { redirect } from '@sveltejs/kit'_12_12export const GET = async ({ url, locals: { supra } }) => {_12 const code = url.searchParams.get('code')_12_12 if (code) {_12 await supra.auth.exchangeCodeForSession(code)_12 }_12_12 throw redirect(303, '/account')_12}
Account page#
After a user is signed in, they need to be able to edit their profile details and manage their account.
Create a new src/routes/account/+page.svelte file with the content below.
Now create the associated src/routes/account/+page.server.ts file that will handle loading our data from the server through the load function
and handle all our form actions through the actions object.
_61import { fail, redirect } from '@sveltejs/kit'_61_61export const load = async ({ locals: { supra, getSession } }) => {_61 const session = await getSession()_61_61 if (!session) {_61 throw redirect(303, '/')_61 }_61_61 const { data: profile } = await supra_61 .from('profiles')_61 .select(`username, full_name, website, avatar_url`)_61 .eq('id', session.user.id)_61 .single()_61_61 return { session, profile }_61}_61_61export const actions = {_61 update: async ({ request, locals: { supra, getSession } }) => {_61 const formData = await request.formData()_61 const fullName = formData.get('fullName') as string_61 const username = formData.get('username') as string_61 const website = formData.get('website') as string_61 const avatarUrl = formData.get('avatarUrl') as string_61_61 const session = await getSession()_61_61 const { error } = await supra.from('profiles').upsert({_61 id: session?.user.id,_61 full_name: fullName,_61 username,_61 website,_61 avatar_url: avatarUrl,_61 updated_at: new Date(),_61 })_61_61 if (error) {_61 return fail(500, {_61 fullName,_61 username,_61 website,_61 avatarUrl,_61 })_61 }_61_61 return {_61 fullName,_61 username,_61 website,_61 avatarUrl,_61 }_61 },_61 signout: async ({ locals: { supra, getSession } }) => {_61 const session = await getSession()_61 if (session) {_61 await supra.auth.signOut()_61 throw redirect(303, '/')_61 }_61 },_61}
Launch!#
Now that we have all the pages in place, run this in a terminal window:
_10npm run dev
And then open the browser to localhost:5173 and you should see the completed app.
Bonus: Profile photos#
Every Supra project is configured with Storage for managing large files like photos and videos.
Create an upload widget#
Let's create an avatar for the user so that they can upload a profile photo. We can start by creating a new component called Avatar.svelte in the src/routes/account directory:
Add the new widget#
And then we can add the widget to the Account page:
Storage management#
If you upload additional profile photos, they'll accumulate
in the avatars bucket because of their random names with only the latest being referenced
from public.profiles and the older versions getting orphaned.
To automatically remove obsolete storage objects, extend the database
triggers. Note that it is not sufficient to delete the objects from the
storage.objects table because that would orphan and leak the actual storage objects in
the S3 backend. Instead, invoke the storage API within Postgres via the http extension.
Enable the http extension for the extensions schema in the Dashboard.
Then, define the following SQL functions in the SQL Editor to delete
storage objects via the API:
_34create or replace function delete_storage_object(bucket text, object text, out status int, out content text)_34returns record_34language 'plpgsql'_34security definer_34as $$_34declare_34 project_url text := '<YOURPROJECTURL>';_34 service_role_key text := '<YOURSERVICEROLEKEY>'; -- full access needed_34 url text := project_url||'/storage/v1/object/'||bucket||'/'||object;_34begin_34 select_34 into status, content_34 result.status::int, result.content::text_34 FROM extensions.http((_34 'DELETE',_34 url,_34 ARRAY[extensions.http_header('authorization','Bearer '||service_role_key)],_34 NULL,_34 NULL)::extensions.http_request) as result;_34end;_34$$;_34_34create or replace function delete_avatar(avatar_url text, out status int, out content text)_34returns record_34language 'plpgsql'_34security definer_34as $$_34begin_34 select_34 into status, content_34 result.status, result.content_34 from public.delete_storage_object('avatars', avatar_url) as result;_34end;_34$$;
Next, add a trigger that removes any obsolete avatar whenever the profile is updated or deleted:
_32create or replace function delete_old_avatar()_32returns trigger_32language 'plpgsql'_32security definer_32as $$_32declare_32 status int;_32 content text;_32 avatar_name text;_32begin_32 if coalesce(old.avatar_url, '') <> ''_32 and (tg_op = 'DELETE' or (old.avatar_url <> new.avatar_url)) then_32 -- extract avatar name_32 avatar_name := old.avatar_url;_32 select_32 into status, content_32 result.status, result.content_32 from public.delete_avatar(avatar_name) as result;_32 if status <> 200 then_32 raise warning 'Could not delete avatar: % %', status, content;_32 end if;_32 end if;_32 if tg_op = 'DELETE' then_32 return old;_32 end if;_32 return new;_32end;_32$$;_32_32create trigger before_profile_changes_32 before update of avatar_url or delete on public.profiles_32 for each row execute function public.delete_old_avatar();
Finally, delete the public.profile row before a user is deleted.
If this step is omitted, you won't be able to delete users without
first manually deleting their avatar image.
_14create or replace function delete_old_profile()_14returns trigger_14language 'plpgsql'_14security definer_14as $$_14begin_14 delete from public.profiles where id = old.id;_14 return old;_14end;_14$$;_14_14create trigger before_delete_user_14 before delete on auth.users_14 for each row execute function public.delete_old_profile();
At this stage you have a fully functional application!