spy4x / seed Goto Github PK

Right now it only deletes the user's row in DB.

Problem:
If an exception is raised in an event handler - it kills the execution pipe for all other event handlers.
But the application survives that and keeps running, just without any event handlers execution.

A solution might be to add a try-catch block in a proper place (to EventBusExt? or implement a BaseEventHandler class?).

try {
  this.handle(fn)
} catch (error: unknown) {
  logSegment.error({ error: error as Error });
}

How to do it: https://youtu.be/-qJv4ks6YAE?t=6312

After it's done - remove usage of @prisma/client in frontend apps

Right now application just "trusts" the environment that all required variables are presented. Which leads to exceptions being raised later on if some of them are missing.

We need a functions that checks if environment is presented and throws an error if it's not.

Before:

export const API_CONFIG = {
redisHost: process.env['REDIS_HOST'] as string,
// ... other vars
};

After:

export const API_CONFIG = {
redisHost: getEnv('REDIS_HOST'),
// ... other vars
};

function getEnv(name: string): string {
  const value = process.env[name];
  if(!value) {
    throw new Error(`Environment variable ${name} is misssing`);
  }
  return value;
}

  "compilerOptions": {
    "plugins": ["@nestjs/swagger/plugin"]
  }

Links:

1. https://trilon.io/blog/nestjs-swagger-4-whats-new
2. https://www.youtube.com/watch?v=-qJv4ks6YAE

• Should keep code inside front-shared-auth library?
• AngularFire build-in guards?
• IsAuthenticatedGuard (redirects to /auth)
• IsNotAuthenticatedGuard (redirects to /profile)

Reason:

it's rarely used by SaaS startups, mostly by social networks.

Parts:

