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,
profileservice 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
chatpages in real-time, since this feed had to contain specific HTML templates and behaviors. Long-polling buffers had to be moved tochat, rewritten and enhanced with events likeuser-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.
Published: June 01, 2014.
Next post in HappyPancake story: Almost Demo
🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out