Problem/Motivation

JSON:API recently implemented #3022584: Consolidate and simplify NormalizerValue objects: introduce CacheableNormalization. Right now, the major issue with the whole serialization system is that it doesn't return the cacheablity metadata. Any external app which wants to relay on Drupal cacheablity metadata to cache the response on the client side cannot do it, if one want to expose the cacheablity metadata. Even in Drupal to cache the response JSON:API has to jump so many hoops see the patch committed in #3022584: Consolidate and simplify NormalizerValue objects: introduce CacheableNormalization.

Proposed resolution

Introduce new CacheableNormalization domain object so that every Normalizer can return the cacheablity metadata and entities can bubble appropriate cacheablity metadata.
Something like


class CacheableNormalization implements CacheableDependencyInterface {

  use CacheableDependencyTrait;

  /**
   * A normalized value.
   *
   * @var mixed
   */
  protected $normalization;

Remaining tasks

To preseve the BC just like $return_as_object in \Drupal\Core\Access\AccessibleInterface::access($operation, AccountInterface $account = NULL, $return_as_object = FALSE) $context['return_as_object'] can be used in \Symfony\Component\Serializer\Normalizer\NormalizerInterface::normalize($object, $format = null, array $context = array()) to return CacheableNormalization object.

OR

CacheableNormalization can implement __toString or ArrayAccess to only return Normalized value.

User interface changes

None

API changes

Hopefully, none.

Data model changes

TBD

Release notes snippet

TBD

Comments

jibran created an issue. See original summary.

jibran’s picture

wim leers’s picture

Issue tags: +API-First Initiative

As much as I'd like to see this happen, I'm not very optimistic about the BC aspects of this. In either solution you propose, we need pretty much every normalizer in core and contrib to implement that fallback logic. 😔

And perhaps even more importantly: it violates \Symfony\Component\Serializer\Normalizer\NormalizerInterface::normalize().

gabesullice’s picture

The solution I explored for this in the JSON:API issue was to not have every normalizer be able to return a CacheableNormalization, but instead allow the serializer "upcast" raw normalizations. Then, various normalizers could start to 'opt-in' and the serializer could skip the wrapping step.

I'm sure there are problems to solve there, but it might get something rolling.

wim leers’s picture

We talked about this yesterday during the API-First meeting. @gabesullice explained his idea in more detail: where essentially the serializer service inspects each normalizer service's service tags, and if they indicate that they're returning CacheableNormalization objects, the serializer service will handle any transformations necessary to let different normalizers collaborate like they do today.

@jibran, is that sufficient, or would you like us to explain this in more detail?

gabesullice’s picture

Thinking about it more, I don't think any interfaces or service tags are actually necessary. I think it could work a bit like this:


class Serializer {

  public function normalize($object, $format, $context) {
    $return_as_object = isset($context['return_as_object']) && $context['return_as_object'];
    // Ensure that the 'return_as_object' flag does not get passed down through
    // recursive calls from normalizers which cannot handle
    // CacheableNormalization objects.
    unset($context['return_as_object']);
    $normalizer = $this->getNormalizer($object, $format, $context);
    $normalization = $normalizer->normalize($object, $format, $context);
    $has_serialization_context = isset($context[CacheableNormalizerInterface::SERIALIZATION_CONTEXT_CACHEABILITY]);
    if ($normalization instanceof CacheableNormalization) {
      if ($return_as_object) {
        return $normalization;
      }
      else {
        if ($has_serialization_context) {
          $context[CacheableNormalizerInterface::SERIALIZATION_CONTEXT_CACHEABILITY]->addCacheableDependency($normalization);
        }
        else {
          $context[CacheableNormalizerInterface::SERIALIZATION_CONTEXT_CACHEABILITY] = CacheableMetadata::createFromObject($normalization);
        }
        return $normalization->getNormalization();
      }
    }
    else {
      // deprecation notice to start requiring CacheableNormalizations.
      if ($return_as_object) {
        if ($has_serialization_context) {
          return new CacheableNormalization($context[CacheableNormalizerInterface::SERIALIZATION_CONTEXT_CACHEABILITY], $normalization);
        }
        else {
          return new CacheableNormalization(new CacheableMetadata(), $normalization);
        }
      }
      else {
        return $normalization;
      }
    }
  }

}

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

fpoirier’s picture

+1

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.