Was ist die korrekte Struktur eines mehrsprachigen Monorepo auf NX? ⇐ C#

[Guest]

Ich baue eine Flugbuchungswebsite, ich muss die Registrierung, Authentifizierung, Buchung, SeatMap usw. Benutzerregistrierung verarbeiten. Ich verwende 2 APIs in 2 Sprachen (.NET in einer API, die die Flugsuche, Buchung und Buchung und Buchung und Buchung verhandelt. Bezahlung; und JS in einer anderen API für die Aktualisierung der Sitzkarte in Echtzeit und die Verwaltung von Caching-Ebenen für wiederholte Flugsuche) + Eine Frontend-Komponente mit NextJs und Rückenwind. < /p>
Ich versuche es Um ein Monorepo mit NX zu verwenden, bin ich mit der Art und Weise verwechselt, wie ich organisiert werden soll. mit dieser Struktur: < /p>

Code: Select all

/monorepo-root
├── /apps                   # Contains minimal, app-specific setup
│   ├── /frontend           # Entry point for the frontend (Next.js)
│   ├── /api-js             # Node.js API with REST operations
│   ├── /api-dotnet         # .NET API REST
├── /libs                   # Reusable code
│   ├── /ui                 # Shared UI components
│   │   ├── /components     # Reusable UI elements like buttons, modals
│   │   └── /layouts        # Shared page layouts
│   ├── /utils              # Shared utilities and helper functions
├── /date           # Date manipulation helpers

< /code>
Jede API hat in ihren eigenen Klassenmodellen, Controllern usw.
aber nach einer Website heißt es: < /p>

nx hat ein Konzept von Apps und Libs. Apps können als einsetzbare Artefakte und LIBs angesehen werden, enthalten den größten Teil des tatsächlichen Codes und der Geschäftslogik. Es ist dennoch nicht ungewöhnlich, wenn Sie zum ersten Mal mit NX arbeiten, viel Code in Ihre Apps einfügen und Libs nur für gemeinsam genutzten Code verwenden. Wenn Sie jedoch zu einem NX -Monorepo wechseln, sollten Sie versuchen, Ihr Repository „The NX Way“ zu strukturieren. Das bedeutet, dass Sie fast keinen Code in Ihre Apps einfügen und fast den gesamten Code in Ihren Libs befinden sollten. Sogar Code, der nicht zwischen Apps geteilt wird, sollten in LIBs gesteckt werden. Das mag zunächst ein bisschen kontrastisch erscheinen, aber wenn Sie diese Struktur anwenden, hilft Ihnen dies, Ihr Monorepo organisiert zu halten. Auf diese Weise sind Sie gut vorbereitet, wenn es notwendig wird, dass eine LIB in Zukunft geteilt oder wiederverwendet wird. Wenn Sie eine konsistente Ordnerstruktur und -namenstrategie für Ihre LIBs verwenden Ist diese Struktur korrekt?: < /p>
/monorepo-root
├── /apps
|     ├── api-dotnet
│     |   ├── Program.cs                 # Bootstrapping the app
│     |   ├── Startup.cs (optional)      # Additional app configuration if needed
│     |   ├── appsettings.json           # App-specific configuration
│     |   ├── All Visual Studio Created files and folders (.csproj, bin, obj, etc)
│     |
|     ├── api-js
|     |   ├── index.js
|
├── /libs
│   ├── /ui                 # Shared UI components
│   │   ├── /components     # Reusable UI elements like buttons, modals
│   │   └── /layouts        # Shared page layouts
│   ├── /utils              # Shared utilities and helper functions
|   |   ├── /date           # Date manipulation helpers
│   ├── /features           # App-specific features, organized by domain
│   │   ├── /auth           # Authentication logic (e.g., login, register)
│   │   ├── /flight-search  # Flight search feature logic
│   │   └── /profile        # User profile management
│   └── /data-access        # Data-related code like database models, services
│       ├── /frontend-api   # Frontend API services
│       ├── /api-js-models  # Models and services for the Node.js API
│       └── /api-dotnet     # Data-related logic for .NET