Merge pull request #185 from magento/interceptors

New way to code generate Interceptors

Author: buskamuza

design-documents/compiled_interceptors.md

@@ -0,0 +1,78 @@
+## Compiled Interceptors
+
+Proposal based on Community Pull Request https://github.com/magento/magento2/pull/22826 created by [@fsw](https://github.com/fsw)
+
+### Problem Statement
+
+Existing debugging of Magento may be tricky because of Interception implementation via dynamical calls of `___callPlugins` in the call stack.
+
+### Overview
+
+The idea is to use a mechanism which generates Interceptors code using app config instead of reading config at runtime.
+The main benefit of having this approach incorporated to Magento is improving Dev Experience while debugging and profiling Magento codebase.
+
+#### Current Code generated Interceptors
+
+```php
+public function methodX($arg) {
+    $pluginInfo = $this->pluginList->getNext($this->subjectType, 'methodX');
+    if (!$pluginInfo) {
+        return parent::methodX($arg);
+    } else {
+        return $this->___callPlugins('methodX', func_get_args(), $pluginInfo);
+    }
+}
+```
+
+#### Proposed version of Code generated Interceptors 
+
+```php
+public function methodX($arg) {
+    switch(getCurrentScope()){
+        case 'frontend':
+            $this->_get_example_plugin()->beforeMethodX($this, $arg);
+            $this->_get_another_plugin()->beforeMethodX($this, $arg);
+            $result = $this->_get_around_plugin()->aroundMethodX($this, function($arg){
+                return parent::methodX($arg);
+            });
+            return $this->_get_after_plugin()->afterMethodX($this, $result);
+        case 'adminhtml':
+            // ...
+        default:
+            return parent::methodX($arg);
+    }
+}
+```
+
+### Design
+
+The main idea is to compile the Interceptor using information from source code. 
+This makes plugins slightly faster (as we no need to resolve all plugins dynamically). 
+This is important in places where there is a lot of non-cached PHP logic going on (for example admin panel).
+
+Having plugins called directly also makes code easier to debug. The Interceptors generated by this approach are fully compatible with the ones generated by Magento 
+currently, so there is no need to change anything in existing plugins.
+
+The new implementation should be optional, and can be chosen by modifying DI configuration, so that each developer can chose the best option for them.
+For the next minor release of Magento product, collect developers feedback and consider removing one of the implementations.
+This will help reduce maintenance cost and confusion by leaving a single way of working with plugins. 
+
+To improve developer experience, a file watcher can be used to regenerate only necessary files when plugins or `di.xml` change. Similar to Node Watch https://www.npmjs.com/package/node-watch
+
+
+#### PROS
+
+1. Easier Debugging process as there is no anymore dynamic method execution via `___callPlugins` (No  calls to ___callPlugins in call stack).
+2. Slightly Faster response time for uncached code in production mode 
+
+#### CONS 
+
+1. Each time after making change in plugins declaration (di.xml) or adding/modyfing the source code of pluings, generated/code/* needs to be purged. 
+2. Longer execution and higher memory consumption while the whole code generation phase - https://github.com/magento-engcom/msi/issues/2269#issuecomment-499551378
+3. Higher latency for the first warmup request and corresponding generation in Dev Mode - https://github.com/magento/magento2/pull/22826#issuecomment-491949914
+
+
+### Discusssions and Public Involvements
+
+- [YouTube recording of Architectural Discussion](https://www.youtube.com/watch?v=no2jVn_mixk&list=PLDvMskiz68Q3ZVyRsc59IjEqX85LaO8mr&index=16)
+- https://github.com/creatuity/magento2-interceptors