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

Make Subrequests module optional #744

Open
fiasco opened this issue Apr 21, 2024 · 1 comment
Open

Make Subrequests module optional #744

fiasco opened this issue Apr 21, 2024 · 1 comment
Labels
enhancement New feature or request triage A new issue that needs triage

Comments

@fiasco
Copy link
Contributor

fiasco commented Apr 21, 2024

Package

next (Drupal module)

Describe the feature request

I'm using next-drupal 1.x but I've opted not to leverage the sub-requests module. The primary reason for this is to opt for cache performance (subrequests uses POST which isn't cacheable) over a lower frequency of requests (subrequests reduce total number of requests although it doesn't reduce net badwidth).

I'd like to use Drupal's External Entities modules but that conflicts with Subrequests - a module I'm not using but is present and enabled in my codebase because the Next module requires it.

Describe the solution you'd like

Remove Subrequests as a required module. Perhaps move it to a composer suggested module. I'd argue that the performance given by this module in request reduction is a negative performance optimization as it stops you from leveraging application caching in Drupal, platform caching (e.g. Varnish), CDN caching and Next.js static caching (virtually all layers).

@fiasco fiasco added enhancement New feature or request triage A new issue that needs triage labels Apr 21, 2024
@JohnAlbin
Copy link
Collaborator

JohnAlbin commented Apr 24, 2024

In Drupal Slack I mentioned this context:

I’ve been thinking about this issue and doing some research. Next.js will cache POST requests, so if you are using Vercel’s env, that’s not an issue per se. However, Varnish doesn’t cache POST by default. It also won’t cache subrequest responses because they are HTTP 207 Multi-Part Status. If you can reconfigure Varnish, that’s not an issue, but if you can’t, then 2 separate GET requests will be more performant because they can be cached.

I agree that subrequests should be an optional module, not a required one.

I think we should add a useSubrequests option to next-drupal that defaults to false that can be enabled if the Drupal site uses that module.

I've put my work-in-progress into a Git branch called 744-make-subrequests-optional. It currently includes the code changes needed for the next-drupal JS package without any needed test changes. And I haven't yet looked at the changes needed in the Drupal modules.

JohnAlbin added a commit that referenced this issue Apr 24, 2024
BREAKING CHANGE:
The subrequests Drupal module is not optional and next-drupal will now only
perform JSON:API subrequests when the useSubrequests flag is enabled.

Fixes #744
JohnAlbin added a commit that referenced this issue Apr 30, 2024
BREAKING CHANGE:
The subrequests Drupal module is not optional and next-drupal will now only
perform JSON:API subrequests when the useSubrequests flag is enabled.

Fixes #744
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request triage A new issue that needs triage
Projects
None yet
Development

No branches or pull requests

2 participants