Hello! I am Alex Moon – I’m currently a Software Engineer @ Gatsby working to build better data integrations. My career has spanned a help desk, systems administration, and software development. When I am not working I can usually be found hiking, contributing to Open Source, or wishing I was sailing.
Serverless Web Apps with Gatsby + Dgraph + TinaCMS
More and more folks are looking to build highly dynamic web apps that deploy via static assets to a CDN. Gatsby has been a leader in this space and has a great story around sourcing data from a wide variety of CMSes. That same story hasn’t been true when looking to source data from a database. Existing solutions have generally been highly custom and complex or all together sub-par.
The good news is this is changing, Gatsby has recently released to beta its GraphQL source toolkit that uses schema queries to integrate any GraphQL source quickly and easily into Gatsby’s data layer. This is already driving new CMS integrations such as CraftCMS and GraphCMS. With Dgraph now shipping full GraphQL compatibility we have the ability to much more simply integrate our Gatsby frontend with a world-class database.
Join us to learn more about building highly scalable web apps deployed at the edge using Gatsby, Dgraph, and TinaCMS.
In your demo source-code, plugins/gatsby-plugin-dgraph/gatsby-node.js had a complicated (IMO) code. You said it was mostly boilerplate in your talk, but I found it confusing as someone new to GatsbyJS.
Will we able to use Dgraph as a data source without these boilerplates when the toolkit is launched? Or do I need to write them for every GraphQL source I’m gonna use?
Hey, What I meant to say was my example source plugin was copied from an example of the CraftCMS implementation with little editting (meaning the toolkit does most of the work). That’s not terribly different from boiler plate…but you are correct, it’s daunting. There’s a lot going on in the code I showed and under the hood. The good news is there is the boiler plate used to be 1000s of lines of code and now it’s ~100 lines(depending on some things) and some config.
Right now the toolkit itself is in beta, what you saw shouldn’t change too much. Once that is released the next project is updating or replacing gatsby-source-graphql. The hope is to create a source plugin that doesn’t use schema stitching but acts fsimilar to gatsby-source-graphql (just provide the graphql endpoint). This is mostly theoretical at this point and I know from talking with Vlad and team there are some more problems to be solved. But, the Toolkit is a huge step forward in helping devs build custom source plugins for integrating with GraphQL APIs and makes that process significantly faster and easier.
Hopefully this answers your questions, let me know if you have more!
I have a question around Gatsby, maybe its a bit off from your talk.
Because of Gatsby’s server side rendering there is no access to DOM object so many open source components tend to break mostly because its trying to access the window object, this gets pretty nasty sometimes.
How do we tackle this effectively, I usually block the component to render until the components mounts at-least once.
Not on every deploy. On a first build with no cache yes, it’ll have to pull everything you tell it to (this is one reason I only fetched Films in the demo). It’s also one reason I wanted to demo client side routes in Gatsby. It’s often assumed that Gatsby is just a “Static Site Generator”…which isn’t true. It ships full React apps that are capable of full dynamic content just like Next or CRA.
If a quality source plugin will use what’s in its cache as a start then only fetch updated data on follow up builds. This wasn’t completely built out in my demo but will be possible with Slash GraphQL in the future when it supports more logic and code with JavaScript. I was able to mimic incremental builds which only had to re-fetch the single film that we edited. This was possible because we passed the id of the edited node into the GraphQL Toolkit and it knew how to re-fetch just that updated node.
Gatsby has a doc that covers some of the technical aspects of this problem and how to work around it.
But at the end of this day this isn’t really a Gatsby issue IMO. NextJS or any SSR system is going to struggle with this as well. Part of the confusion with Gatsby and other JS frameworks is both the client side code and server side code are in JavaScript. This makes the line between them very blurry and can be quite confusing. The other aspect is React. Ultimately, React (and any VDOM based libraries) expect to control the DOM. Many window based tools are build expecting to be allowed to work with the DOM directly as they please. But in a React world that can cause some strange front-end bugs or things to just not work at all. This issue comes up when we fight (knowingly or not) against doing things the “React” way.
In my work I’ve found I just have to replace libraries and do it the “React” way. This can mean 1 of 4 things:
Many libraries have a React implementation where someone has done the hard-work of making the library into a react component. It may be done by the original author or a third party, either way some googling or npm search might help you find these. If this doesn’t exist…
You need to do a lot of work to make the library work in the React ecosystem. This can be difficult if not impossible which means…
Just get a new library. This can be frustrating if you already have things built and working on a site you are converting, or maybe you are familiar with a library…but React has been around for a decade now…there’s probably a component…if not
At the end of the day you may just need to right a custom component.
Solving these issues isn’t always straight forward…and there are catches in how you make window based libraries work. The good news is using window should be a problem that slowly goes away as people create and convert libraries to use JS modules.
