Should you split the static content and your app-logic into two different entities?

Let me start by explaining the two scenarios. By splitting, it means that you run two web-instances that make up your website or application. For the user, it should feel like the same app. The reasonable part to split is the app-logic itself, and possible static content. The app-logic is where you might have users, models, and logic that makes your app solve whatever problem it might offer. This would also be the destination after signing in. The static-part would be your landing page, documentation, blog and whatever text the user needs to read before login in or signing in to the app. In responsibility terms, you might also think of these two as

1. The part that’s run by the marketing department (This might be you).

and

2. The part that’s run by the software engineers (This might be you as well).

I am sure you get the point.

I came across a discussion on this splitting topic on Twitter recently, and it was clear there were a lot of strong opinions. I understand why, as I’ve been struggling to decide upon this dilemma myself. I don’t think there is a correct answer on what to do, but at least we can look at the pros and cons. I think we can also conclude that this is as many other hard questions, a balancing act.

Pros (of divided architecture)

• Extremely lightweight front-end, most likely ultra-fast loading times.
• No downtime during app-upgrades.
• Lots of solutions available that will result in record ’time to market’, e.g. Ghost, GatsbyJS, Squarespace, Jekyll, Contentful, GoHugo ++.
• Solutions built for the right purpose, which is content creation.
• No need to commit and push for every small update.
• Saves you countless hours compared to coding a custom solution. (No, coding a fully fledged blog in e.g. Rails does not take 15 minutes as DHH did in that video.)
• Depending on the chosen technology, you might get some of the SoMe features for free. (Meta tags, sharing, snippets, image handling, etc.)
• Isolated main app logic.
• Maintainer gets forced to try out new technologies? (Not sure this is a pro, could be a waste of time)

Cons (of divided architecture)

If a developer tells it’s quick to code a custom blog or static platform, he/she is probably lying. Remember, a site is not complete unless it supports these features. Hence this warning: A static ’lightweight’ front end always takes more time to set up than initially planned.

You’ll need to duplicate way more functionality and code than you thought. Header, navbars, footer, domain settings and suddenly you’ve got two CSS sources that need to be maintained. CSS variables will not be enough to handle this.

Your selected landing page/blog framework (if not pre-hosted) might be ephemeral. Many of these new technologies are built by the JS community. These guys change the stack and introduce dependency issues more often than you change underwear. At least compared to the good old MVC frameworks like Rails, Grails or Django.

My current understanding is that www.myapp.com/blogg is more desirable in terms of SEO than blog.myapp.com.

There will be increased complexity if you’d like to share app data to the front page. E.g. if you would like to share how many users joined the platform, or how many cat photos that were uploaded during the last 24 hours. Of course, it can be supported if you split the apps, but you’ll have to expose an endpoint, use webhooks or in some way make that data available.

You’ll need 2 sets of admin user accounts. This issue can also be handled by using a third-party auth service, but most likely you’ll simply create standard user authentication with a DB on the app-side, so the problem will occur.

You’ll need 2 sets of tracking software, and there will be no natural flow of user behavior between the two platforms. Not sure how I would solve that when using a brilliant tool like Hot Jar.

As you see, at this time, the list of cons are longer than the list of pros. I’ll have to judge based on the situation. If you have any thoughts on this subject, please let me know on e.g. Twitter.