Skip to content

RascalTwo/Todo-Fullstack

Repository files navigation

Todo Fullstack

Live-synchronized Todo app.

visitors Heroku Website

todo.fullstack.mp4
todo.fullstack.sync.mp4

Link to project: https://r2-todo-fullstack.herokuapp.com/

Statistics

GitHub language count GitHub top language GitHub code size in bytes Lines of code

Repository

GitHub issues GitHub closed issues GitHub pull requests GitHub closed pull requests GitHub last commit

Git Docker Heroku YAML GitHub Actions GitHub

Combination of Frontend package.json version and Backend package.json version as submodules for deployment purposes via Docker.

The Frontend is built, then the Backend, the assets are copied from the frontend to the backend, and finally the backend is started and serves the frontend assets along with the actual API.

How It's Made

Tech used: HTML, CSS, JavaScript, TypeScript, Node.js, Express.js, Sequelize, Docker, Heroku, GitHub Actions, Material UI, Vite, React

First is the Backend, which is a Node.js server with Express.js and Sequelize, written using the MVC architecture, fully usable via both the REST API and WebSocket API.

Then is the Frontend, which is a React app built with Vite, using Material UI, using the Context API for state management.

Both are written in Typescript, and managed via both Docker and GitHub Actions, being merged into a single deployment via this very repository.

Optimizations

While the API is quite optimized - allowing for both usage of the traditional REST API & WebSocket API - the offline-list could be improved by transforming the Frontend into a PWA.

Lessons Learned

While not my first time using any of these particular technologies, combining them all together with a multi-repo setup was a great experience.

Docker

The Dockerfile can be used to build the application for production, with the Backend serving the Frontend.

For development purposes, Docker Compose is also an option, starting both halves in development mode with a persistent Postgres database.

Heroku

Deployment to Heroku is achieved using the Dockerfile

GitHub Actions

A single GitHub Action is used to automate the deployment to heroku, with the help of the Heroku Deploy action.

Why are you using GitHub Actions to automate deployemnt and not Heroku?

At the time of writing, using Git submodules is only supported for builds triggered with direct pushes, builds triggered via the Heroku GitHub API do not include the submodule contents

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published