Fullstack Svelte Course Overview

Introduction

Setting up your local development environment

Setting Up a Svelte Local Development Environment

How to Initialize a Boilerplate Svelte Project

Setting Up a Formatter and Linter for Svelte Development

Setting Up A Development Environment

Setting up a Single Page Application Router

An Introduction to Svelte Routing for Single Page Applications

Creating a Front End Layout for Admin Pages

Front End Layouts - Creating Reusable Parent Components

Front End Routing

Using Front End Component Libraries for Svelte Development

Learn Svelte - How to Create a Basic Landing Page

Using Svelte to handle DOM events and bind inputs

A Guide to Handling DOM Events and Input Binding with Svelte

User Interface Styles and Interactions

Initialize an Express Node.js Project for Svelte Development

Creating REST API GET, POST, PUT, and DELETE Requests

School Lunch Data Model

Creating the Backend Application

Fetching Data from the Frontend with Axios

How to Use Axios to Fetch Data From APIs for Svelte Apps

Using Svelte Each Blocks to Iterate a List

Svelte 'each' Blocks - Loop Through an Array and Update a DOM

Using Svelte to Show and Hide Loading Spinner Icons

Externalizing Frontend Configuration

Fetching Data in the Frontend

Installing PostgreSQL Locally to Add Persistence to a Svelte App

Configuring Knex js Migrations for Database Management Scripts

How to Use Knex js in an Express Backend App

Adding Post, Put and Delete Endpoints to the Backend

Sveltekit Endpoints - How to Use Post, Put, and Delete

Adding Persistence with PostgreSQL

Cleaning Up the Front End of a Single Page Application in Svelte

Building a Form in Svelte That Lets Users Create Data Entities

The Lunch Week Details Component

Creating, Updating and Deleting Data in the Frontend

Securing the application with JSON Web Tokens

Securing a Svelte Application with JSON Web Tokens

Evolving the App to a Multi Tenant Architecture

Get Started Creating a Multi Tenant Application in Svelte

Creating a User Signup Flow for a Multi Tenant Svelte App

Securing the Application

Public Lunch Week Page

Public Lunch Menu View

Building Svelte Single Page Applications and Serving Static Files

Production Deployment

This course teaches all the major concepts you need to build a production ready SaaS application by step by step _building a fully functional application_. The course is divided into two main parts - the _frontend_, which uses Svelte to build an interactive, rich user interface and the _backend_, which uses Express and PostgreSQL to build a server that handles data management.

Svelte is an exciting new frontend UI framework that offers a very developer friendly workflow and easy to learn syntax. Express and PostgreSQL are tried-and-true technologies that provide a rock solid backend.

Across about 7 hours of video instruction with full source code, this course covers everything from setting up your development environment to securing your application with a multi-tenant architecture and ultimately deploying the application to production.

Build a Svelte app with Node.js, Express, and Postgresql

In this course, we'll be creating a full stack SaaS application with Svelte, Express and PostgreSQL

Fullstack Svelte

Persistence with a relational PostgreSQL database

Frontend create, read, update and delete operations

How to integrate Auth0 for JWT authentication

Multi-tenant applications are apps in which multiple customers or customer groups use the application but are separated from one another. Multi-tenancy is very common in SaaS applications because it allows an application to be created once and offered to many customers.

Up until now, we have been using a single-tenant application. All of our data is available to any user. Supporting multiple customers (in our case schools) adds complexity but is needed in a lot of real world situations.

In this lesson, we'll evolve the application to a multi-tenant architecture. Here's the plan:

 database. From pgAdmin, right-click on Databases and choose Create > Database. Use the name "catalog" and hit Save.

Postgres database names should be lower case

Next, we are going to separate our migrations. We need to have one set of migrations for the "app database" (ie our old database) and a new set of migrations for the Catalog database. Under the backend project's database directory, create two new directories:

$ mkdir app_migrations
$ mkdir catalog_migrations

Continuing, let's do some re-organization and cleanup. Move the existing migrations from 

 and delete the old migrations directory and 

