storage

This article is a stub. You can help the IndieWeb wiki by expanding it.

storage in the context of the indieweb usually refers to how you are storing your data, specifically in what kind of storage format(s).

Where you store your data is typically a question of web hosting.

Flat files

Main article: file-storage

Many indieweb projects are storing their data in flat files on the file system for reasons of simplicity and robustness.

See also the databases-antipattern for reasons why flat files for storage are growing in popularity compared to databases.

These flat files typically are either:

Markdown with custom (per project) extensions for various metadata
HTML+microformats (e.g. hAtom and/or h-entry)

And contain either:

one post per flat file
time sharded: a set of posts per fixed time period per flat file

Some IndieWeb Community members using flat files for storage with their projects (see: file-storage for more)

HTML plus microformats

Tantek on tantek.com uses Falcon (time sharded per bim)
Kevin Marks on kevinmarks.com stores posts formatted as HTML in GitHub and deploys statically to Heroku.
...

Markdown plus extensions

Aaron Parecki on aaronparecki.com uses p3k (one file per post, YAML extensions for meta info)
Bear on bear.im uses Hakkan with one file per post (time sharded by year+day-of-year), key:value header for metadata and a json blob for connected resources
User:Bret.io Yaml headers (aka front-matter) with github flavored markdown mixed with liquid template include tags for post attachment metadata. Yuuuuuck! This is what jekyll sets you up with. It has its ups and downs, but its a mix of 3 weird languages which really bothers me.
...

Databases

In addition to popular projects like WordPress, a few indieweb projects store their data in databases, typically with custom one-off database schemas that requires special programming to translate into other formats.

See individual database pages for usage:

Common Pitfalls

Designing storage before UI/UX

Storage first is usually a fruitless endeavor because there's either too many possibilities so the storage needs seem overwhelming, or you make arbitrary storage simplifications which end up premature constraining your design / display options.

This can be seen here in a conversation between Tantek Çelik and Eddie Hinkle while thinking about Health information being stored on Eddie Hinkle’s personal site.