This is a university project for the course of Software Engineering. The project is a web application for managing the booking of the train tickets.
This is a monorepo that contains apps and packages.
- Apps - standalone applications that can be deployed independently.
- Packages - reusable libraries.
You can find the documentation here.
This is a SvelteKit application that should serve as the BFF (Backend for Frontend) for the web client. It should handle the user information, authentication and it's authorized to access the API via the internal api token.
This is a Fastify application that should serve as the API for the web client. The idea is that it should not be exposed or know anything about the user. From the APIs standpoint, it manages the customers, bookings, train and other resources. It has a trusted relationship with the web app and it's authorized to access the database.
The project uses Supabase, which is a Postgres database with a REST API on top of it. Additionally, the authentication is handled by Supabase (WIP🚧).
- DB - all the database related information + schemas. It can be re-used across many back-end services/lambdas.
- Contracts - shared types between the front-end and back-end.
- Api client - an autogenerated client for the API based on the OpenAPI specification (WIP🚧).
As this is an educational project, I'm trying to document the mistakes I've made to learn from them.
I've used to have a .env file that contained all the configurations for the application. However, I later realized that this is not a good idea. Sometimes your configurations can be public. Moreover, they are usually nested and it's hard to manage them in a single file. Additionally, the application should've been relying on NODE_ENV to determine the environment and whether to enable some features or not.
Currently, I see 3 types of configurations:
- env variables - for variables that are changed in the environment frequently. PORT, CONFIG_URL, etc.
- secrets - sensitive information that should not be exposed. API keys, tokens, DB connection strings etc.
- configs - non-sensitive information that defines the behavior of the application. For example, fastify config, logger config, services config
Without a clear convention, it's hard to remain consistent. The API ended up being a mess. I've checked the API design guidelines from several companies and created a document with the conventions I'm going to follow.
I really like Stripe APIs and the way they allow you to use them. You can easily query and expand the resources. The integration is really easy and straightforward. So, I tried to do the same thing, but I ended up with having a small number of endpoints and the client was expanding 5 nested resources in a single request. This was a bad API design and I'm willing to change it.