Now, we need to create a schools table in the new catalog database. Stub out the migration from the command line. This time, we specify a 

 so that we can keep catalog related migrations in the 

 directory.
From the root of the backend project:

$ knex migrate:make create-schools-table --migrations-directory database/catalog_migrations

The project should look something like this:

 with the following migration code to create a schools table with 

 column will later be used to determine which database to use for which school (tenant).

exports.up = function (knex) {
  return knex.schema.createTable('schools', function (table) {
    table.increments('school_id')
    table.string('school_name').notNullable()
    table.string('school_database').notNullable()
  })
}

exports.down = function (knex) {
  return knex.schema.dropTable('schools')
}

So far, we have only had one database to deal with and we have gotten by with running the 

 command from the command line. Moving forward, we'll have one database for every tenant and we need something more automated. Knex migrations also have a JavaScript API that we can use, so let's write a standalone Node script that will handle all the migrations.

 in the root of the backend project. Here's the script:

 file. We're doing the same here, but we need to add additional vars to the 

PG_HOST=localhost
PG_PASSWORD=<your pg password>
PG_USER=postgres

Go ahead and give the script a try by running 

$ node migrate
FS-related option specified for migration configuration. This resets migrationSource to default FsMigrations

To make things interesting, let's insert a couple of schools into the catalog schools table. In pgAdmin, right click on the catalog database and choose Query Tool. From here, you can run the following insert statement:

insert into schools (school_name, school_database)
values
('Pinewood Elementary', 'pinewood_elementary'),
('Sunnyside High School', 'pinewood_elementary')

. This time, new databases for each school should be created and updated with the necessary tables from the 

. You can refresh the databases in pgAdmin to see the results:

---
title: Get Started Creating a Multi Tenant Application in Svelte
description: Evolving the App to a Multi Tenant Architecture
privateVideoUrl: https://fullstack.wistia.com/medias/cpr53jabqq
isPublicLesson: false
code: https://gitlab.com/fullstackio/books/newline-course-apps/blair-googer-fullstack-svelte-app/-/tree/main/code/module_08/lesson_02/App?ref_type=heads
---

### Multi-tenant Applications

Multi-tenant applications are apps in which multiple customers or customer groups use the application but are separated from one another. Multi-tenancy is very common in SaaS applications because it allows an application to be created once and offered to many customers.

Up until now, we have been using a single-tenant application. All of our data is available to any user. Supporting multiple customers (in our case schools) adds complexity but is needed in a lot of real world situations.

In this lesson, we'll evolve the application to a multi-tenant architecture. Here's the plan:

1.  Each school will get their own database. This will keep their data isolated from other schools.
2.  When we create JWTs via Auth0, we'll add metadata into the JWT identifying the user's school.
3.  For a given API call coming into the Express backend, we'll parse the JWT and determine the user's school and connect to the proper database.
4.  We'll create a special "catalog" database that will contain a table of schools and we'll use that to help manage the other databases with a new Knex migration script.

### The Catalog Database

Let's get going by creating the new `catalog` database. From pgAdmin, right-click on Databases and choose Create > Database. Use the name "catalog" and hit Save.

> Postgres database names should be lower case

Next, we are going to separate our migrations. We need to have one set of migrations for the "app database" (ie our old database) and a new set of migrations for the Catalog database. Under the backend project's database directory, create two new directories:

```shell
$ mkdir app_migrations
$ mkdir catalog_migrations
```

Continuing, let's do some re-organization and cleanup. Move the existing migrations from `/migrations` into `/database/app_migrations` and delete the old migrations directory and `.knexfile`.

Now, we need to create a schools table in the new catalog database. Stub out the migration from the command line. This time, we specify a `migrations-directory` so that we can keep catalog related migrations in the `/database/catalog_migrations/` directory.
From the root of the backend project:

```shell
$ knex migrate:make create-schools-table --migrations-directory database/catalog_migrations
```

The project should look something like this:

![migrations](https://d2uusema5elisf.cloudfront.net/courses/fullstack-svelte/module_09/lesson_09.02/public/migrations.png)

Update the new `create-schools-table` with the following migration code to create a schools table with `school_id`, `school_name`, and `school_database` columns. The `school_database` column will later be used to determine which database to use for which school (tenant).

```js { actualFilename=../../../code/module_08/lesson_02/school-lunch/backend/database/catalog_migrations/20200925201944_create-schools-table.js endChar=309 endLine=12 startChar=0 startLine=1 statedFilename=create-schools-table.js url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-svelte-course/module_09/lesson_09.02/.../../code/module_08/lesson_02/school-lunch/backend/database/catalog_migrations/20200925201944_create-schools-table.js }
exports.up = function (knex) {
  return knex.schema.createTable('schools', function (table) {
    table.increments('school_id')
    table.string('school_name').notNullable()
    table.string('school_database').notNullable()
  })
}

exports.down = function (knex) {
  return knex.schema.dropTable('schools')
}
```

### A Custom Migration Script

So far, we have only had one database to deal with and we have gotten by with running the `knex migrate:up` command from the command line. Moving forward, we'll have one database for every tenant and we need something more automated. Knex migrations also have a JavaScript API that we can use, so let's write a standalone Node script that will handle all the migrations.

Create a file called `migrate.js` in the root of the backend project. Here's the script:

```js { actualFilename=../../../code/module_08/lesson_02/school-lunch/backend/migrate.js endChar=1322 endLine=57 startChar=0 startLine=1 statedFilename=migrate.js url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-svelte-course/module_09/lesson_09.02/.../../code/module_08/lesson_02/school-lunch/backend/migrate.js }
const knex = require('knex')
require('dotenv').config()

const getConfig = (databaseName) => {
  return {
    client: 'postgresql',
    connection: {
      database: databaseName,
      host: process.env.PG_HOST,
      user: process.env.PG_USER,
      password: process.env.PG_PASSWORD,
    },
  }
}

const migrateDatabases = async () => {
  const defaultKnex = knex(getConfig('postgres'))
  const catalogDb = await defaultKnex
    .select()
    .from('pg_database')
    .where({ datname: 'catalog' })
    .first()

  if (!catalogDb) {
    await defaultKnex.raw(`create database catalog`)
  }

  const catalogKnex = knex(getConfig('catalog'))
  await catalogKnex.migrate.latest({
    directory: './database/catalog_migrations',
  })

  const schools = await catalogKnex.select().from('schools')

  for (let i = 0; i < schools.length; i++) {
    const school = schools[i]
    const db = await catalogKnex
      .select()
      .from('pg_database')
      .where({ datname: school.school_database })
      .first()

    if (!db) {
      await catalogKnex.raw(`create database ${school.school_database}`)
    }
    const appKnex = knex(getConfig(school.school_database))
    await appKnex.migrate.latest({
      directory: './database/app_migrations',
    })
  }
  process.exit(0)
}

;(async () => {
  migrateDatabases()
})()
```

In the previous lesson, we used the `dotenv` package to apply env vars from our `.env` file. We're doing the same here, but we need to add additional vars to the `.env` file.

Add the following to `.env`:

```shell
PG_HOST=localhost
PG_PASSWORD=<your pg password>
PG_USER=postgres
```

Go ahead and give the script a try by running `node migrate` from the command line:

```shell
$ node migrate
FS-related option specified for migration configuration. This resets migrationSource to default FsMigrations
```

To make things interesting, let's insert a couple of schools into the catalog schools table. In pgAdmin, right click on the catalog database and choose Query Tool. From here, you can run the following insert statement:

```sql
insert into schools (school_name, school_database)
values
('Pinewood Elementary', 'pinewood_elementary'),
('Sunnyside High School', 'pinewood_elementary')
```

Then run the migrate script again: `$ node migrate`. This time, new databases for each school should be created and updated with the necessary tables from the `app_migrations`. You can refresh the databases in pgAdmin to see the results:

![pgadmin-tables](https://d2uusema5elisf.cloudfront.net/courses/fullstack-svelte/module_09/lesson_09.02/public/pgadmin-tables.png)