Conversation
There was a problem hiding this comment.
Pull request overview
Expands the Full-stack team section of the Engineering Handbook by replacing “Work in progress” placeholders with substantial documentation, and adds MkDocs support for Mermaid code fences so architecture diagrams can be embedded in the docs.
Changes:
- Added comprehensive Full-stack documentation across tech stack, security, deployment/operations, coding standards, and appendices.
- Introduced an “AI-Assisted Development” guide and linked it in navigation/index pages.
- Updated MkDocs markdown extension configuration to support Mermaid fenced blocks.
Reviewed changes
Copilot reviewed 27 out of 27 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| mkdocs.yml | Adds Full-stack nav entry for AI tools and configures pymdownx.superfences custom fence for Mermaid blocks. |
| docs/teams/fullstack/tech_stack/40_integrations.md | Replaces placeholder with integration patterns and Mermaid diagrams. |
| docs/teams/fullstack/tech_stack/30_devops.md | Replaces placeholder with DevOps/infra overview, Docker, CI/CD, and Mermaid diagrams. |
| docs/teams/fullstack/tech_stack/20_database.md | Replaces placeholder with DB/ORM/migration guidance and Mermaid diagrams. |
| docs/teams/fullstack/tech_stack/10_backend.md | Replaces placeholder with backend architecture and API patterns (includes Mermaid diagrams). |
| docs/teams/fullstack/tech_stack/00_frontend.md | Replaces placeholder with frontend architecture, tooling, and Mermaid diagrams. |
| docs/teams/fullstack/security/10_privacy.md | Replaces placeholder with privacy/GDPR and implementation guidelines. |
| docs/teams/fullstack/security/00_auth.md | Replaces placeholder with auth/authz patterns (JWT/OAuth/Firebase/RBAC). |
| docs/teams/fullstack/index.md | Updates section headings/links and removes “🚧” markers in favor of concrete summaries. |
| docs/teams/fullstack/docs/10_api_docs.md | Replaces placeholder with REST/GraphQL documentation standards and examples. |
| docs/teams/fullstack/docs/00_code_docs.md | Replaces placeholder with documentation philosophy and templates. |
| docs/teams/fullstack/development/30_project_setup.md | Updates branch naming (develop) and modernizes docker compose commands; adds AI scaffolding note. |
| docs/teams/fullstack/development/10_pull_request_guidelines.md | Updates PR self-review and reviewer assignment guidance. |
| docs/teams/fullstack/dev_env/20_ai_tools.md | New guide for AI-assisted development and security rules. |
| docs/teams/fullstack/dev_env/10_secrets.md | Modernizes docker compose examples and improves secrets docs formatting. |
| docs/teams/fullstack/dev_env/00_local_setup.md | Updates setup steps (develop branch, docker compose commands) and adds local domain notes. |
| docs/teams/fullstack/deployment/20_monitoring.md | Replaces placeholder with monitoring/logging/healthcheck guidance. |
| docs/teams/fullstack/deployment/10_rollback.md | Replaces placeholder with rollback procedures and decision tree. |
| docs/teams/fullstack/deployment/00_deployment.md | Replaces placeholder with CI/CD workflow and environment promotion guidance. |
| docs/teams/fullstack/coding_standards/40_error_handling.md | Updates logging section to align on Pino/nestjs-pino (removes Winston example). |
| docs/teams/fullstack/coding_standards/30_testing.md | Replaces placeholder with testing philosophy, conventions, and tool overview. |
| docs/teams/fullstack/coding_standards/10_linting.md | Clarifies linting/formatting approach and adds note on evolving tooling. |
| docs/teams/fullstack/coding_standards/00_style_guides.md | Updates Vue guidance to <script setup lang="ts"> + composables examples. |
| docs/teams/fullstack/appendices/30_templates.md | Replaces placeholder with PR/README/docker-compose templates. |
| docs/teams/fullstack/appendices/20_faq.md | Replaces placeholder with onboarding/dev/review/deploy FAQ. |
| docs/teams/fullstack/appendices/10_scripts.md | Replaces placeholder with commonly used scripts/commands (Docker/DB/Git helpers). |
| docs/teams/fullstack/appendices/00_glossary.md | Expands glossary with additional modern terms (CI, IaC, E2E, etc.). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
chore: current state updates
| - cache | ||
|
|
||
| postgres: | ||
| image: postgres:16-alpine |
There was a problem hiding this comment.
postgre 16 v template? co takhle už 18 :)
| findOne(@Param('id', ParseUUIDPipe) id: string): Promise<UserResponseDto> { | ||
| return this.usersService.findOne(id) | ||
| } | ||
| } |
There was a problem hiding this comment.
no tady bych se o tom ještě pobavil. Já už jsem kolikrát říkal, že definování api dokumentace přes tyhle dekorátory se mi moc nelíbí, ale whatever, pokud se na tom shodnem, tak můžem jit tudy.
co mě na tomto přístupu vadí víc než bordelení kódu je, že do procesu definice api takhle nejsou zapojení mobile devs. Apičko definujeme my, to je jasné, ale vstupy od kluků jsou většinou fajn, protože tam vidí problémy zas ze svojí strany.
There was a problem hiding this comment.
Tohle vypadá fajn na generování bez zaplevelení kódu: https://docs.nestjs.com/openapi/cli-plugin
| GraphQL Playground (or Apollo Sandbox) is available at the GraphQL endpoint in development. It provides: | ||
|
|
||
| - Interactive query builder | ||
| - Auto-complete based on the schema |
There was a problem hiding this comment.
právě no... s graphkem máš autocomplete, tak by mi dávalo smysl, kdybychom na začátek dávali spíše název modelu, než tu akci takže "userCreate" spíš než "createUser". Protože tím autocompletem si můžeš chytnout entitu se kterou pracuješ a potom vidíš dostupné akce spíš než další desítky create akcí
zkoušel jsem tu konvenci zavést na kruhu, ale trochu se nám to rozjelo. Není major problém, ale přišlo by mi fajn, můžem se pobavit.
| - **Refresh tokens** should be stored securely and rotated on use | ||
| - **Rate limit** authentication endpoints to prevent brute force attacks | ||
| - **Never log** tokens, passwords, or authentication payloads | ||
| - **Invalidate sessions** on password change |
There was a problem hiding this comment.
jaké sessions? když máme JWT, tak session neexistuje ne? většinou to máš buď JWT, nebo nějakou session a invalidace tokenu může probíhat se získáním nového access tokenu
taky by bylo fajn zmínit, že když jdeme cestou JWT, tak není dobrá practise si pokaždé vytahovat usera z databáze, že tím přicházíš právě o výhody JWT
| constructor(private readonly usersService: UsersService) {} | ||
|
|
||
| @Get() | ||
| findAll(@Query() query: PaginationDto): Promise<PaginatedResponse<User>> { |
There was a problem hiding this comment.
píšeš o tom, že bysme neměli vracet entity jako DTOčka do api (souhlas), ale tady to teda vypadá jako root entita, kterou používáš pro response. Možná by ten název mohl reflektrovat, že jde o nějaké custom DTO.
je to i niž u graphka :)
|
|
||
| | Use REST when... | Use GraphQL when... | | ||
| |---|---| | ||
| | Simple CRUD operations | Complex nested data relationships | |
There was a problem hiding this comment.
i s tou data complexity si nejsem jistý. Kruh má komplexní data a nejsem si jistý, že nám to v něčem pomáhá. Zvlášť když appka i front používá to graphko často jako rest. A nemáme plán na to, jak verzovat modely v graphku, leda prostě suffixovat v2 a tak no.
|
|
||
| ## Validation | ||
|
|
||
| All incoming data is validated using DTOs with `class-validator`: |
There was a problem hiding this comment.
co nějaká poznámka ke class-validatoru, jak blbě handluje nested data, že je potřeba si na to dát bacha?
| COPY --from=builder /app/dist ./dist | ||
| COPY --from=builder /app/node_modules ./node_modules | ||
| COPY --from=builder /app/package.json ./ | ||
|
|
There was a problem hiding this comment.
node 20? :)
jinak ten multistage build setup by měl být složitější. Protože nejdřív potřebuješ instalovat i dev dependencies abys byl schopný to zbuildit a pro produkční container stáhnout packages bez dev dependencies
| ### Where We Are | ||
|
|
||
| - Infrastructure for most projects is provisioned manually (cloud consoles, CLI) | ||
| - A handful of projects use **Terraform** with basic GCP or Digital Ocean resource definitions |
There was a problem hiding this comment.
fakt jo? to někde máme?
vím jen o prastarém nesnězenu a národním muzeu
| **SPA (Single Page Application)** | ||
| A web application that loads a single HTML page and dynamically updates content as the user interacts with the app. | ||
|
|
||
| **SSR (Server-Side Rendering)** |
There was a problem hiding this comment.
Chybí mi tu zmínka o SSG, když už ho používáme 🙂
| docker compose exec postgres psql -U myuser -c "CREATE DATABASE mydb;" | ||
|
|
||
| echo "Running migrations..." | ||
| docker compose exec api npm run migrate |
There was a problem hiding this comment.
npm nepoužíváme, ale je to všude
možná dobrý nápad zvalidovat i to, jestli chceme zůstat u yarn
|
|
||
| We don't mandate a specific IDE. Most team members use: | ||
|
|
||
| - **WebStorm** (JetBrains) — Full-featured, excellent TypeScript/Vue support |
There was a problem hiding this comment.
Přidala bych, že je to self-paying, aby nebylo mrzení
There was a problem hiding this comment.
aha, to je vtipné, mi bylo řečeno, že si to mám zaplatit sama 🙂
|
|
||
| See the [Backend](../tech_stack/10_backend.md) page for a comparison table. In short: | ||
|
|
||
| - **REST** for simple CRUD, public APIs, file operations, webhooks |
|
|
||
| ### What should I focus on during code review? | ||
|
|
||
| 1. **Correctness** — Does the code do what it's supposed to? |
There was a problem hiding this comment.
Chybí mi tu ještě readability (naming, apod.) a efficiency
|
|
||
| **Key capabilities:** | ||
|
|
||
| - **Server-side rendering** — Fast initial page loads and SEO for public-facing apps |
| ├── plugins/ # Nuxt plugins (Sentry, etc.) | ||
| ├── server/ # Server routes and middleware | ||
| │ └── api/ | ||
| ├── types/ # TypeScript type definitions |
There was a problem hiding this comment.
Chybí mi tu ještě utils na auto-imported helper funkce
|
|
||
| - **Auto-imports**: Nuxt auto-imports Vue APIs and composables — no need for manual imports in most cases | ||
| - **CSS**: Use scoped styles in components. For shared styles, use a CSS framework or utility classes as appropriate for the project | ||
| - **API calls**: Use Nuxt's `$fetch` or `useFetch` composable for data fetching with built-in SSR support |
There was a problem hiding this comment.
Zrovna fetche nepoužíváme, když si generujeme API EPs ze Swaggeru :/ + nemáme to SSR a nevím, jestli někdy mít budem - budeme oddělovat BE od FE, abychom SSR mohli použít? Budeme ho potřebovat?
| ### Key Conventions | ||
|
|
||
| - **Auto-imports**: Nuxt auto-imports Vue APIs and composables — no need for manual imports in most cases | ||
| - **CSS**: Use scoped styles in components. For shared styles, use a CSS framework or utility classes as appropriate for the project |
There was a problem hiding this comment.
Doplnila bych ještě někde, že používáme Tailwind pro css
| ├── types/ # TypeScript type definitions | ||
| └── nuxt.config.ts # Nuxt configuration | ||
| ``` | ||
|
|
There was a problem hiding this comment.
Ještě bych doplnila použití i18n jako standard, i když se explicitně nepoužívá vícero jazyků.
|
@Marpheus Masakrálně mega moc textu 😄 Ale dobře udělané, napadlo mě tam pár drobností. |
| |---|---| | ||
| | **NestJS** | Medium-to-large projects, complex business logic, multiple modules, long-term maintenance | | ||
| | **Express / Fastify** | Small APIs, microservices, tight budgets, simple CRUD | | ||
| | **Hono** | Edge-first APIs, serverless functions, minimal footprint | |
There was a problem hiding this comment.
Mame niekde pouzite Hono, alebo preco je tu uvedene ako priklad?
| }); | ||
| ``` | ||
|
|
||
| ### 2. REST API Error Handling (Non-GraphQL Apps) |
There was a problem hiding this comment.
Mne by sa pacilo, keby pouzivame error handling ako zaviedol na kruhu Adam, ked sme robili jablotron api. V principe sa jedna iba o cast error handlingu ako vyhadzovat chyby, kedy si predpripravis triedu so staticmi. Priklad triedy:
export class CommonErrors {
static InvalidInputData() {
return new ApplicationError(
'Request body does not match any of the expected types for this operation.',
ErrorCodeEnum.BAD_USER_INPUT,
HttpStatus.BAD_REQUEST,
)
}
}
nasledne uz iba hadzes dany error jednoducho takto:
throw CommonErrors.InvalidInputData()
Co mi pride ako prijemny vylepsovak obzvlast v pripadoch, ked sa rovnaky error pouziva na viacerych miestach. Tym zabezpecime aj ak chceme dany error pozmenit (textaci, alebo hadze nespravny errorCode), urobime tak na jednom mieste a nemusime po celej aplikacii hladat kde sa tento error hadze.
1d3d14f to
ac82f45
Compare
No description provided.