| Technology | Description | code-library-client | code-library-server | code-library-perms |
|---|---|---|---|---|
| Docker | X | X | ||
| Typescript | strictly typed superset of javascript (i.e. it compiles to javascript). offers advantages in development through improved linting and catching bugs at build time | X | X | X |
| GraphQL - ApolloJs | language- and transport-agnostic standart for building self-documenting and efficient apis. implemented via @apollo/client in code-library-client and via apollo-server in code-library-server. further reading at https://graphql.org/ | X | X | |
| JWT - JsonwebtokenJs | json web tokens (jwt) are a standart for verifying the issuer of a json payload using a private secret, we are using jsonwebtokenJs for the implementation. further reading at https://jwt.io/ | X | X | |
| JestJs | Used for unit testing | X | ||
| MongoDb - MongooseJs | mongoDb is one of the most popular nosql-databases. we decided to use it over a relational database for shits and giggles and are interacting with it via the ORM mongooseJs. | X | ||
| NextJS | we decided to go with this server side rendering react framework for SEO, speed, increased backwards compatibility, and its built-in routing | X | ||
| Next-AuthJs | used for google authentication, as well as keeping the users jwt token cookie httpOnly while still being able to access it on the nextJs server | X | ||
| ReactJs | X | |||
| ZodJs | schema validation library offering awesome typescript support | X | ||
| AxiosJs | a http request library we might use to access external apis, it offers greater backwards compatibility and automatic status code throwing in comparison to the native browser api fetch | X | ||
| ChalkJs | used for console.log styling | X | X |
JWTs in a nutshell: A JSON payload that is readable by anyone, signed using a secret key. Using that key, our backend can, later on, confirm that a JWT sent by the user as a cookie is authentic (i.e. signed by our backend), and the payload can thereby be trusted.
sequenceDiagram
participant Google
participant CB as Client (Browser)
participant CS as Client (Server)
participant Backend
CB ->> Google: Username + Password
Google ->> CS: Userdata
CS ->> Backend: Userdata
Backend ->> CS: JWT (payload: Userdata)
CS ->> CB: set-cookie=JWT
CB ->> Backend: some request (cookie=JWT)
Note right of Backend: Both Backend and Client (Server) can verify<br/> the JWT using process.env.JWT_SECRET
A user has a permissions integer (abbreviated to permsInt in the codebase), which contains
All components of our app are running on the cloud. Partially, that was decided based on suggestions from our project consultant, easy automation of recurring tasks, and the fact that we got free credits to use on a few of the big providers.
Our final choice was Google Cloud Platform. From its multitude of services, we’re relying on Cloud Run to run our app containers – frontend and backend – while connecting to a MongoDB database provided by MongoDB Atlas. Both platforms offer fully managed solutions, which means we don’t have to worry about configuring and provisioning infrastructure for scaling in the future.
Figure 1: CODE Library App architecture diagram
🔗 Our project on Google Cloud Platform
🔗 Our main database cluster on MongoDB Atlas
🔗 Billing information on MongoDB Atlas
We have two environments for deployment on GCP: staging (pre-production) and production. Each one is triggered based on the name of the branch being pushed to the repository.
- Pushes to master will trigger a deployment to the staging environment.
- Creating or updating a pull requests will also trigger deployments to the staging environment.
- Tags prefixed with a "v" (i.e., v1.0.0) will trigger a deployment to the production environment.