Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared vs common imports #564

Open
basmasking opened this issue Oct 23, 2024 · 0 comments
Open

Shared vs common imports #564

basmasking opened this issue Oct 23, 2024 · 0 comments
Labels
feature New feature or request

Comments

@basmasking
Copy link
Member

basmasking commented Oct 23, 2024

Currently, all non-segmented modules share state with all segments running on the same worker node. This setup simplifies the use of shared resources, such as the database. However, since most modules do not (and should not!) maintain state, we propose adding a configuration option to enable or disable state sharing.

For the separation, we will use the following terminology:

  • shared: modules that share state
  • common: modules that do NOT share state

In summary, the following steps need to be taken:

  1. Set all non-segmented imports to be common by default.
  2. Explicitly define shared imports for each segment.

To achieve the first goal, we need to replace dynamic imports with static imports. For the second goal, we need to introduce an additional access level, "shared", to indicate a shared import. For example:

[name].segment.json

{
    "./integrations/database/module":
    {
        "default": { "access": "shared" }
    }
}

Modules with "shared" access will be imported dynamically to ensure they are excluded from the bundling process.

@basmasking basmasking added the feature New feature or request label Oct 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant