New Feature / Enhancement Checklist
Current Limitation
Currently, Parse Server appears to load the default Push adapter during startup even when Push is not configured.
In getPushController(), @parse/push-adapter seems to be loaded before hasPushSupport is determined from the presence of the push configuration. This means deployments that do not use Push may still go through part of the Push initialization path.
@parse/push-adapter is already a separate package, so this issue is not about creating a new Push package. The smaller limitation here is runtime behavior: Push-related code should ideally not be loaded or initialized unless Push is actually enabled.
This matters because many Parse Server deployments do not use Push notifications, especially API-only, serverless, worker, or backend-only deployments.
Feature / Enhancement Description
Lazy-load and initialize Push only when push is configured.
A possible implementation approach:
-
In getPushController(), check whether options.push exists before loading @parse/push-adapter.
-
If push is not configured:
- do not call
loadModule('@parse/push-adapter');
- do not create a default Push adapter;
- do not create a Push worker;
- only create the minimum no-op/default controller state required by Parse Server internals.
-
If push is configured:
- keep the current behavior;
- load the bundled
@parse/push-adapter;
- support custom
push.adapter;
- initialize Push queue / Push worker as today.
-
Preserve backward compatibility for users who configure Push.
This would be a smaller and lower-risk change than changing the dependency relationship between parse-server and @parse/push-adapter. Making @parse/push-adapter optional or peer-installed could be considered later, but the first step would simply be to avoid loading Push when it is not used.
Example Use Case
- A developer runs Parse Server without Push notifications configured.
- Their configuration does not include a
push key.
- Parse Server starts normally.
- Parse Server does not load
@parse/push-adapter.
- Parse Server does not initialize a Push adapter or Push worker.
- The deployment avoids unnecessary startup work for a feature it does not use.
This is especially useful for deployments where startup time and dependency loading matter, such as serverless containers, small Docker images, test environments, or backend-only Parse Server deployments.
Alternatives / Workarounds
Currently, there does not seem to be a complete workaround for avoiding the default Push adapter load path when Push is not configured.
push.queueOptions.disablePushWorker can disable the Push worker when Push configuration exists, but it does not address the case where a deployment does not use Push at all and wants to avoid loading or initializing Push-related code.
Another possible future improvement would be to make @parse/push-adapter an optional peer dependency, but that would be more breaking and probably belongs to a later major-version discussion.
3rd Party References
Related broader modularity discussion:
That issue discusses code splitting and loading only the adapters / servers that a deployment actually needs. Push lazy-loading could be a small, concrete first step in that direction.
New Feature / Enhancement Checklist
Current Limitation
Currently, Parse Server appears to load the default Push adapter during startup even when Push is not configured.
In
getPushController(),@parse/push-adapterseems to be loaded beforehasPushSupportis determined from the presence of thepushconfiguration. This means deployments that do not use Push may still go through part of the Push initialization path.@parse/push-adapteris already a separate package, so this issue is not about creating a new Push package. The smaller limitation here is runtime behavior: Push-related code should ideally not be loaded or initialized unless Push is actually enabled.This matters because many Parse Server deployments do not use Push notifications, especially API-only, serverless, worker, or backend-only deployments.
Feature / Enhancement Description
Lazy-load and initialize Push only when
pushis configured.A possible implementation approach:
In
getPushController(), check whetheroptions.pushexists before loading@parse/push-adapter.If
pushis not configured:loadModule('@parse/push-adapter');If
pushis configured:@parse/push-adapter;push.adapter;Preserve backward compatibility for users who configure Push.
This would be a smaller and lower-risk change than changing the dependency relationship between
parse-serverand@parse/push-adapter. Making@parse/push-adapteroptional or peer-installed could be considered later, but the first step would simply be to avoid loading Push when it is not used.Example Use Case
pushkey.@parse/push-adapter.This is especially useful for deployments where startup time and dependency loading matter, such as serverless containers, small Docker images, test environments, or backend-only Parse Server deployments.
Alternatives / Workarounds
Currently, there does not seem to be a complete workaround for avoiding the default Push adapter load path when Push is not configured.
push.queueOptions.disablePushWorkercan disable the Push worker when Push configuration exists, but it does not address the case where a deployment does not use Push at all and wants to avoid loading or initializing Push-related code.Another possible future improvement would be to make
@parse/push-adapteran optional peer dependency, but that would be more breaking and probably belongs to a later major-version discussion.3rd Party References
Related broader modularity discussion:
That issue discusses code splitting and loading only the adapters / servers that a deployment actually needs. Push lazy-loading could be a small, concrete first step in that direction.