Read Time: 2 Minutes

Cinch Stack

Stack selection is rarely given enough thought. This is especially true among established teams. While a team newly formed has yet to develop a strong working relationship and shared development habits, an established team often falls back to the comfortably known.

My first instinct with Cinch was to go Server Side Rendered (SSR) over Single Page App (SPA). It’s comfortable, fits the product, and accessible.

Cinch will primary serve content created by authors. This content will most often be consumed in one-off visitations (think consumption of a single post from an author on the platform). Thus SSR, with it’s faster Time to First Paint (TFP), seems to be the obvious choice.

The Cinch roadmap also includes a mobile app to provide native performance and improved on-device editing. The means we’ll eventually need an API. While building an API onto Cinch wont’ be huge undertaking, it would be faster on the dev side, and more maintainable long run to not have two methods of data access. This provides the first crack in the SSR argument.

The crack begins to widen when considering our primary target audience is writers who want to build a regular following. Their audiences will be able to subscribe to support their work and subscribers means multiple visitations. While subscriber traffic will represent only a fraction of total platform traffic, those subscribers absolutely deserve a better experience – they are, after all supporting writers directly.

Finally, after much discussion we decided against including the ability for users to create entire themes from scratch. This just isn’t necessary, and the ability to add custom CSS will more than suffice. Without the need for custom templates, SSR just doesn’t fit. It’s faster up front in dev time, longer over the course of a year. It’s faster up front in visitation, but slower for repeat visitors.

So for Cinch we’re going with a MERN stack, that is Mongo, Express, React, on Node. We’ll be running Mongo 3.6 with Mongoose in anticipation of using Amazon’s DocumentDB. On Node we’ll be on v12 LTS.

On deployment we’ll be on AWS. This choice is unusual as we generally use DigitalOcean. Here we opted for AWS simply because we’re already going to be on DocumentDB from Amazon. During dev though, we’ll be using Digital Ocean.

We’re super excited about Cinch. I really hope that it’ll bring not only a quick and easy way for writers to start writing, but help writers grow a sustainable audience who truly appreciates their work.

Leave a Reply

Your email address will not be published. Required fields are marked *