Work with Only Client and Package Projects

[Sharafudeen]

When creating an Oqtane module using the default module template, four projects are generated: Client, Server, Shared, and Package.

In some scenarios, the module only consumes external APIs directly from the Client project and does not require any server-side processing, database access, or shared models. In such cases, the Server and Shared projects appear unnecessary.

Can an Oqtane module function correctly with only the Client and Package projects? Are there any limitations, risks, or best-practice recommendations for adopting this simplified architecture? I would appreciate insights from anyone who has implemented a similar approach.

[sbwalker]

@Sharafudeen the default module template is designed to work in every possible run-time scenario available in Oqtane (ie. Static Blazor, Blazor Server, Blazor WebAssembly, Blazor Hybrid) and demonstrate nearly every framework capability. If you are developing a module for a specific run-time scenario or with limited functionality then you can remove any of the aspects which are not applicable to that scenario.

For example, if your module does not have any server-side functionality you can remove the Server and Shared projects. Or if your module is only intended to be used with Static Blazor and Blazor Server then you can remove the Services in the Client project and the Controllers in the Server project. Or if your module does not need import/export or search functionality, you can remove the interface implementations from the manager class. There are nearly unlimited variations which are possible.

The following blog from 3 years ago attempts to clarify the fact that the default module template is intended to be a functional starting point for a module - but it can be heavily customized to meet your own specific needs: https://www.oqtane.org/blog/!/67/dapper-sql-scripts

[Sharafudeen]

@sbwalker Thank you for the clarification. This is very helpful.

One suggestion: it may be beneficial to provide 2–3 additional module templates tailored to common development scenarios. This could help new Oqtane developers better understand how different module architectures fit various business requirements and reduce the need to manually remove unnecessary projects after creation.

For example, templates could be offered for:

• Client + Package only (API-driven modules)
• Client + Server + Package (full-stack modules)
• Full template (Client + Server + Shared + Package) for maximum flexibility

Including a brief description of the intended use case for each template could help developers get started more quickly and choose the most appropriate foundation for their projects.

[sbwalker]

@Sharafudeen this suggestion has come up before and my answer is the same... this is the perfect opportunity for the community to get involved and create/maintain some templates. Templates can be packaged and installed as standard modules.

[Sharafudeen]

@sbwalker Sure. Will do my best. Thanks!