I think the point is that ockam site requires a flexible layer to manage its data, which is focused mostly on .md documentation files. So Storing, updating and managing these files through a database could be quite hard and annoying, since all of them are stored across many different github repos. Moreover, all these files, have to be shown in a user-friendly way. This data from .md files, have to be converted to HTML at some point as well.
So what we have done is we keep all data on their place ( depended github repos ), grab them before build time, and generate static content based on it. Moreover, we have some mechanism to target particular branches/commits on depended repos, and control when we want to trigger our pipelines.
So, replaying directly to your question - no, building a static site not require a database. JAMStack architecture is helping us to provide and manage our specific data sources.
Well in the JAMstack a database (or any other datasource) can be used and required during the build step, which will generate the static html using that datasource (see getInitialProps in nextJS). Once the static html is generated and output, the datasource is not needed anymore.
This is pretty much in contrast to other stacks, where more often you will not need a database at compile time, but only at runtime. Of course, the statically generated HTML will not update unless rebuild and deployed (except if you use a hybrid static/dynamic approach using Javascript or the completely server-side rendered mode, both of which are also supported by nextjs).
Yea, it's related to https://mdxjs.com. All .md files can contain valid jsx code. This `mdxComponents` folder name, refers to components that could both be - used directly in markdown files or used to generate html from markdowns.
Sorry I should add - Works fine for me in Safari and Chromium, in Firefox the header and footer render fine, but the content fails to display. There are no console errors.
PS. The reason why we're moving away from Postman is due to some tiny issue[1] that has caused lots of "you need to click here to see everthing" conversations.
I'm not quite sure what you mean by "Postman documentation". Is this Postman's documentation or documentation for other APIs (not sure if Postman has an OpenAPI spec?).
I found slate, and it's super cool, but I haven't used it myself. There might be some pipelining involved, from my understanding of projects like https://github.com/Mermade/widdershins where you convert OpenAPI specs to markdown?
I think the good folks over at getstream.io used slate as a base for their docs CMS and loved it enough to write about it, and I'd love to read more about slate in production. Looking forward to when you finish your migration and if you write about it!
I just git cloned, installed, and ran dev, and yeah it does have everything! I thought it was just the landing page! This is really cool, thank you very much for open sourcing this!
Edit: think I misunderstood :) I have used Vuepress before, it is geared towards building documentation. I believe Vue’s own docs use it. I had a good experience with it, would recommend!
Do you know of any other Vuepress documentation themes, or where I could find them? I like Hugo because they have a curated open-source showcase of different themes @ themes.gohugo.io, so you don't have to search around the web to find stuff.
