architecture

Live arrays define a website: its layout, functionality, and even its queries in a way that is theoretically language and platform-independent.

Watch the session video here.

I'd like to present the case study at https://www.drupal.org/case-study/bunny-farm-framework-for-building-the…, detailing how I came up with the architecture, how it works, and why it would be useful.

The module and architecture encapsulates what I've learned over the years on how to create maintainable, fast and secure systems, supporting both decoupled (JSON) and normal Drupal output.

One of the more interesting additions to Drupal 8 is the core conditions API. Condition plugins are used to make decisions about all kinds of things like block visibility, layout choices, page manager variants, and even rules. Decisions can be based upon any available contextual information from the URL or session, as well as remote service calls, database queries, or almost any other source. 

I will walk through writing a simple condition plugin and then show some more complicated examples with configuration forms and unusual contexts.

Over the last two years our community has seen the rise of countless solutions to implement design systems and components within Drupal. During the same period across camps, cons and the internet at large Adam and Brian have been having an ongoing conversation about best practices in component based development.  

In many ways, my journey through Drupal has been inverted. After studying Computer Science, I began my Drupal career as a backend developer writing custom modules and dabbling in front-end work. More recently, as a Project Manager and Drupal Solutions Architect, I've focused on more site-building and organizing Drupal elements into flexible solutions. I've found myself relying on the theory I learned in school to direct my site building efforts.

Have you ever faced the need to fulfill the requirements of different business units within one docroot? Have you ever needed to build parts of your website to be separate entities and multi-site architecture wasn't an option?

Introduction of microservices promised faster project maintenance and debugging, easier scaling, high availability and lots of good, old, developer fun. However, a huge ecosystem of sometimes mutually incompatible tools and the lack of guidelines made the concept too scary for most of the teams.

Early adopters and teams with appropriate budgets started experimenting and building their own tools. The rest of us were attending conferences and trying to get the big picture from multiple, often dissonant sources.

Jigsaw puzzles are a fun way to test your ability to create and execute a strategy as well as testing your eye for spotting details. Drupal sites, like jigsaw puzzles, come in a variety of shapes, sizes, and complexities. Finding the best architecture for a particular Drupal site depends on these facets and more. How do you architect for different sized projects? What are some of the techniques that are used on each and every project? How do you break down the project and create the right strategy for implementation? How do you manage the build?