]> git.r.bdr.sh - rbdr/blog/blame - doc/specs/20200601-serving-different-versions.md
Add the spec for this feature
[rbdr/blog] / doc / specs / 20200601-serving-different-versions.md
CommitLineData
cce07b52
BB
1# Problem
2
3Feed reader users should be able to subscribe to the blog
4
5# Background
6
7As of this writing, the blog is served as HTML which is appropriate for
8web browsers but maybe not for other mechanisms like feed readers.
9
10Feed readers have different formats that they support:
11 * h-feed is a microformat built into the page
12 * rss and atom are XML based publishing formats
13 * JSON feed is a JSON based publishing format
14 * rss 3.0 is a text based pblishing format :P
15
16Currently the blog contains a single generator function that copies
17assets and generates HTML out of markdown files. This is good enough for
18the current setup, but if it were to generate more it would get messy
19real quick.
20
21Given the constraints listed below, some formats are not recommended:
22 * RSS 3.0 is not a good candidate at the moment as it would require
23 us to parse the markdown to extract the title.
24 * Atom would work, however, given the requirement for an id, title, and
25 date this would require more effort than a more lenient format.
26 * RSS 2.0 fits the constraints as we wouldn't need to specify anything
27 for the item.
28 * JSON Feed would work, however given the requirement for an id, thtis
29 would require more effort than a more lenient format.
30
31It is unclear whether the current constraints are good enough for feed
32readers. If this causes issues, it's likely we will have to include date,
33id or title as required in the other formats.
34
35After reviewing the functionality of existing readers, it has been found
36that an id and publication date would be needed for readers to behave
37correctly. This means that ATOM and JSON Feed would be equally valid
38as solutions than RSS 2.0
39
40The current generator function depends on knowing a source for the post
41being generated, and a target on where the assets will be placed.
42
43# Hypothesis
44
45Given we serve the blog in a feed reader friendly format, users will be able to subscribe.
46
47# Test of Hypothesis
48
49Given I add the blog to a feed reader service like Reeder or Feedly, I will be able to see the entries.
50Given I add a new entry to the blog, the entries will be updated.
51
52# Assumptions
53
54* We can generate a valid feed with just the entries themselves and the existing
55 blog data.
56 * We can: Validated by generating an example file.
57* Including just a list of items with the whole content is good enough for
58 feed readers.
59 * We can't: It seems like we'll require at least a guid. The old reader
60 behaves correctly with just the guid. It's unclear whether feedly
61 does since it has caching. Will leave grok running.
62* It isn't required to link back, and we can include the whole text.
63 * This is correct, however it might make sense to just link to the
64 blog itself.
65
66# Constraints
67
68* We won't be parsing the markdown to generate feed items.
69* We won't be adding any sort of frontmatter to the entries.
70* The blog will remain ephemeral, and we won't introduce permalinks.
71* We won't have configurable templating or options to add/remove
72 output types.
73
74# Solution Proposal
75
76(Note: This solution is incomplete. We need to add guid and pubDate
77generation, as this is required for the RSS to be usable)
78
79We will split the current generator function into generators, and create
80a new generator that will generate an RSS 2.0 file
81
82# Blackbox
83
84```
85 ┌─────────────────┐ ┌───────────────┐
86 │ │ │ │
87 ┌─────▶│ StaticGenerator │──────────▶│ Static Assets │
88 │ │ │ │ │
89 │ └─────────────────┘ └───────────────┘
90┌───────┐ │ ┌───────────────┐ ┌───────────┐
91│ │ │ │ │ │ │
92│ Blog │──────┼─────▶│ HTMLGenerator │────────────▶│ HTML File │
93│ │ │ │ │ │ │
94└───────┘ │ └───────────────┘ └───────────┘
95 │ ┌──────────────┐ ┌──────────┐
96 │ │ │ │ │
97 └─────▶│ RSSGenerator │─────────────▶│ RSS File │
98 │ │ │ │
99 └──────────────┘ └──────────┘
100```
101
102# Theory of Operation
103
104When the generate function of the blog is triggered, it will iterate over
105a list of generator functions and call them with the source and target
106directories, and an array containing the parsed markdown from the post.
107Each generator function will do its work, throwing an exception if they
108encounter an error.
109
110When the static generator is called, it will remove the current assets
111directory in the target directory, and recursively copy the assets from
112the source directory.
113
114When the HTML generator is called, it will parse an `html` template, using
115the posts as the context, and will place the resulting file in the target
116directory.
117
118When the RSS generator is called, it will parse an `rss` template, using
119the posts as the context, and will place the resulting file in the target
120directory.
121
122# Technical Specification
123
124## The Generator Interface
125
126Every generator must implement this interface in order to work with
127Blog.
128
129* Generators MUST be a function
130* Generators SHOULD read the source, destination, and posts parameters to
131 write files.
132* Generators MUST NOT write anything into the source directory
133* Generators MUST return a promise
134* Generators SHOULD NOT resolve the promise with any information, as it will
135 be discarded
136* Generators MUST throw exceptions if they encounter an unrecoverable error
137
138```
139IGenerator(source<String>, destination<String>, posts<Array<String>>) => Promise
140```
141
142## New Generators
143
144### Static Generator
145
146This generator will have the logic to move static assets around. It will
147re-use the current asset logic in the `#_generate` method in Blog.
148
149```
150StaticGenerator <IGenerator>
151```
152
153### HTML Generator
154
155This generator will have the logic to generate an HTML file. It will
156re-use the current HTML logic in the `#_generate` method in Blog.
157
158```
159HTMLGenerator <IGenerator>
160```
161
162### RSS Generator
163
164This generator will have the logic to generate an RSS file. It will
165re-use the current HTML logic in the `#_generate` method in Blog,
166however, instead of using the `index.html` template it will use a
167`feed.xml` template that generates a valid RSS 2.0 feed document.
168
169```
170RSSGenerator <IGenerator>
171```
172
173## Modifications to existing parts of the code
174
175The `#_generate` function will be modified so it will now parse the
176post markdown, and then iterate over the generators, calling them
177so they create the appropriatet files.
178
179## Important Metrics
180
181Given we're only processing 3 blog posts, and this is a compile time
182activity and not runtime, there are no recommended metrics in terms
183of file throughput performance or runtime performance.
184
185This should change if this would ever handle a higher volume, or would
186be expected to run this process runtime.
187
188## Furhter Improvements
189
190It's recommended to eventually put more effort in assigning a unique ID
191to each post so we can use more feed formats.
192
193For more compatibility and future proofing, the same solution for
194RSS could be used to generate other feed formats, just adding
195a new generator
196
197This same solution could be extended to serve the blog in different formats
198(eg. a .txt that is easy to read in terminals)