Static websites have great performance, security, and simple data management. With the right tools, we can add these static site benefits to our Django site.
How do we get great performance for the most heavily-trafficked portions of a site? How do we increase security for areas not secluded behind an authentication barrier? How do we do this cheaply so that we can spend our concentrated efforts on our user experience and product?
Lots of time and effort can be spent on managing our dynos, cache-storage policy, and content delivery mechanisms. Completely important! We should spend that management on our application and its customers. It shouldn’t be wasted on ensuring our landing pages and API documentation aren’t running under strain after we release version Coke Vanilla Lingonberry.
We want a set-it-and-forget-it solution with minimal handholding where we can center on the content and know its going to fair well after making the rounds on HackerNews.
Time is a flat circle! In its early years, the Internet was driven by static HTML and its latest incantation is getting another serious look. Static sites help keep our end-product and its support straight-forward. Batteries included, they come CDN-ready with quick data transfer, rendering, and high security.
Static sites have increased security as there is no database. In the case of a static-site generator, the database is only accessed during build and is removed from client-side connections. Limited server interactions outside of asset request greatly cut down on security vulnerability.
After compilation, a static site is completely CDN-ready; each page has been built out and can be immediately cached for use on a content-delivery network, such as CloudFront. While there are similar workflows for dynamic sites, typically each dynamic page must initially be requested by a browser before being built and then cached. The static site caches the complete page before it’s visited and only regenerates when the development team commits to a new production build.
Tack on that static pages, as cached elements, are easily transferred gzipped (often a default through the CDN) and you have a production code base thats smaller to transfer and more quickly rendered by the browser. or customer interacts with a performant site without waiting for a page’s own “build process” to happen.
What about client-side interactions? The visitors gets a completely rendered page and interacts with the site just as we intended. As is the case with Vue, JavaScript silently “hydrates” the page without the user knowing that Vue taken over. In a hydration process, the front-end code will replace elements on the page with JS powered versions. If the JS breaks, or a customer has Javascript-blockers running, we’re still running a regular-old HTML site.
How do we use the static-built experience that relies on the power of a Django-based back-end to drive application data? We can do just that with the newly released Gridsome, a Vue.js static site generator. Gridsome is influenced by Gatsby, a React-based and GraphQL-driven static site generator.
Gridsome uses a combination of static data and data from various endpoint data sources to create a rich interactive experience. In our case, this data is pulled from an internal Django API.
On build, Gridsome compiles its static pages from GraphQL queries of our supplied data. The framework supplies routing and helpful metadata management. JavaScript is automatically separated into smaller individualized code bundles that are only requested when needed.
When the user views the site, Gridsome hydrates the page with the Vue-based components and works as a single-page application.
Gridsome provides distinct power in its implementation of data source plugins. Source plugins pull in data from a directed source endpoint; be it markdown, JSON, databases. The plugin will inject that data into a local GraphQL database and query for specific data during the build process. We can even reference the various data sources as needed and create an extensive data set through taxonomy definitions and relations.
The use of GraphQL is key to our efficiency on the front-end. The declaration system is similar to a JSON representation and we can get up and running in a few hours. GraphQL is very much a “What You Query is What You Get”; through relatively simple declarations, GraphQL will supply only the needed data for a given task.
No more returning unneeded data through a general catch-all SQL query or spending inordinate amounts of time crafting specific SQL queries for that oddball piece of data that you need.
Gridsome comes with a slew of common-use source plugins. A general file-system plugin processes Markdown (through Remark), JSON, and YAML; traditional CMSes, such as Wordpress and Drupal, can be used; and there are plugins for headless CMSes, such as Contentful and CosmicJS.
The source plugin system is entirely extensible, making it easy to develop a plugin for our own requirements. A Dropbox source can work with the Dropbox API to parse document metadata in a particular directory and supply a list of available documents. A Firestore source can query various distinct Firestore collections and import them into GraphQL for further use.
Gridsome’s data sources open the door for extending our reach into using Django as a back-end data system. We can use Django’s data models and tap into them via private API calls. Gridsome will then process this data and have it available for our front-end development.
The beauty here is that you can opt in for where a static site best serves your needs.
Supply Django with a general catchall view or url declaration and let your static site run free. Your server-side generated views, those that are not recommended for caching or may require extensive server-side application logic, can live as conventional Django-driven templates through explicit declaration in Django as usual.
Gridsome might submit form data to Django for its powerful validation or data processing. Or use Django and distinct API endpoints as a “localized” lambda or function registry. Django developers excel at using micro-services to get a task complete and Gridsome is no different than a micro-service we might use for exception handling.
Gridsome is still on its way to a 1.0 release. The team is finalizing development on various pieces for the single page web-app functionality (such as built-in Service Workers) and finalizing tests as various users kick the tires. However, as its primarily a superset of existing technology and produces static HTML (just like the old days), we can content ourselves with smaller sites or portions of an existing site.
The framework has some great introductory documentation; its only going to get better as documentation and example code are high-order for the team. Its core developers and community are friendly and responsive to any request about the burgeoning system.
Static sites aren’t a wholesale replacement for dynamic sites. Static portions of sites can best serve dynamic portions and carry the load of more content-rich sections.
Let the server-side system do what it does best: heavy data manipulation and large scale relational data models. For now, we’ll continue to use a combo of Gridsome and Django-Templates for the client-side and see where it takes us.
Take a look to see how you might get started on using static sites with Django!