Tight Stack, Lazy Stack – PART ONE: KNOW YOUR USE CASE – PART TWO: LAYERS!

View Github Repository Open presentation in a new window

sdboyer

See all presentation from sdboyer

Tight Stack, Lazy Stack – PART ONE: KNOW YOUR USE CASE – PART TWO: LAYERS!

0 1

fatlazy

On Github sdboyer / fatlazy

Tight Stack, Lazy Stack

Sam Boyer @sdboyer

Hi everybody, my name is... Title of my talk is... In talking about Full Stack Engineering, it's important to recognize the difference between the sort of full stack we like - trim, tight, and focused - and a full stack that's lazy. So that's what I'm gonna do. And I'm gonna do it by picking on Drupal.

how many people in the crowd have used Drupal? how many would consider themselves "Drupalistas?"

Me

  • Drupaller since 2008
  • Maintain[ed] a couple of very popular modules
  • Architect of the drupal.org Git hosting platform
  • Co-lead of a Drupal 8 initiative
  • Architect-y person with NBCUniversal
  • DevOps zealot
  • Nowadays, I do PHP, Go, Ruby, JS, and Python
  • And probably, a guy who really needs a break from Drupal

Drupal

  • 13-year old PHP CMS/framlication
  • Old-school LAMP (mostly)
  • About 2% of all websites run it
  • Can run small to very big sites
  • Ginormous community

  • Drupal is a traditional server-side LAMP application
  • While it can technically run on PostgreSQL or SQLite, mysql/maria is the 98.5% use case
  • Community is ginormous. Some 25k modules (code extensions), 2k themes (in the old-school visual design, "skinning" sense)

Drupal is, itself, a full stack application

  • jQuery, jQuery UI come packaged; core ships with JS extensions to make it easier to work with Drupal's pseudo-apis
  • Every major release breaks backwards compatibility - an attempt to keep things spry.
  • Simplest way to understand Drupal the split-mind/use case: (almost) it's not a real thing until a clickable configuration option has been created.

But way more "lazy" than "tight."

OK, back up. Lazy stack? Tight stack?

Let's get meta!

So, this distinction is my key point here. Every functioning application encompasses the full stack, somehow.

So when we talk about being an FSE, we mean, "how well do you handle the whole stack?". The hidden issue there, though, is the quality of the stack you're handling. So let's talk about that!

PART ONE: KNOW YOUR USE CASE

"Full stack" starts long before bytes hit vim

The whole point of learning the full stack is so that you know the full vertical slice for solving a problem. But all that shit is useless if you don't know what problem you're trying to solve. This is similar, but different, from the role of architect: you don't necessarily have to understand *why* the layers fit together the way they do. It's OK to focus on the *how* first. You should have an intuition about what you do, and don't, want to "get for free," because you can see the inefficiencies in layer interchange.

There are approaches to this!

  • UX (kinda sorta)
  • Behavior-driven development
  • Content strategy
  • Domain modeling
DDD

if you don't at least know what these approaches are and what they emphasize, i'd challenge the idea that you're an FSE

in particular, domain modeling tells us about creating a shared vocabulary, right off the bat.

Drupal has AAAALL its own words. Good luck modeling.

Terminology is really important in domain modeling, but Drupal gets that wrong immediately. Forces use of Drupal nomenclature and concepts - entities, content types, taxonomy, view modes - to talk about major domain concepts.

Content model is *really* flexible, though.

But because that all ends up being interface-driven, Drupal ends up as "the system for people who haven't figured out their use case, yet." This is one of those key ways that the stack makes you lazy: by making it (ostensibly) easier to change data models later, a lazy mess is made of the modeling process. TODO: drop in a picture of Drupal interface vs. screenie of simple models-as-code.

So, what is Drupal's use case?

Answer: nobody knows. Anything, and nothing. For a web framework, this is mostly fine. For a CMS, it's way less fine. Again, Drupal's niche is figuring helping you figure out your use case as you go along. In a way, it's kinda a great prototyping rule. Or, it would be, if it didn't take a relaive expert to know what aspects of the prototype were relevant, and what weren't.

PART TWO: LAYERS!

Layers - the heart of FSE. They are the pieces of the stack. What can we say for Drupal? Well, it *has* a stack. jQuery, PHP, MySQL. In D8, a teensie bit of backbone, and a REST interface to content.

Full-stack-ish layers

Now, full stacks are looking increasingly diverse today, but this is still a roughly good picture. There's the client end, where you may see a frontend framework (or not), and some of what's traditionally serverside might have scooted up there, too. Then there's the serverside, which has a bunch of stuff we're all accustomed to seeing - models and business logic, sessions, routing, an ORM or DBAL of some kind. And then finally, the persistence layers, with varying degrees of volatility and canonicality. The specifics here vary, but most web applications have to answer something like this set of questions.

Drupal's layers

Drupal works from the middle, dictating most of the other layers. Everything in the middle section is bundled in and only some are "swappable". It significantly dictates output formats, making it harder to swap in a frontend framework. Only the most experienced Drupallers are now experimenting with Angular-driven frontends. It is, for most practical purposes, incompatible with NoSQL backends for persistent storage. Again, only the most advanced have done it with much success. A lot of the time, this is fine. But proper FSEs will start chafing at this sooner or later.

Modules and hooks: Drupal's stack-smoosher

Drupal's extensions are called "modules." They are generic, meaning they all can be installed in the same way. This is good. However, they also generic, meaning they all have equal access to the same mechanisms for mutating behavior and state. This is bad. The extensive control afforded to modules means that Drupal has gravitated towards, and built itself around, giant anonymous dicts/hashes/arrays of data and instructions as its primary way of doing shit. So, kinda like LISP, except with a shitty, shitty datastructure instead of a first-class one. And in PHP. Win.

Lazy stacks create bizarre problems (and knowledge)

Features. Oh god, features. Since the very structure of a Drupal instance is at least partially tracked in the database - including content types, fields, and other major systems... Features is a way of "exporting" it to code. But because it wasn't code in the first place, it gets UGLY. Updates? Changes made in the UI that aren't yet reflected in code? Changes to datastructures from upstream? A lazy stack takes you off the beaten path. You can't even see how wider, conventional wisdom applies to the situation because it's all so obscured. It makes you *learn irrelevant stuff*.

Drupal 8 improves some of this...

But we still really like letting everything bleed together.

This is improved in D8 - we've finally come around to an idea of "plugins," which participate in formal contracts to solve specific problems (caching, entities). Of course, we've also conflated all that together. Entities are Plugins. And Config entities are all three.

All that said, lazy stacks can create interesting problems

On the plus side, lazy stacks can create interesting problems, complex programming challenges. So, while getting something done in Drupal core can be difficult for other reasons, it is a good place to sharpen your skills. yammer about my rewrite of the way core assets work. 1. multiple actors, not aware of each other, that each need to register CSS/JS assets for delivery 2. need to get them all in the right order 3. need to aggregate them for optimal frontend performance 4. ideally, should aggregate with global optimality in mind...but... all of this leads to a conclusion.

SUSPECT YOUR STACK

Drupal is guilty of many poor practices. But it's generally true that *any* system you work with is going to mislead you, at least a bit. So, part of your job as a full-stack developer is to keep an eye on the difference between the standards and what you're actually doing. Otherwise, the quality of your current project will suffer, as will your ability to work in other stacks.

Lazy vs. Tight

Effort + skillCoolness of shit