4 ms·

There are two primary advantages for the ockam.io site to use JAMStack: No need for a database or complex backends Building and hosting are decoupled I don't

by ithrow 6y ago

There are two primary advantages for the ockam.io site to use JAMStack: No need for a database or complex backends Building and hosting are decoupled I don't get it, since when building a static site requires a database? Are they referring to eliminating some kind of CMS?

mattgreg 6y ago
Here is all the source code and build systems for the Ockam.io site: https://github.com/ockam-network/website https://github.com/ockam-network/website
littlecranky67 6y ago
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).
miedziak 6y ago
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.
- mattgreg 6y ago
  ...exactly!

by ithrow 6y ago

mattgreg 6y ago

Here is all the source code and build systems for the Ockam.io site: https://github.com/ockam-network/website https://github.com/ockam-network/website

littlecranky67 6y ago

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).

miedziak 6y ago

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.

mattgreg 6y ago
...exactly!