🏁
Best Practices
  • Introduction
  • The Big Picture
    • Principles
      • Software engineers solve business problems
      • Programming is a social activity
      • Attention is the most precious resource in a project
      • Simplicity is the best ally in the long run
      • The only problem to solve is the one we have today
    • Architecture
      • Domain
      • Services
      • Persistence
      • HTTP
      • UI
    • Naming
  • Constraints
    • TypeScript
    • Monorepo
    • Monolith
    • Versioning
  • Source code
    • Declarative programming
    • The README
    • Modules
    • Folder structure
    • Code formatting
    • Code comments
  • The Outside World
    • Runtime configuration
    • Logging
  • Testing
    • The purpose of testing
      • End-to-end tests
      • Integration tests
      • Unit tests
  • Tools
    • Git
  • Resources
    • Resources
Powered by GitBook
On this page
  • UI and HTTP
  • Declarative UI

Was this helpful?

  1. The Big Picture
  2. Architecture

UI

From an architectural point of view, the user interface is a client to the public HTTP layer - and mostly talks the language of the HTTP layer.

UI and HTTP

It is OK to import domain modules into the UI layer (but not others, obviously).

Once GraphQL is introduced into the stack, the graph types might be slightly different from the domain types, causing annoying issues. For this reason, it's best to stick to the graph's language here.

Use a type generator to minimise effort. These can turn graph types into static type definitions for the UI, resulting in end-to-end type safety.

Declarative UI

There are many great UI libraries and frameworks today. React is suggested here because it's a declarative and functional solution.

See thekarel/best-practices-example for examples.

PreviousHTTPNextNaming

Last updated 5 years ago

Was this helpful?