Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Symfony Extensibility

Symfony Extensibility

Avatar for Sebastian Seggewiß

Sebastian Seggewiß

December 05, 2024

Other Decks in Programming

Transcript

  1. Who are you listening to? Name: Sebastian “Segge” Seggewiß Current

    role: Engineering Lead Experience: Over 6 years at Shopware
  2. What? Let’s take a look at Shopware • Shopware has

    an initial state and features • Features are added, bugs are fi xed • The project evolves over time
  3. Why? Why Shopware is extendable • Third party developers have

    experience in other domains • A broad eco system is appealing to customers • Custom project needs should be easily adaptable
  4. At the beginning there where Bundles • To structure our

    code • The Core (Core of the PHP application) • The Storefront • The Administration • Where split into their own Bundles • Why? • Code organization • This way Shopware can be deployed without a Storefront (Headless) or without the Administration if a customer doesn’t need it
  5. Administration Bundle • Administration -> ShopwareBundle -> SymfonyBundle • In

    the build function we load our default bundle con fi guration fi les • And for example add a CompilerPass
  6. Plugins • Plugin -> ShopwareBundle -> SymfonyBundle • Other features

    like Lifecycle hooks are added. For example: • Installation • Update
  7. Bundles vs. Plugins • Plugins are loaded based on the

    information in the Database (Depending on the Plugin loader) • Bundles are loaded by con fi guration fi les on the fi lesystem
  8. Benefits • Merchants can manage extensions on their own •

    Our Extension Store o ff ers thousands of integrations • Extensions can temporarily be disabled
  9. • Access to all registered services • Direct database access

    • Able to add frontend code Plugin features
  10. Twig • Twig is not capable of multiple template inheritance

    • Multiple extension want to modify the same twig templates and blocks
  11. sw_extends • Instead of Twigs built in extends function we

    implemented our own sw_extends • The Template inheritance is built upfront and considers active Bundles, Plugins and Themes
  12. Problems? • The system is tightly coupled • Needs a

    lot of maintenance • One faulty plugin can prevent the whole application from booting • Everything accessible not stated as private will be considered public API
  13. App information • Currently app information is passed by a

    manifest fi le • This could be replaced by a registry which holds app manifest endpoints. That would completely eliminate the need for app fi les on the Shopware server
  14. Webhooks • Apps can register to all forms of Webhooks

    • On your app backend you can then modify or get additional data via the Rest API
  15. Administration • The Administration leverages iFrames and Post Message communication

    • The Meteor Admin SDK exposes public API for numerous actions. The underlying implementation details can be changed without the app developer noticing
  16. Storefront App Scripts • App scripts are a collection of

    hooks that utilize Twig to run PHP code in a sandboxed environment
  17. Public API • Be aware of your public API at

    all times • Public API is not limited to Rest API for an extension system
  18. Coupled vs. Decoupled Systems • Both systems have their bene

    fi ts • My personal opinion: Stay to decoupled systems whenever possible but acknowledge that decoupled will never be as “powerful” as coupled once