This is another in a series that’s based off of my presentation at the Tridion Developer Summer this year on Tridion and Node.js. My two previous posts covered why Node.js mattered with Tridion, and how Node would work as a content API. What I want to talk about, briefly today, is what you can do terribly, terribly, terribly wrong if you’re mixing Node in with Tridion implementations.
As I’ve said before, NPM is the de-facto Nuget for front-end development. Front-end developers will use utilities like Gulp, Grunt, and Webpack for taking their assets and “compiling” them into CSS, JavaScript, and image sprites. There’s nothing wrong with this, and in fact it’s a pretty good idea.
But, the JavaScript ecoystem that comes with NPM can bring lots of bad news if an architect isn’t keeping a close eye on the front-end team.
Don’t let Node provide throwaway templating
Front-end developers can sometimes get carried away with building their static site. I’ve seen cases where the front-end build ends up being a complete web application with header includes, footer includes, partials, and even models. Front-end developers take their JavaScript ecosystem and use all of it instead of what they needed to do their jobs.
Don’t let Node-based projects push modifications into Tridion
I’ve seen implementations that used Gatsby. If you haven’t heard, Gatsby is a static site generator.
Built with React.
So the latest thing is to build static sites with React.
Gatsby is particularly problematic as it…well…builds a site. So front-end developers are building a website with React, and deploying a whole website. So there’s an obvious problem here:
Every time you publish a page, you must regenerate the entire site.
That’s Gatsby’s default way of doing things.
In this particular implementation, this became obviously problematic because Tridion isn’t the kind of CMS where clients are totally cool with the entire site getting rebuilt every time you publish a page. This, in fact, seems like a terrible idea because you may have dozens, or even hundreds of content authors publishing dozens or hundreds of pages every day.
So in this particular implementation, we ended up building a deployer extension to notify our Gatsby deployer that a single section of the site had a republish, so that just that section would get republished. So technical debt was created because of a poorly chosen solution
This is a flawed model driven from a node.js-based mindset and not a CMS-centric one.
TL;DR
Watch for front-end developers pushing the new and shiny and making the case that it’s only affecting the front-end. Templating solutions and whole-site generators can have a serious impact on your Tridion implementation.