Deep Dive: MobX Architecture Analysis - Models, Services, and Stores #3758
webberwang
started this conversation in
General Discussions
Replies: 7 comments
-
Neo4j Schema Types and DTO ArchitectureThis section provides a comprehensive analysis of the Neo4j schema types and Data Transfer Object (DTO) interfaces in the Codelab platform. Neo4j Schema ArchitectureSchema OrganizationAll Neo4j schemas are located in
Core Schema Categories1. User & Authorization
2. Application Structure
3. Type SystemComprehensive type system supporting:
4. Data & State Management
5. Actions System
6. Supporting Models
Neo4j RelationshipsTree Structure RelationshipsOwnership RelationshipsComponent ArchitectureType System RelationshipsAction RelationshipsDTO ArchitectureDTO OverviewThe platform uses 49 DTO interface files with TypeBox for runtime validation: DTO Organization1. Shared Core DTOs (
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Detailed File Locations by Nx LibrarySchema Files (83 total)backend-infra-adapter-neo4j-schema (19 files)Frontend Application Schemas (30 files across 12 libraries)Frontend Presentation Schemas (18 files across 2 libraries)Shared Infrastructure Schemas (9 files)DTO Interface Files (51 total)shared-abstract-core (41 files)frontend-abstract-application (1 file)frontend-abstract-domain (9 files)Summary by Library TypeBackend Libraries
Frontend Libraries
Shared Libraries
This comprehensive file structure supports:
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Correction: Neo4j Schema Files OnlyThe previous comment included all Neo4j Schema Files (19 files in
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Updated Architecture Analysis with Neo4j Schemas and DTOsNeo4j Schema Files (19 files)Type System Hierarchy (from Neo4j
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Nx Monorepo Architecture and Directory StructureThis section provides a comprehensive analysis of the Codelab platform's monorepo organization using Nx. Monorepo Structure OverviewThe Codelab platform uses an enterprise-grade Nx monorepo with clear architectural boundaries following Domain-Driven Design (DDD) and Clean Architecture principles. Directory OrganizationLibrary Architecture PatternEach stack ( Layer Definitions
Dependency RulesKey Rules:
Shared Libraries ArchitectureShared libraries provide the bridge between frontend and backend: Domain OrganizationThe platform is organized around 16 core business domains:
Project Naming ConventionImport Path: Examples:
Key Architectural Benefits
Project ConfigurationEach project includes:
Technology Stack by LayerFrontend Stack:
Backend Stack:
Shared Technologies:
This monorepo structure enables the Codelab platform to maintain a complex visual application builder while ensuring maintainability, type safety, and clear architectural boundaries. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Next.js App Router Architecture in apps/webThis section analyzes the folder structure, routing patterns, and data fetching architecture of the main web application. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Next.js App Router Architecture in apps/webThis section analyzes the folder structure, routing patterns, and data fetching architecture of the main web application. Folder Structure OverviewParallel Routes ArchitectureThe app makes extensive use of Next.js 13+ parallel routes for composable UI: Common Parallel Route Slots:
Example: Apps List Page Structure// apps/(list)/layout.tsx
export default function Layout({
children,
header,
modal,
}: {
children: React.ReactNode
header: React.ReactNode
modal: React.ReactNode
}) {
return (
<DashboardLayout
header={header}
modal={modal}
>
{children}
</DashboardLayout>
)
}Modal Routes Pattern:Server Components and Data Fetching1. Server Component PatternMost pages are async server components that fetch data before rendering: // Typical page.tsx pattern
const Page = async (props: PageProps) => {
// Parse params/searchParams
const context = await parsePageProps(props)
// Fetch data server-side
const { items, aggregate } = await getAppsQuery(context)
// Return hydrated client component
return (
<DomainStoreHydrator apps={items}>
<AppsList />
</DomainStoreHydrator>
)
}2. Data Fetching Flow3. Authentication Flow// (authenticated)/layout.tsx
export default async function Layout({ children }) {
// Get authenticated user or redirect
const user = await getServerUser()
// Fetch user preferences
const preferences = await getPreferences(user.id)
// Preload common data
preloadAppsQuery()
preloadAtomsQuery()
return (
<RootProviders user={user} preferences={preferences}>
{children}
</RootProviders>
)
}4. Server Functions UsedAuthentication:
Data Queries:
Data Mutations (Server Actions):
Middleware Configuration// middleware.ts key features
export async function middleware(request: NextRequest) {
// 1. Auth check for protected routes
if (pathname.startsWith("/apps")) {
const session = await getSession(request)
if (!session) {
return NextResponse.redirect("/auth/login")
}
}
// 2. API request authentication
if (pathname.startsWith("/api/v1")) {
headers.set("Authorization", `Bearer ${token}`)
}
// 3. Pagination defaults
if (["/atoms", "/tags", "/types"].includes(pathname)) {
url.searchParams.set("pageSize", "50")
}
}Layout CompositionProvider Hierarchy:Key Architectural Patterns
Performance Optimizations
apps/sites Structure (Production Rendering)The Key differences from apps/web:
This architecture leverages Next.js App Router advanced features to create a sophisticated dashboard application with complex UI requirements while maintaining clean separation between server and client responsibilities. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Overview
This is a comprehensive analysis of the MobX architecture in the Codelab platform, covering models, services, and stores. This analysis was created to understand the state management patterns before investigating the RootRenderer component lifecycle and fixing TypeRef resolution issues.
Table of Contents
MobX Models Overview
The platform contains 45 MobX model files organized into several categories:
Model Categories:
Model Patterns:
All models follow consistent patterns using mobx-keystone:
@modeldecorators for registrationcreatefactory methods@computed@modelActionRef<T>toJsonmethodswriteCachemethodsMobX Services Architecture
Found 47 service files organized into three layers:
1. Application Layer Services (
libs/frontend/application/*)2. Domain Layer Services (
libs/frontend/domain/*)MobX-Keystone models that manage domain state with consistent naming pattern:
*.domain.service.ts3. Infrastructure Services (
libs/frontend/infra/*)Technical concerns like browser logging
Service Patterns:
Domain Services Pattern:
Application Services Pattern:
MobX Store Hierarchy
Three-Tier Architecture:
Core Domain Models Analysis
1. App Model
2. Page Model
3. Element Model
4. Component Model
5. Prop Model
6. Store Model
7. Atom Model
Key Patterns and Design Decisions
1. Reference System
2. Tree Structure
3. Type System Integration
4. Immutability
5. Separation of Concerns
6. Factory Pattern
7. Context System
Next Steps
This analysis forms the foundation for understanding:
The TypeRef issue appears to be related to the Atom model's
apifield not being included in production queries, which breaks the reference system when the renderer tries to access type information.Related Issues
Beta Was this translation helpful? Give feedback.
All reactions