Sure, as you will have to do with any add-on product, you'll need to write a plone.restapi extension for support such feature and expose via REST, right?
Then, also write a custom React component to support that kind of data, plug it into Gatsby, then show it like you want it. Not really a big deal if you want to have all the niceties of a Gatsby site.
yes, almost as easy as a 'Big Green Button'.
Why are we preferring Docker images here? I'm not quite familiar with them fully yet, so any suggestions on what I should read/checkout would greatly help. How is this different from a hosted instance of Plone as what we have in: https://plonedemo.kitconcept.com/en ?
Docker allows you to run your own Plone locally with the content you require for your development. Hosted plonedemo is cleared daily.
So this is used as an alternative to buildout for running Plone locally?
Yes – Docker is an easy way to deploy a running instance of software, and it's especially easier to deploy a set of running processes that need to be configured to work together (for simple situations; some people think it's ok to use Docker to deploy to production, but that will depend)
Buildout can be finicky 
Hi, I have submitted an initial draft at Plone GSoC, I am using the rest API as well. My GSoC proposal also involves making modular Plone functions that interact with the rest API. I think these functions can be reused while using GatsbyJS. It looks very interesting, but unfortunately, I currently have my Mid Sem Examination. If I have time, I will submit another proposal regarding this. If not, I can still contribute anyway!
I think the best thing to do is, to make a library of reusable and modular functions. Once that is done, you can always put in the time to develop a Gatsby application.
Could you please elaborate what you mean by "modular functions"?
Basically, create a set of functions in NodeJS to use the Plone rest API. These functions can always be reused.
By modular, I meant that these functions should be built only to serve the required purpose.
These functions should be built in such way that they are easily composable. ie. the functions should return all the required information such that if a callback function is passed to a function, it should be able to proceed.
for eg. Consider this weird example.
Say there is a function F1() which returns a few posts and once you get the result in F1() you want to save next batch (if it exists) in an internal cache. (F1() is asynchronous)
One way to do this is to use await, check if next batch exists and continue with the workflow.
Another way is to pass a callback function, which should execute within F1(), once it is done.
I prefer the latter. This callback function should have enough information to proceed.
(This is a pretty dumb example, I'll notify you once I come up with a better one.)
This callback function could be one of the functions we built, so this is what I meant by composable, The functions should be built in such a way that you can chain callback functions.
The advantage with the latler design is that, the context of the previus executions is available to the currently executing function, this could be used in a productive way.
I might have used the wrong word there, Am sorry for any misunderstanding.
Heads up. Most of the “hard problems” (not really that hard thanks to great restapi) related to Plone source plugin for GatsbyJS (fast static sites from Plone content) have been solved in our GSOC project.
The remaining work for minimal plugin is to polish, document and creation of easy to use starter project. Luckily there are still a few weeks left on GSOC.
Please, contribute your questions, concerns and wish list as issue comments at https://github.com/collective/gatsby-source-plone/issues/137