Using SvelteKit with Flask and PostgreSQL

Written By: Austen Radigk

Article Sections

1. Project Background
2. Chosen Tech Stack
3. Project Setup
4. Development Process
5. SvelteKit and PostgreSQL
6. Takeaways

Project Background

This Software Engineering project takes place as a part of the Software Engineering course at St Edward's University. The main purpose of this project was to build a functional website for some sort of business. In our group, we had 5 people, and chose to build a website that sold computer parts. To no surprise, this idea has been executed multiple times. But in our case, that made it easier to compare with other examples already out there. We started by naming this web app ForgeTech. 

Chosen Tech Stack

• Svelte: A frontend framework that makes use of mixing HTML and Javascript logic. 

• Tailwind CSS: CSS Library, which puts styles in the class section of an HTML element. This is a fantastic add-on to most tech stacks.

• Skeleton UI v2: A simple and easy-to-use UI library, which takes advantage of tailwind classes and svelte. Once the tailwind concept is understood, it is like building with styled Lego bricks. 

• Docker: Acting as a virtual environment to load and run backend services like Flask and Postgres, which helps with compatibility among different devices during development.

• Flask: A simple lightweight backend framework that takes advantage of Python.

• PostgreSQL: The database that powers the website. In the beginning, it was chosen because we were trying to learn more about its use and applications, more on this later.

Project Setup

• VSCode Setup: For this project, the group decided to primarily use VSCode as the main IDE. VSCode is a great editor that falls in the middle of something like the Sublime text editor and Eclipse, specifically tuned for Java. What makes VSCode great for this project is that it's highly customizable for many languages via different add-ons available. In our case, it allowed us to control Docker, Git and made it easy to manage files when a workspace is selected. 
• Directory Tree / Github Setup: As the main goal was to keep things simple, we chose to keep everything in a single project directory. This also allowed us to put everything in one repository on GitHub. This made it easier to get up-to-date changes across the site. Not only that, we stuck to a simple branching structure, mainly, working as our development branch, while a staging branch worked as a place to test changes and make sure they were compatible.

• Frontend Setup: Setting up a Svelte web app with SkeletonUI and Tailwind CSS is easy. It only takes a few commands. The SkeletonUI documentation makes the installation easy to follow.

• Backend Setup: 

1. Docker: Starting with docker, this was set up to run two services, Flask and PostgreSQL. Docker is necessary since multiple people were working on the project. It enables us to start the backend services with one command and prevents compatibility issues as it runs in a virtual environment. Plus we can specify which Python libraries and version of it to use every time docker is built or rebuilt which prevents a certain function from going deprecated in the middle of the project.
2. Flask: After setting up docker, Flask is set up by building out a simple Flask app, which includes three simple elements, a init file that imports the Flask library along with other libraries, models, which specify how tables are created in the PostgreSQL database, and routes, which specify how information is passed into or queried from the database depending on the task. 
3. PostgreSQL: Since we are using Docker, PostgreSQL can be run inside the virtual environment and accessed from the Flask app locally inside the environment.

Development Process

• Organization: The course split up this process for us, sprints were assigned every few weeks, with an emphasis on making the deadline. Our group split the task among everybody, so there was a more equal workload. For example, we started with backend development first, team members assigned the task of creating tables or adjusting existing tables for a sprint would do that first and update the flask code as needed. This prevented scenarios where frontend assigned members went in and made conflicting changes to the Flask Models. The goal of this was to have the backend tables set up for the front end to build off of.
• Communication / Weekly Meetings: I can not express how important communication is during a project like this, one conflicting line of code and slow down everything. Every week, our group met up in person or online to discuss progress being made and potential changes that could impact other workflows. As the project progressed throughout the semester, communication tightened up a lot making it easy to get more tasks completed without merge conflicts, which leads us into the next important aspect of development.
• Understanding Git: Understanding how Git works, and how it should be used is crucial. We found a workflow that suited the group well. This included creating separate branches for each feature being added to the site after the backend changes were made and merged into the staging branch. After the feature branches were complete, they were also merged together in the staging branch and then put onto the main branch after some adjustments. Below is a snippet from VSCode that shows part of the git tree, this helps visualize the workflow with git.

SvelteKit and Flask and PostgreSQL

As mentioned before, we decided to use SvelteKit with Flask and PostgreSQL, at first it was a decision we were slightly regretful of, but in the long run, it allowed us to do more. 

1. The Cons: Taking advantage of Flask and PostgreSQL requires knowledge, and the group, including myself, had to learn how Flask and PostgreSQL functioned in relation to the other technologies. This caused many headaches at first. Manually developing routes and tables took trial and error. There are many moving parts to this setup, if not executed correctly, it creates problems, unlike other alternatives such as Firebase.
2. The Pros: It may seem like a slightly more complicated setup, but it opens the door to customization. PostgreSQL is kinda like a custom computer, in a way, it allows you to use it with different backend technologies and implement different use cases into a single database, unlike something like Firebase. For larger-scale development, this actually makes sense. Not only that, Flask and Postgres are free to use, unlike Firebase, provided there is a suitable hosting platform. If we were to continue development for this project, the development pains experienced at first would pay off in the long run with a setup like this. 
3. How SvelteKit Integrated With Flask: Svelte was easy to set up for this use case. Svelte provides a setup for a server-type-script file that can be custom-built per frontend route. This made it easy to determine what routes were needed on the backend and also made it simple to connect them at these points. Below is a sequence diagram that demonstrates the flow of data in relation to this setup.

Takeaways

• The use of Flask and PostgreSQL is overkill. But, learning how these technologies worked together was valuable. Not only that but understanding the reasons to use a setup like this could save a lot of time and money in the future is good knowledge. Services like Firebase are beginner-friendly but lack certain features concerning more advanced concepts. 
• Since everything was stored locally, the entire project existed in a single Github Repository. This also allowed us to run and update this setup on a droplet.
• Having organized development is really important for this use case since it's easier to break code. However, getting over the hurdle opens the door to more opportunities down the road.
• This not only expanded our knowledge of these technologies but also expanded other core development skills, such as communication, time management, and thinking outside the box regarding certain features using Svelte, Flask, and PostgreSQL.