Gatsby allows developers to create react apps with full functionality, not just static websites. The uniform design language for websites built with Gatsby allows the team to work in a codebase with a single design methodology, while not having to think much about the different sources of data, performance metrics and scalability. The structure for the code is predetermined, and only the website itself has to be built.
The Gatsby framework is used to build a variety of applications, from simple single page apps and blogs to fully fledged webshops and complex applications. The project offers the developer a great source of information about building with it in the form of documentation, examples on how to use a feature, starter kits (a functioning starting point which is ready to expand upon) and blog posts doing deep-dives into a topic. If some feature is not available, you’re free to implement a plugin which slots into the Gatsby build pipeline and adapt Gatsby to your personal needs.
Software can be viewed from many angles. Ask a developer and a user what they think about some software product and you’ll probably get not only contradictory answers, but even uncomparable answers. This is because they look at the software from such a different point of view.
Welcome to the third part of our four-part series on Gatsby. The previous essays can be found here: first, second. For a complete understanding we highly recommend reading those first. In this part we will evaluate technical debt and architectural decisions made. To be able to cover this all we will first take a look at the quality assurance systems Gatsby has in place. We’ll explain what a contributor needs to do to have their pull request successfully merged and what Gatsby does to protect their code quality. When we have in place how pull requests are merged, we will analyze what pull requests have been merged recently, what changes are coming up, and how these changes impact the technical debt and maintainability of Gatsby. This should give a clear understanding of what is going on inside Gatsby. After getting this understanding, we get a bit more formal and dive into absolute quality assessment, analysing results from SIG and BetterCodeHub. In conclusion we will take all evaluated aspects together. If you want to learn more about these topics, this essay is just for you!
This is our fourth and final post on Gatsby. The first post introduced Gatsby by explaining its product vision. In the second one, we discussed several architectural views and the third one explored technical debt. This essay will cover another architectural concept influencing Gatsby’s flexibility and maintainability: variability management. Due to Gatsby’s plugin architecture with over 1800 plugins, it has an “infinite” number of different possible configurations. Still, everything works together surprisingly well!