DEV Community

Steve Baker
Steve Baker

Posted on • Edited on • Originally published at stevebaker.dev

Creating a portfolio site using Gatsby & Trello

#gatsby #trello #staticsitegenerator #ssg

If you want a portfolio site that updates itself without managing a CMS, this might be the approach for you. I had all my project data already sitting in a Trello board - so instead of duplicating it somewhere else, I wired it directly into a Gatsby static site. Here's how it works and whether it's worth it.

What is Gatsby?

Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps

Gatsby allows you to build a static site, similar to Jekyll but with a lot more to offer - you can use a range of node packages & use React features such as Components etc. You will build a site using React but when built, a static site will be generated (with minimal JavaScript & dependencies - just good ol' HTML and CSS!)

My Trello 'Projects' board

The idea for this project was to expose data from my personal Trello board & showcase some of the projects I've done in the past or am currently working on. The information was already in this board so why not expose it (as opposed to duplicating this data in a Content Management System)

Hooking it up to Trello

This project was surprisingly simple in the end, I basically ended up with a handful of components - a ProjectList Component, ProjectItem Component and ProjectDetail Component ('Project' mapping to a single Trello Card).

To scrape the data from Trello & dynamically generate a page per Trello Card (& also a Project List page), I used the gatsby node APIs and ended up with something like this:


...
// Use a Trello API to gather the data
const trelloCards = myTrelloHelper.getAllCards();
...

exports.createPages = ({ boundActionCreators }) => {
  const { createPage } = boundActionCreators;

  // Page to list all projects
  createPage({
    path: `/`,
    component: require.resolve("./src/all-projects-template.js"),
    // Data for this page - we require all of the Trello Cards & Labels
    context: { trelloCards },
  })

  const cardTemplate = path.resolve(`src/card-template.js`);

  var showdown = require('showdown');
  var converter = new showdown.Converter();

  // Create a page for each Trello Card
  trelloCards.forEach((card) => {
    const path = card.path;

    // Convert our Trello markdown to HTML
    card.details = converter.makeHtml(page.desc);

    createPage({
      path,
      component: cardTemplate,

      // Send the card data to this component so we can render the cards details
      context: {
        card
      }
    });
  });
};
Enter fullscreen mode Exit fullscreen mode

Benefits & Drawbacks

Benefits

  • Security - The data source (Trello) isn't publicly available - only my CI and my local dev environment have access to the Trello API Key (although it's just a readonly key, I still wouldn't want users to access my other Trello boards or cards!)
  • Cost - Hosting a static site is cheap / free as there is very little architecture - no API's to host & using Trello means no cost for data storage
  • Stability - As this is a static site with no JavaScript, no API's and no database, there's less points of failure. No worries of unhealthy API's or databases having issues etc. If the API being consumed does have performance issues or is down, the end user won't see this - the generated content will just be slightly outdated.
  • Speed - Static content means there's very little / no JavaScript (bulky front end frameworks can drastically reduce page load and render speeds, especially when not configured properly or minified) & everything can be cached via a Content Delivery Network.
  • Effort - I don't have to duplicate my content! As long as I add the correct tags & readable content on my private Trello board, it will get transformed into a readable web page

The main drawback I found was:

  • No real-time updates: It currently doesn't update in real time though I have my project set to rebuild & redeploy on a regular schedule along with any git commits. I could also use Trello web-hooks to trigger a build which seemed a little overkill for my needs

Conclusion

This approach is quite flexible - swapping in another data source (CMS, API or even a different Trello board!) would take minimal effort.

Top comments (0)