Modules overview
  • 17 Apr 2024
  • 3 Minutes to read
  • Dark
  • PDF

Modules overview

  • Dark
  • PDF

Article summary

Spec to Code

While PRD-AI is the Idea→Spec part of the platform, modules are the Spec→Code part.

What is a module?

A module is a bundle of pre-certified full-code artifacts, often specialized, that provides a discrete set of capabilities. You can easily think of a module as a building block or Lego piece.

What is modular development?

Modules are part of a bigger philosophy known as modular development, where developers kind of separate out functions and pieces in order for reuse. Modular programming where developers separate program functions into independent pieces. These pieces (modules) act like building blocks, which when put together create the executable program.

Let’s look the difference between standard code and modular code.

The monolithic code block is where a lot of enterprises and companies sit today. It has no reasonable components; just a giant chunk of code.

Modular code still has a large layer of custom software that is unique to that application; however, now there are pieces of code that can be, and should be, reused that are packaged into modules.

Advantages of modular development and code:

  • Easier to read

  • Easier to test

  • Easily find things later

  • Reusability without bloat

  • Single source for faster fixes

  • Easier, lower-risk updates

  • Easier refactoring

  • Easier to collaborate

Integration with PRD-AI

After PRD-AI uses natural language to generate features and requirements, we match those features with modules. A feature explains a need in natural language and then PRD-AI links that feature to a module, which is a code capability to achieve that feature.

After the modules are paired with features, Crowdbotics assembles them together and deploys everything out into GitHub in full code.

Module Catalogs

Modules are stored in one of two catalogs:

  • Public catalog — Our public catalog is a crowdsourced set of prebuilt modules available to every Crowdbotics user. These cover the most broadly relevant functionality for consumer and B2B apps.

  • Private catalog — Your private catalog is company-specific and contains modules built by you. Only your organization can see the catalog and the modules are available to you. PRD-AI pulls from your private catalog when matching features to modules. Your catalog grows as you build more apps.

And the great thing about modules is that they are “compounding interest.” The more modules you create, the more uplift you get over time; it begins to grow and grow. Eventually, you can reach a point where you are at 70% code reuse.

Private catalog use case

Crowdbotics is proud to work with one of the world's leading manufacturers of construction, mining, forestry, and industrial heavy equipment.

The biggest and most unique point of value that Crowdbotics brought to the table was CodeOps — the reusability of code and the return on investment the business could receive by adding successive releases in the future. The company also gravitated to the idea of building a private catalog of modules that it could reuse over time.

On our first project with them, we identified up to 70 modules that could be reused, not just in that project itself, but elsewhere in the company. We've already started to deploy those modules in their private catalog as we are doing development to hit the business timelines and requirements; we are, in parallel, packaging up that code as we go and deploying it into their catalog. This means that other areas of the business can start pulling from the catalog and using those modules.

Module layers

Modules are comprised of several layers:

  • User Interface — The part of the app that users see.

  • Core Connectors — Code that connects a Crowdbotics app to back end services.

  • Policies & Config — Code that sets policy and configuration options for installed modules.

  • Workflow/Logic — Business logic layer of the application.

  • Data Model — Defines the data architecture for the application.

  • APIs — Defines APIs for accessing data models.

  • Configuration Options — Specifies elements like API keys or other assets that may need to be set for a module to function.

Modules structures can be as simple or as complex as you like. They can be made up of numerous new files and directories, or very few. Good modules are written to accomplish one thing, however complex that one thing may be, and they should be made as simple and reusable as possible. If you are writing a module, always keep in mind that future developers may use this module in a wide variety of contexts — hence, simplicity and reusability are key.

Frontend and Backend modules

We recommend using Django to create backend modules and React Native to create frontend modules.
Review the example modules in the example modules at GitHub. These examples give you some ideas about how modules function and how they are structured.

Was this article helpful?