Modules

OpenSya is the open-source recruitment infrastructure for modern companies.

Modular, scalable, and fully owned by you.

Modules are the foundation of OpenSya extensibility. They allow teams to package, share and compose features as runtime-aware infrastructure units.

What is a Module?

A module is an isolated feature unit that can extend an OpenSya application.

A module can provide:

• Backend controllers
• Backend services
• Database models
• Database plugins
• Guards
• Locales
• Frontend pages
• Frontend components
• Frontend plugins
• Runtime configuration

Examples of modules:

Why Modules?

OpenSya is designed for recruitment infrastructures that evolve over time.

Companies may need different workflows, custom data models, integrations or deployment strategies.

Modules allow teams to:

• Extend the platform without modifying the core
• Isolate business domains
• Reuse features across projects
• Share infrastructure units
• Build a long-term ecosystem

Module Philosophy

OpenSya modules are designed around four ideas:

1. Isolation
2. Runtime registration
3. Interoperability
4. Ownership

A module should be able to evolve independently while still being orchestrated by the OpenSya runtime.

Module
  ↓
Runtime Registration
  ↓
OpenSya Orchestration
  ↓
Application Integration

Module Structure

A module can follow the same fullstack conventions as an OpenSya application.

my-module/
├── server/
│   ├── controllers/
│   ├── services/
│   ├── database/
│   │   ├── models/
│   │   └── plugins/
│   ├── guards/
│   └── locales/
│
├── client/
│   ├── pages/
│   ├── components/
│   └── plugins/
│
└── opensya.module.ts

The server/ directory extends the backend runtime.

The client/ directory extends the frontend runtime.

The opensya.module.ts file declares module metadata and runtime behavior.

Runtime Registration

Modules are discovered and registered by the OpenSya runtime.

During registration, OpenSya can:

• Read module metadata
• Resolve dependencies
• Register backend definitions
• Register frontend definitions
• Merge locales
• Load module configuration
• Expose runtime contracts

Module Discovery
        ↓
Metadata Loading
        ↓
Dependency Resolution
        ↓
Runtime Registration
        ↓
Application Integration

Backend Extensions

A module can extend the backend runtime with controllers, services, models and guards.

Example:

server/
├── controllers/
│   └── interviews/
│       └── index.get.ts
├── services/
│   └── interviews/
│       └── list.ts
└── database/
    └── models/
        └── interview-session.ts

These files are discovered and orchestrated by OpenSya using the same runtime conventions as the main application.

Frontend Extensions

A module can also extend the frontend runtime.

Example:

client/
├── pages/
│   └── interviews.vue
├── components/
│   └── InterviewCard.vue
└── plugins/
    └── interviews.ts

The frontend runtime is delegated to Nuxt, while OpenSya provides shared conventions and module integration.

Locales

Modules can provide their own translations.

server/locales/
├── en/
│   └── common.json
└── fr/
    └── common.json

Module locales can be merged with native and application-level translations.

This allows modules to expose their own labels, errors and runtime messages.

Dependencies

Modules may depend on other modules.

Example:

analytics
└── depends on recruitment

A module system should make dependencies explicit so the runtime can load modules in the correct order.

Future module APIs may expose this through module metadata.

export default defineOpenSyaModule({
  name: 'analytics',

  dependencies: ['recruitment'],
});

Interoperability

Modules should be designed to work together.

They may communicate through:

• Services
• Runtime events
• Shared typings
• Public APIs
• Module configuration
• Database models

The goal is to avoid tightly coupled modules while keeping the infrastructure composable.

Creating a Module

The OpenSya CLI provides a dedicated template for modules.

pnpm create opensya my-module --template module

yarn create opensya my-module --template module

npm create opensya my-module -- --template module

bun create opensya my-module --template module

A dedicated guide will cover module creation step by step.

Best Practices

Keep Modules Focused

A module should represent one clear domain or capability.

Good examples:

• recruitment
• interviews
• notifications
• analytics

Avoid creating large modules that own unrelated features.

Avoid Hidden Coupling

Prefer explicit dependencies and public contracts.

A module should not silently depend on internal implementation details from another module.

Keep Runtime Definitions Conventional

Use the same OpenSya conventions as applications:

server/controllers/
server/services/
server/database/
client/pages/
client/components/

Design for Ownership

Modules should support self-hosted and fully owned infrastructures.

Avoid hard-coding external services or vendor-specific assumptions when possible.

Philosophy

Modules are how OpenSya grows from a runtime into an extensible infrastructure platform.

They allow modern companies to build recruitment systems that are modular, scalable and fully owned.

Instead of locking teams into a fixed SaaS workflow, OpenSya modules make the platform adaptable to real business needs.