docs: Develop on TigerBeetle section

[emschwartz]

This PR turns what was previously called the Design section into a Building on TigerBeetle section. The recipes are moved into that section to reduce the number of top-level items in the sidebar.

• docs: rename design section to Building on TigerBeetle
• docs: flesh out Building on TigerBeetle page
• docs: add ledgers section to top of data modeling page
• docs: fix broken links and use consistent markdown formatting
• docs: rename intro.md to README.md
• docs: move recipes into Building on TigerBeetle section
• docs: link from index page to Building on TigerBeetle readme
• docs: include get_ operations in readme index

[emschwartz]

One thing I'm not sure about is whether the contents of building-on-tigerbeetle/README.md should be in the main docs page README.md

[emschwartz]

Anyone understand what that CI error means?

[sentientwaffle]

What about "Integrating with TigerBeetle" and /integration/... as the path? Or "Interfacing with TigerBeetle"?
I think "interfacing"/"integration" are just as -- or maybe more -- evocative as "building on".

...And also I like one-word path segments 😛

[emschwartz]

I hear you on one-word path segments...

I don't love 'integrating with' because that makes me think more of an API service like Spotify, where they are the main thing and you're integrating with them.

TigerBeetle is more inside or underneath your application.

[sentientwaffle]

What about "Concepts"? Or "Semantics"? Though maybe those are too imprecise... 🤔

What do you think of "interfacing", just for the path name, if not also the sidebar label?

(It looks like DuckDB calls their equivalent section "Connect" -- in the general sense of the word it is a good choice, but it has the other meaning of connecting via the network which is too narrow. I think "Interfacing" would be better.)

Another idea: "Applications", which has the (somewhat coinciding) double meaning of "user applications," and "how to apply tigerbeetle to your problem".

[emschwartz]

If we're looking for one-word options, I'd lean more towards something like build and we could call the section "Build on TigerBeetle" (which might match the tense of "Deploy" better)

The URL would be docs.tigerbeetle.com/build/ which seems pretty good

[sentientwaffle]

🤔 Could that be confused with compiling TB, or downloading builds?

[emschwartz]

Yeah I thought of that. I think there's some slight possibility for confusion, but only slight. For compiling TB, I'd expect to find those instructions somewhere on the readme. And for downloading things, I'd expect that to be under "download".

Some other examples:

• Yugabyte uses Develop https://docs.yugabyte.com/preview/develop/
• Not exactly comparable but Supabase has Guides https://supabase.com/docs/guides/database/overview
• Redis has a bunch of sections but maybe the most comparable is their Manual https://redis.io/docs/manual/
• MongoDB also uses Manual (though that kind of includes all the docs) https://www.mongodb.com/docs/manual/data-modeling/

[sentientwaffle]

Develop is nice, and contrasts nicely with deploy. But if you still like "Build on TigerBeetle" the best, then let's just change the url path to "build" and go with that.

[emschwartz]

Develop works for me!

[sentientwaffle]

Mixed feelings on moving recipes under design. It does feel like the right place for it, but the docusaurus collapsed-by-default accordion navigation punishes nesting with extra clicks and animations to find what you're looking for. Probably worth it anyway, though.

[emschwartz]

Yeah, I hear you on that.

My main motivation is that I want to clean up the top level sidebar so that there are fewer things and it's more obvious where you need to go. Obviously having more levels of navigation has drawbacks, but we also don't want it to seem like there's an overwhelming amount of information you need to take in right away.

Looks like it is possible to make it start out not collapsed https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-content-docs#sidebarCollapsed