We were once tasked to build a website for a small publishing house. The site would have pages of books and of authors. Each book page would link to the page(s) of the book's author(s). Each author's page would have thumbnail(s) of this author's book(s). There was also to be an index page, which would contain various books, with names of respective authors, and links to each book's and author's page. It was almost like describing a simple relational database.
Except we wanted the site to be static, and the data about books and authors to be stored in yaml files on github. So book page, author page and index page needed to learn about each other at build time by reading the frontmatter of the yaml files.
With Gatsby's graphql data layer doing so would be trivial, and the whole developer experience would have been highly satisfying. But we weren't allowed to use Gatsby, because the size of the main javascript file that Gatsby (coupled with Netlify CMS) would output was approximately 100 kB, and our tech lead had a strong aversion to large javascript files and to what he considered an overengineered framework. So we had to use Hugo instead. Which we did. Hugo, bless it, also allowed building relationships between data files at build time; but the way it did so was so unintuitive and its Go-based templating language was so cumbersome that I hated almost every moment of working with Hugo. Besides, barebones Hugo did not have a flexible enough static assets pipeline, so we had to write our own (gulp) scripts for bundling static assets. With Gatsby, that would have come out of the box.
Gatsby may not be the technology for building lightest-weight sites (no matter how much the Gatsby team emphasises their commitment to performance), but the developer experience when working with Gatsby is unsurpassable.
I've had a lot of good experiences with Jekyll, and I'm fairly sure that the problem you've described would have worked nicely with it. Extending it is also really straightforward, you just put a few lines of Ruby in a file in the right place.
I've moved my site from Jekyll to Gatsby, and while there are some nice things, it's not been a clear win. My site is very significantly slower for first load, but slightly faster for all subsequent loads. The build is far less stable with Gatsby, there are ~5 dependency updates per day, things like Sass don't "just work" anymore, but on the other hand, there are a few more packages that do useful things that I didn't get in the Jekyll community.
We were once tasked to build a website for a small publishing house. The site would have pages of books and of authors. Each book page would link to the page(s) of the book's author(s). Each author's page would have thumbnail(s) of this author's book(s). There was also to be an index page, which would contain various books, with names of respective authors, and links to each book's and author's page. It was almost like describing a simple relational database.
Except we wanted the site to be static, and the data about books and authors to be stored in yaml files on github. So book page, author page and index page needed to learn about each other at build time by reading the frontmatter of the yaml files.
With Gatsby's graphql data layer doing so would be trivial, and the whole developer experience would have been highly satisfying. But we weren't allowed to use Gatsby, because the size of the main javascript file that Gatsby (coupled with Netlify CMS) would output was approximately 100 kB, and our tech lead had a strong aversion to large javascript files and to what he considered an overengineered framework. So we had to use Hugo instead. Which we did. Hugo, bless it, also allowed building relationships between data files at build time; but the way it did so was so unintuitive and its Go-based templating language was so cumbersome that I hated almost every moment of working with Hugo. Besides, barebones Hugo did not have a flexible enough static assets pipeline, so we had to write our own (gulp) scripts for bundling static assets. With Gatsby, that would have come out of the box.
Gatsby may not be the technology for building lightest-weight sites (no matter how much the Gatsby team emphasises their commitment to performance), but the developer experience when working with Gatsby is unsurpassable.