Mateu has many of the Decoupled Drupal Hard Problems well covered, so I'll take care of one of the dumb ones.

I noticed last weekend that the build was broken for this site - post switching on the homepage wasn't working, and as you scrolled down, posts started to be wrapped in the container for the previous post. I tried a new Gatsby build and saw the same thing. Next, I zeroed in on the post where content started overlapping and eventually noticed that I had some malformed markup in my post in Drupal - a missing closing quote for a href attribute. After updating the post to add the missing quote and doing another build, everything was fine again.

You could chalk most of this up to me - if I was using a wysiwyg editor it would have added the correct link markup for me, and I should probably be taking a closer look at my build after it goes to GitHub Pages. But I think this hiccup was a nice reminder of the reality of these super sexy decoupled architectures. We lose a bit of the protection that Drupal provided us from something like malformed markup in a body field making a page explode. Builds will break in ways that they didn't with Drupal alone - the site worked fine in development mode but broke when the production bundle was built. And while testing is always important, we likely need to test in ways that are different from when we were testing Drupal by itself.

There are lessons to be learned even in the dumbest of problems. I'm sure I'll run into some more.

Learned the hard way recently that Drupal 8.4 upgrades jQuery to jQuery 3. This kills a few methods that were deprecated in previous versions of jQuery including .load(), .unload(), .error(), and .size(). The release notes cover this, but it didn't fully click until I actually ran into the issue.

Related: is a minor release really a minor release if it contains major release upgrades for a couple of your largest dependencies?

Theresa Nicholls was eager to get back home as she packed her bags at the Hyatt Regency Chicago on Friday.

Her weeklong conference of school psychologists had been rocked by the mass shooting at a Florida high school. A day earlier, a Chicago police officer had been shot and killed in the Loop, just blocks from where she and her colleagues were staying.

As she was getting ready to check out, a friend texted her: There had just been a shooting in the lobby of her hotel.

“What the hell is going on?" she thought. "What is happening? It’s like the world is falling apart around us.”

My wife was at this conference. There are a lot of reasons we need to do something about America's access to guns. Let's add this one to the list.

A great collection of resources on creating decoupled applications with Drupal and React from the Lullabot folks. Hope to contribute a link or two at some point.

I say that I'm a 'full stack' developer, even though it is a term I've never really liked all that much. The main reason that I don't like the term is because I feel like it doesn't mean that much to people. Full stack developer kind of feels like someone saying 'I'll do whatever'.

I'm not sure if it is directly related to being a full stack developer, but over the years I've seen a pattern in how I'm utilized. In my various roles as a developer, I often start out doing front end work, and then over time find myself doing predominantly back end work. This could be because back end work has a higher value at the places I've worked. It also could be because I suck at front end and just don't know it (hopefully not that one.) It's almost as if what people take full stack to mean is that the developer is exaggerating about their skill level on either the front or back end of the stack. Or maybe that they just haven't figured out which end of the stack their real talent lies.

I've always considered myself someone who prefers front end, so that is a bit of a challenging pattern to be stuck in. But lately I've been wondering, am I not being honest with myself?

Maybe I'm just describing myself wrong. I often describe myself as is a full stack developer with a preference for front end. While that sounds kind of like a line from a personal ad, it does describe what I like to work on. I prefer front end work, can do back end work, and especially enjoy back end work when it is in service of making front end work possible or better.

Drilling down on that last part brings us to the section where perhaps I'm not being honest with myself.

I can do back end work, and especially enjoy it when it is in service of making front end work possible or better.

Maybe my real thing is what lies in the middle. The overlapping part of the venn diagram between front end and back end.

There is so much in the middle.

Helping front and back end developers communicate. Developing and maintaining pattern libraries. Helping different developers or different systems integrate with pattern libraries. Everything that goes with decoupled architectures - the APIs supporting them, the fancy JavaScript frameworks that use those APIs. And of course, stepping out of the middle when the situation calls for it.

Maybe I've been a middle end developer all along.