백엔드 시스템 명명 패턴
이것들은 백엔드 시스템 내에서 준수해야 하는 명명 패턴이에요. 패키지 간 내보내기를 일관되게 유지하고 내보내기의 용도와 의도를 이해하기 쉽게 만들어요.
출처: 문서
본문
이것들은 백엔드 시스템 내에서 준수해야 하는 명명 패턴이에요. 패키지 간 내보내기를 일관되게 유지하고 내보내기의 용도와 의도를 이해하기 쉽게 만들어요.
일반적으로 모든 이름은 camel case여야 하며, 예외는 kebab case여야 하는 플러그인과 모듈 ID예요.
플러그인
| 설명 | 패턴 | 예 | 참고 |
| export | <camelId>Plugin | catalogPlugin, userSettingsPlugin | |
| ID | '<kebab-id>' | 'catalog', 'user-settings' | 문자, 숫자, 대시, 문자로 시작 |
예시:
export const userSettingsPlugin = createBackendPlugin({ pluginId: 'user-settings', ...})
모듈
| 설명 | 패턴 | 예 | 참고 |
| export | <pluginId>Module<ModuleId> | catalogModuleGithubEntityProvider | |
| ID | '<module-id>' | 'github-entity-provider' | 문자, 숫자, 대시, 문자로 시작 |
예시:
export const catalogModuleGithubEntityProvider = createBackendModule({ pluginId: 'catalog', moduleId: 'github-entity-provider', ...})
확장
| 설명 | 패턴 | 예 |
| 인터페이스 | <PluginId><Name>ExtensionPoint | CatalogProcessingExtensionPoint |
| 참조 | <pluginId><Name>ExtensionPoint | catalogProcessingExtensionPoint |
| ID | '<pluginId>.<name>' | 'catalog.processing', 'foo.barBaz' |
예시:
export interface CatalogProcessingExtensionPoint { ...}export const catalogProcessingExtensionPoint = createExtensionPoint<CatalogProcessingExtensionPoint>({ id: 'catalog.processing', ...})
서비스
| 설명 | 패턴 | 예 |
| 인터페이스 | <Name>Service | LoggerService, DatabaseService |
| 참조 | <name>ServiceRef | loggerServiceRef, databaseServiceRef |
| ID | <pluginId>.<name> | 'core.rootHttpRouter', 'catalog.catalogClient' |
| 팩토리 | <name>ServiceFactory | loggerServiceFactory, databaseServiceFactory |
예시:
export interface CatalogClientService { ...}export const catalogClientServiceRef = createServiceRef<CatalogClientService>({ id: 'catalog.catalogClient', ...})export const catalogClientServiceFactory = createServiceFactory({ service: catalogClientServiceRef, ...})
위 서비스 참조 명명 패턴에는 핵심 API의 모든 핵심 서비스를 위해 예외가 만들어졌어요. @backstage/backend-plugin-api는 모든 핵심 서비스 참조를 단일 coreServices 컬렉션으로 제공해요. 마찬가지로 @backstage/backend-test-utils는 모든 mock 서비스 구현을 단일 mockServices 컬렉션으로 내보내요. 이는 loggerServiceRef와 databaseServiceRef가 대신 coreServices.logger와 coreService.database로 사용 가능하므로 위 표가 약간 오해의 소지가 있음을 의미해요. 플러그인이 내보내야 할 서비스가 매우 많지 않는 한 이 패턴을 피할 것을 권장해요.
루트 범위 서비스에 Root 접두사를 붙이는 것이 종종 선호되지만 필수는 아니에요. 예를 들어 RootHttpRouterService와 RootLifecycleService는 이 패턴을 따르지만, ConfigService는 루트 범위 서비스임에도 그렇지 않아요.