Fanray 1.0.0 released

From 8/14/2017 to 11/30/2017, it took me three and half months to go from the initial commit to the v1 release today. I’m right on track to achieve what I started out to do, learning in the open, building something I can use everyday, and sharing all aspects of this process with the community.

It’s an MVP

V1 is not much, but it’s useful enough to bring you these words on this page. It was intended to be an MVP.

A Minimum Viable Product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.[1][2] Some experts suggest that in business to business transactions an MVP also means saleable: "it’s not an MVP until you sell it. Viable means you can sell it".

Here I myself is the early customer and for it to be saleable to myself it has to have the basic features I think a blog should have, posts, categories, tags, comments, SEO considerations, RSS feeds etc., and on top of these it must be performant and stable.

The blog has been around since the 90s, its features vary greatly from a static page with text to complex systems like WordPress. Ambition could easily kick in and scope of things could go out of hand and let me start something that I never finish on time. To avoid this I’ve decided early on to support MetaWeblog API, which dictates a set of features a blog needs to implement so that desktop clients, like the Open Live Writer, can talk to it. This strategy has proven to be helpful, it really limited my scope on what needs to build without ambiguity. This also allows me to have a rich client to at least start posting without a full blown admin console which takes more time to develop and is coming in 1.1.

Architecture

I’ve designed the app using n-tier architecture, a very typical presentation to business logic to data access setup. Below diagram also shows some of the clients the blog could potentially support and how they communicate.  For example, a desktop client talks to Fanray through MetaWeblog API which is built on XML-RPC, so the content type of communication is XML, whereas the browser talks to MVC controllers that return them HTML, CSS and JavaScript.

  • desktop (MetaWeblog API – XML)
  • browser (MVC – HTML)
  • mobile (Web API – JSON)
Fanray blog architecture
Fanray blog architecture

 

On top of the basic architecture the practice of doing Skinny Controllers, Fat Models and Dumb Views is a very effective strategy to achieve Separation of Concerns. The Web Tier handles traffic and presentational logic only.  The Business Logic Layer does most of the heavy lifting on validation, calculation, caching and much more. When it comes to Data Access Layer, it does just data accessing operations.  Of course, there are grey areas, for example validation can happen at any tier, this deserves a post of its own.  But the basic idea is that each tier (or layer I kind use them interchangeably) has a very specific concern. These different clients talk to different kind of endpoints, browser calls on MVC controllers and Open Live Writer calls on MetaWeblog API endpoints, both ask for the same business logic to carry out, when they get the results they return them to the clients in different formats.

Onward

I’m making steady improvements to this app and hopefully others who happen to come across this project could find it useful as well. Any feedback is welcoming and if you would like to participate, please check out the GitHub repo on how to contribute. Thank you.