1. Backend endpoint @Get('is-username-free/:userName')
2. DTO UserIsUsernameFreeDTO
3. Query UserIsUsernameFreeQuery
4. QueryHandler and its usages UserIsUsernameFreeQueryHandler
5. Field definition in Prisma schema file
6. Prisma Migration for the new field. Create with $ yarn prisma migrate dev --name users_add_email
7. Any other usages of wording "username", "userName" and "USERNAME" (there are places on backend and frontend, but mostly single-line removals

Testing:

• Check that command $ yarn format && yarn precommit && yarn nx affected:build succeeds
• Check that new user can be created in app front-web (http://localhost:4200)

Related to #109 - field "email" replaces field "userName".

Client app:

• /auth
• /profile

Admin app:

• /auth
• /profile
• /users # List of users
• /users/:id # Details of a user profile

Right now it's a single module with multiple responsibilities:

Rephrase text using Amazon "backwards" approach:

1. Heading - Name the product in a way the reader (i.e. your target customers) will understand.
2. Sub-Heading - Describe who the market for the product is and what benefit they get. One sentence only underneath the title.
3. Summary - Give a summary of the product and the benefit. Assume the reader will not read anything else so make this paragraph good.
4. Problem - Describe the problem your product solves.
5. Solution - Describe how your product elegantly solves the problem.
6. Quote from You - A quote from a spokesperson in your company.
7. How to Get Started - Describe how easy it is to get started.
8. Customer Quote - Provide a quote from a hypothetical customer that describes how they experienced the benefit.
9. Closing and Call to Action - Wrap it up and give pointers where the reader should go next.
10. If the press release is more than a page and a half, it is probably too long.

It is UI component responsibility to validate inputs.

Right now CacheManager stores values in-memory.

We should move it to Redis.

This is where it is configured.

This is how it should be configured:

import * as redisStore from 'cache-manager-redis-store'; // TODO: yarn add cache-manager-redis-store

const cacheModule = CacheModule.register({
  store: redisStore as unknown as CacheStoreFactory,
  port: 6379,
  host: API_CONFIG.redisHost,
  ttl: CacheTTL.week,
});

Right now LogService usage is a nasty overwhelming boilerplate.

Every controller's endpoint and command/query/event handler function look like this:

async methodName(...params): ReturnType {
    return this.logger.trackSegment(this.methodName.name, async () => {
      ... actual code ...
    }, {params});
  }

It would be neat to simplify this to just:

@Logger()
async methodName(...params): ReturnType {
      ... actual code ...
}

Ideas:

• Use webpack-bundle-analyzer to figure out what's inside the bundle
• Use import type instead of just import. Example: import type {Prisma} from '@prisma/client';

Field properties:

• Optional
• String, max length 50 symbols
• Unique (like to-be-removed field "userName")

Related to #108 - field "email" replaces field "userName".

Parts are similar to "userName" (check related issue) - frontend, backend, prisma field definition, prisma migration.

Features:

• Edit fields
  • firstName
  • lastName
  • photoURL
• Delete account

Steps:

1. Add form with first name, last name and photoURL (just text for now) fields to In shared component libs/front/shared/auth/ui/src/lib/profile/profile.component.html.

Look at libs/front/web/auth/src/lib/create-profile/create-profile.component.html as an example.

Note: you'll need to define a form = new FormGroup({...}); in TS file to make HTML form fields work.

2. Define @Output() update = new EventEmitter<User>(); and @Input() isSaving = false for delegating a parent component (libs/front/web/profile/src/lib/profile/profile.component.html) to handle the logic and provide a loading state back to this component.

3. Implement necessary NGRX actions, effects, and selectors to handle the REST API interaction. Folder: libs/front/shared/auth/state/src/lib/+state

4. Use implemented action and selector in libs/front/web/profile/src/lib/profile/profile.component.ts to initiate an update and watch the loading state. Check if it works. Repeat in libs/front/admin/profile/src/lib/profile/profile.component.html

The final result will look similar to the "Create Profile" component, just with photoURL field instead of email:

Next command should run before a deployment: $ yarn prisma migrate deploy

Main Flow:
1. Ask email
2. Get providers for the email (fetchSignInMethodsForEmail)
3. If no providers - show "Sign up flow" (see below)
4. If one provider - initiate it straight away
5. If multiple providers - show icons for each of them
6. User initiates some provider flow

Sign up flow:
1. Show all possible providers
2. User initiates some provider flow

Places:

1. $ yarn remove @fortawesome/fontawesome-free
2. libs/front/shared/styles/src/shared/imports.sass

Frontend:

• upload file to Firebase Cloud Storage

Backend:

• Resize image to multiple sizes (xs/md/lg)
• Keep track of files in DB

• Generate Angular HttpServices based on Swagger schema?
• https://firebase.google.com/docs/reference/js/firebase.auth.Auth#onidtokenchanged
• Firebase Hosting automatic caching disable:

   {
     "hosting": {
       "rewrites": [{
         "source": "/api",
         "run": {
           "serviceId": "api",
           "region": "us-central1"
         }
       }]
       "headers": [{
         "source": "/api",
         "headers": [{
           "key": "Cache-Control",
           "value": "no-store"
         }]
       }]
     }
   }
  

https://nx.dev/guides/environment-variables#setting-environment-variables

Images of Angular and Prisma are missing (broken link probably).
Please find alternative URLs and replace them.

Idea

A Seed user (developer) should be able to clone Seed and run a script/command that would setup the whole infrastructure for it in the cloud.

Scope

• Google Cloud only (for now)
• May or may not deploy apps after the setup (just run $ yarn nx run-many --target=deploy --all=true) - should be defined if it is convenient.

Implementation options

User executes $ yarn setup:cloud that runs one of:

• Terraform
• Custom script (sh?) docs/how-to-init-cloud-infrastructure.md

Ideas for the future:

• $ npx seed-startup Wizard that: 1. clones repo 2. installs deps 3. asks for ProjectID and if it should setup infrastructure now

Useful links:

• https://www.cloudskillsboost.google/course_sessions/1861885/video/324602
• https://www.youtube.com/watch?v=7xngnjfIlK4&list=WL&index=48&t=4847s
• https://github.com/GoogleCloudPlatform/serverless-expeditions/tree/main/cloud-run-django-terraform

List of what to be configured

Backend:

• Cloud Run
• PostgreSQL
• PGBouncer
• Redis

Frontend:

• Firebase Hosting

Both:

• Firebase Authentication
• Firebase Cloud Storage
• Environment variables

File: libs/front/shared/styles/src/shared/imports.sass

This is how it is now:

It's vertical and viewer has to scroll a lot to see it all.

It would be good to change it to something like a table with horizontal cells, maybe multiple rows.
Ideas? Suggestions?

Example: https://github.com/nestjs/nest#sponsors

Can be generated using tools like https://github.com/mingrammer/diagrams

Responsibilities of "event bus":

1. "Queue"
   A node posts an event, then a free node can grab and process it.
   Example: Delivery order statuses change: Order created -> Cooking -> Delivery in progress -> Delivered.

2. "Bus"
   A node posts an event, then all nodes are notified.
   Example: WebSocket notifications to all participants in a chat app.

Candidates:

• PostgreSQL
• Redis
• RabbitMQ and similar solutions
• Google Cloud Tasks? (better avoid vendor-locking)

• firebase-functions/logger/compat?