Sites adds too much complexity

[nicl]

I think raising a PR to show this is probably more useful but initially I wanted to question whether we should support multiple sites. At the moment I'd just like to document my thoughts and share them.

As far as I can tell the pros of our sites approach are:

• helps others bootstrap quicker due to easy set up (i.e. all the webpack, linting, etc. is built-in)
• helps promote common standards for the same reason as above
• single repo makes sharing code easier (no need for publishing packages)

The cons are pretty big though:

• distracts from our mvp/core aim of articles
• adds a fair bit of complexity/overhead
• can confuse the separation of concerns and introduces significant coupling

These are all pretty major in my opinion.

I really think in terms of shared code, Guui is where we will add value. The sites mechanism adds stuff that is more subjective (linting, etc.), likely to change, and may not be appropriate for all projects. I don't think a future where all/several of our node apps are tightly coupled in terms of code is a good thing in a medium-sized org with multiple teams and diverse aims.

I would prefer separate projects which only share code through published packages/dependencies - in particular Guui. So the approach would be:

• Guui - purely for shared components (pasteup should just be subsumed into this unless I have missed some of its purpose, which is quite possible)
• Frontend - purely for our site
• other sites, live elsewhere

Not being able to use Guui directly (except as npm module) may seem painful but I think a good workflow would be to develop components in dotcom (or in other teams' projects) first, and then when confirmed useful and in more than one place, genericise and place in guui.

[nicl]

Just to add to this, current directory structure is:

/flow-typed # Flow type definitions
/lib        # Deployment and build related code
/packages   # Shared code between sites
/sites      # Site-specific code
/webpack    # Webpack code

Instead I think we should have:

/frontend
/guui

Where the two are completely independent. (We could even have separate repos but I don't really care on that point so much.)

[SiAdcock]

I appreciate the thinking behind this @nicl, so thanks for that. There's a lot of different ideas here which I will attempt to unpack, apologies if I miss anything important.

I do agree that supporting multiple sites is complex. I also agree that it is not the main aim of this project, for now.

I wanted to question whether we should support multiple sites

We had a fair amount of discussion about this early in the project, and we came up with the same "Pros" as you. If we could support sites that conform to the frontend template, it would enable teams to quickly create a new site using Node, Express, Guui, Webpack, ESLint, Flow types, etc without having to put together all the repetitive project initialisation boilerplate.

I really think in terms of shared code, Guui is where we will add value

Bang on, I totally agree. Guui is what should be receiving most, if not all, our focus.

The sites mechanism adds stuff that is more subjective (linting, etc.), likely to change, and may not be appropriate for all projects. I don't think a future where all/several of our node apps are tightly coupled in terms of code is a good thing in a medium-sized org with multiple teams and diverse aims.

I acknowledge that the frontend stack will not provide an appropriate template for all applications and teams. In these cases, installing Guui as a dependency makes sense. However, for those teams that it is appropriate, the option is here.

It remains to be seen whether this is a realistic proposition. If nobody bites after a given amount of time, I think this is the point when we should consider removing sites and not before. As you say, Guui is the main value proposition and should be receiving our focus. Is the sites concept hindering development on Guui?

Guui - purely for shared components

One small point, just in case it is unclear: there should not be any code sharing between sites. Sites share code style and bundling config and a rendering mechanism. They may import shared components from Guui. But we don't want a <Header/> component that lives in frontend, say, being imported into the membership site, or whatever.

(pasteup should just be subsumed into this unless I have missed some of its purpose, which is quite possible)

I'm not sure if Pasteup should be subsumed into Guui. It might be a question of how modular is too modular, but it seems that there is inherent value in Pasteup that is not exclusive to Guui; a bright line can be drawn between them. Guui is a framework with a shared component library. Pasteup is a package of design tokens for consumption in a generic CSSinJS application. You may be right and this line may turn out to be imaginary, but again I don't think we have the data for this decision, and this ought not be the focus of our time right now.

Not being able to use Guui directly (except as npm module) may seem painful but I think a good workflow would be to develop components in dotcom (or in other teams' projects) first, and then when confirmed useful and in more than one place, genericise and place in guui.

We ought to allow developers to build Guui components in isolation, outside of the context of a site. Based on feedback from the Journalism team, one of the best things about dotcom-rendering is the fast feedback cycle when building components. Forcing devs to develop components in their own application and then migrating the resulting components into Guui seems like a step backwards in terms of developer experience.

If you have any thoughts on this, please come and chat to me, I think it would be more productive than a GitHub issue back and forth 😉 Maybe some of this should be logged in among our architectural decisions documentation.

[nicl]

Thanks Simon!

After discussion, also with @GHaberis , we're going to postpone decision-making on sites for now, but @SiAdcock is going to create a Trello card to force a decision on this in the future.