Application scope

  • Pagser is described as the largest project in the course and has been worked on for years. 2:00:33
  • It is a content-sharing/blogging application where users can start a blog and others can interact with the content. 2:00:48
  • The application has more than 20,000 lines of code. 2:02:15

User-facing features

  • Users can log in, view subscriptions, inspect author profiles, see content, review reading history, and manage read-later items. 2:01:04 2:01:29 2:01:42
  • Profiles include name, headline, biography, photo upload, cropping, and backend image resizing/cropping. 2:02:45 2:03:01
  • Users can create private/public pages using a rich text editor powered by self-hosted TinyMCE assets. 2:03:40
  • Page creation supports embedded images, thumbnails, attached files, tags, comment toggles, and publishing. 2:04:04 2:04:27 2:04:43
  • Public content supports likes/dislikes, subscriptions, thumbnails, attached files, and complex threaded comments. 2:05:04 2:05:32 2:05:51
  • The comments UI is powered by React and Redux. 2:06:09
  • Pagser does not yet include notifications or websockets; a later project will cover websockets with chat. 2:06:29

Architecture

  • Pagser has a similar structure to Weer: Cpeak-powered Node.js backend, Postgres, common, React, Sass, and reusable packages. 2:06:51
  • Pagser has much more CSS and JavaScript than Weer, including a separate dark-theme CSS file. 2:07:07
  • It has multiple HTML files because public pages and public profiles are server-side rendered for SEO. 2:07:27 2:07:43
  • Cpeak handles server-side rendering and file uploads, and the speaker describes it as zero-dependency. 2:07:43

Email and auth

  • Pagser includes password reset email functionality. 2:08:00
  • The example email comes from no-reply@pagser.com, and the speaker says the email setup will be cheap with very low per-thousand-email costs. 2:08:42
  • Registration includes email verification by code. 2:09:04 2:09:32
  • Authentication includes password hashing, forgot password, and email verification. 2:09:52

Media and storage

  • Pagser needs backend media processing for uploaded images, including crop and resize operations. 2:09:52
  • Uploaded images and attachments should not be stored only on the EC2 machine because local server storage is not durable enough. 2:10:13
  • The speaker cites SSD failure rates around 1% per year and notes that instances can be lost or terminated. 2:10:13 2:10:35
  • The planned durable storage approach is to keep three copies of each file in three separate world locations, handled automatically by the storage service. 2:11:00

Deployment roadmap

  • Deploying Pagser requires cloning, running yarn setup, adding secrets to Parameter Store, setting up AWS SES for email, setting up S3 for uploads, and updating sky-role for storage/email permissions. 2:11:19 2:11:37
  • The repository should use the udcc branch, for the same reason as Weer: the production project can change while the course branch stays aligned with the lesson. 2:12:03

Parameter Store setup

  • Pagser environment variables are taken from packages/server/.env.example and stored in Parameter Store under pagser/prod. 2:12:37 2:13:45
  • The speaker uses aws ssm put-parameter commands to create parameters from the terminal instead of entering each one manually in the AWS console. 2:13:45 2:14:09
  • Local AI is used to generate the batch of SSM commands because cloud AI should not be trusted with secrets. 2:13:04 2:17:44
  • Secret values and the database password are stored as SecureString; non-sensitive values are stored as String. 2:17:44 2:20:58

S3 bucket

  • S3 is introduced as cloud storage where applications can upload and read files. 2:15:25
  • The bucket name must be globally unique across AWS accounts. 2:15:25
  • Public access is intentionally allowed here because profile pictures and page images are meant to be publicly readable. 2:15:46
  • Public access should be blocked for sensitive personal user data. 2:16:22

Build and run

  • Pagser is cloned on the server from the udcc branch, then yarn setup is run. 2:21:24 2:21:54
  • The build takes longer than Weer because Pagser is much larger and the React build is heavy. 2:21:54
  • Building on the production server consumes significant CPU, so later CI/CD or Docker image builds on another machine can make deployments much faster on the live server. 2:22:17 2:22:39 2:22:56
  • Pagser creates its own Postgres database and does not reset or damage the Weer database. 2:23:14
  • After yarn start, Pagser runs two instances under PM2 and serves on port 3080. 2:24:27 2:24:55
  • Login with seeded users works, but forgot-password and registration email flows do not yet work because email sending has not been configured. 2:24:55 2:25:13