Я создаю сайт бронирования авиабилетов, мне нужно обрабатывать регистрацию пользователей, аутентификацию, бронирование, карту мест и т. д. Я использую 2 API на 2 языках (.NET в API, который обрабатывает поиск рейсов, бронирование и оплата и JS в другом API для обновления карты мест в реальном времени и управления слоями кэширования для повторного поиска рейсов) + внешний компонент с NextJS и Tailwind.
Я пытаюсь использовать монорепо с Nx, но меня смущает то, как это должно быть организовано.
На данный момент я создал 3 приложения (api-js, api-dotnet, интерфейс) с такой структурой:
/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
Каждый API имеет свои собственные модели классов, контроллеры и т. д.
Но, глядя на веб-сайт, он утверждает, что:
Nx имеет концепцию приложений и библиотек. Приложения можно рассматривать как развертываемые артефакты, а библиотеки включают в себя большую часть фактического кода и бизнес-логики. Тем не менее, нет ничего необычного, когда вы впервые начинаете работать с Nx, помещаете в свои приложения много кода и используете библиотеки только для общего кода. Но когда вы переходите на монорепозиторий Nx, вам следует попытаться структурировать свой репозиторий «путем Nx». Это означает, что вы вообще не должны помещать код в свои приложения и почти весь код должен располагаться в ваших библиотеках. Даже код, который не будет использоваться совместно приложениями, следует помещать в библиотеки. На первый взгляд это может показаться немного нелогичным, но если вы примените эту структуру, она поможет вам поддерживать порядок в монорепозитории. Кроме того, таким образом вы будете хорошо подготовлены, если в будущем возникнет необходимость в совместном использовании или повторном использовании библиотеки где-то еще. Если вы используете единообразную структуру папок и стратегию именования для своих библиотек, вы получите монорепозиторий, работать в котором будет приятно.
Итак правильная ли эта структура?:
/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
Подробнее здесь: https://stackoverflow.com/questions/792 ... repo-on-nx
Какова правильная структура многоязычного монорепозитория на Nx? ⇐ C#
Место общения программистов C#
-
Anonymous
1732820702
Anonymous
Я создаю сайт бронирования авиабилетов, мне нужно обрабатывать регистрацию пользователей, аутентификацию, бронирование, карту мест и т. д. Я использую 2 API на 2 языках (.NET в API, который обрабатывает поиск рейсов, бронирование и оплата и JS в другом API для обновления карты мест в реальном времени и управления слоями кэширования для повторного поиска рейсов) + внешний компонент с NextJS и Tailwind.
Я пытаюсь использовать монорепо с Nx, но меня смущает то, как это должно быть организовано.
На данный момент я создал 3 приложения (api-js, api-dotnet, интерфейс) с такой структурой:
/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
Каждый API имеет свои собственные модели классов, контроллеры и т. д.
Но, глядя на веб-сайт, он утверждает, что:
Nx имеет концепцию приложений и библиотек. Приложения можно рассматривать как развертываемые артефакты, а библиотеки включают в себя большую часть фактического кода и бизнес-логики. Тем не менее, нет ничего необычного, когда вы впервые начинаете работать с Nx, помещаете в свои приложения много кода и используете библиотеки только для общего кода. Но когда вы переходите на монорепозиторий Nx, вам следует попытаться структурировать свой репозиторий «путем Nx». Это означает, что вы вообще не должны помещать код в свои приложения и почти весь код должен располагаться в ваших библиотеках. Даже код, который не будет использоваться совместно приложениями, следует помещать в библиотеки. На первый взгляд это может показаться немного нелогичным, но если вы примените эту структуру, она поможет вам поддерживать порядок в монорепозитории. Кроме того, таким образом вы будете хорошо подготовлены, если в будущем возникнет необходимость в совместном использовании или повторном использовании библиотеки где-то еще. Если вы используете единообразную структуру папок и стратегию именования для своих библиотек, вы получите монорепозиторий, работать в котором будет приятно.
Итак правильная ли эта структура?:
/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
Подробнее здесь: [url]https://stackoverflow.com/questions/79235094/what-is-the-correct-structure-of-a-multi-language-monorepo-on-nx[/url]
Ответить
1 сообщение
• Страница 1 из 1
Перейти
- Кемерово-IT
- ↳ Javascript
- ↳ C#
- ↳ JAVA
- ↳ Elasticsearch aggregation
- ↳ Python
- ↳ Php
- ↳ Android
- ↳ Html
- ↳ Jquery
- ↳ C++
- ↳ IOS
- ↳ CSS
- ↳ Excel
- ↳ Linux
- ↳ Apache
- ↳ MySql
- Детский мир
- Для души
- ↳ Музыкальные инструменты даром
- ↳ Печатная продукция даром
- Внешняя красота и здоровье
- ↳ Одежда и обувь для взрослых даром
- ↳ Товары для здоровья
- ↳ Физкультура и спорт
- Техника - даром!
- ↳ Автомобилистам
- ↳ Компьютерная техника
- ↳ Плиты: газовые и электрические
- ↳ Холодильники
- ↳ Стиральные машины
- ↳ Телевизоры
- ↳ Телефоны, смартфоны, плашеты
- ↳ Швейные машинки
- ↳ Прочая электроника и техника
- ↳ Фототехника
- Ремонт и интерьер
- ↳ Стройматериалы, инструмент
- ↳ Мебель и предметы интерьера даром
- ↳ Cантехника
- Другие темы
- ↳ Разное даром
- ↳ Давай меняться!
- ↳ Отдам\возьму за копеечку
- ↳ Работа и подработка в Кемерове
- ↳ Давай с тобой поговорим...
Мобильная версия