Minimal Viable Product

This week we were pushing forward major features missing from Minimum Viable Product for the demo in June. The progress was quite good, even ahead of the schedule. I attribute that to the design we came up with for the project.

Pieter focused on introducing infinite scrolling to our feeds: alerts, news and diary. These feeds are provided by the separate golang packages of the same names. They don't own any data, but rather project incoming events into a local storage (mySQL tables used as key-value storage with some indexing) and expose an HTTP handler to render all the HTML for browsing these feeds.

When we ran out of the things to do for the MVP, Pieter switched to implementing draft, register and review packages. Previously we assigned future responsibilities to them and established their contracts in form of events that cross boundary of these packages. These events were mocked by populateDB script and consumed by the other packages. This allowed to refine the design multiple times even before we started coding in this version.

Tomas continued acting as Santa this week, working hard on the new HTML templates for the project, while also refining some of the old ones. These templates feature responsive UI, making them ideal for devices with small screen sizes (half of our visitors use them). Later on we could adjust HTML to work nicely for the desktop apps as well.

It felt really awesome for me to skin diary, alerts and news with these new templates along with my favorite chat package. This process actually granted additional design insights:

  • we can't generate HTML of the feed items in advance, since we need to embed things like on-line status, current profile photo;
  • while rendering final HTML for the feeds, profile service is queried for enrichment information dozens of times per render - I had to implement a simple in-memory cache with cluster-wide eviction of invalid items (driven by the events);
  • we no longer could use application-wide long polling feed for updating chat pages in real-time, since this feed had to contain specific HTML templates and behaviors. Long-polling buffers had to be moved to chat, rewritten and enhanced with events like user-read-message.

There are still a few missing bits and pieces related to the UI of profile views and chat conversations, but these are going to be easy to implement once we have the HTML templates to fill them in.

For the upcoming week I will probably be busy with implementing nav package (it serves navbar html which is reactively highlighted whenever there is some new content for the user to consume). Ideally, we'll also tackle rendering of the ads into the feeds, since this is the most valuable feature for the business.

At some point next week we might start enhancing our solution with package-level event-driven tests expressed in the form of specifications. We currently have such tests implicitly (in the form of event streams generated by populateDB script), however there is value it making them explicit.

- by .