GatsbyJS & Auth0 Tech Assessment

CI&T Australia
CI&T Australia Tech Blog
4 min readMay 10, 2021

By Evan Amezcua, Frontend Engineer, Transpire

Gatsby and Auth0 has been in our Tech Radar for a while and recently we did a tech assessment to understand its benefits and shortcomings by using it to solve an actual problem. Sharing a condensed version of our experience here for you to read.

Protec the Spec — Transpire in-house apis

Created with Gatsby, auth with Auth0

Tech to test:

GatsbyJS and Auth0

Problem to solve:

At Transpire, we have multiple projects that the team is currently working on. Most projects have an API being developed and documented, but that API spec is usually isolated in the projects repository. Sharing this documentation with team members can be difficult, and it’s not always easy to find. This documentation also isn’t always something that should be public, and needs to be housed in a way that only people who are allowed can access it.

As part of this tech assessment we thought of having all the api specs in one place, in a single project hosted in an S3 bucket, and deployed with Cloudfront. Code is hosted on internal Bitbucket repo. Api specs are *.yaml, located in public/specs/ directory.

Learnings

Benefits:

Gatsby:

  • Performance! It’s so fast. (Noted to be 2–3 times faster than similar sites in vanilla React)
  • Documentation is super robust, well outlined with good examples. https://www.gatsbyjs.com/docs/ This has basic how-to guides, but also specific guides for use with different CMSs or tech.
  • Integrations — many popular techs have bootstrapped project templates, integrations, etc (typescript!!) called Starter Libraries. This might be for a blog, a simple portfolio, or a CMS such as Netlify or WordPress.
  • There is also many nice-to-have features like react-router, lazy loading images, code splitting, PWA support out of the box. These can be tough to implement in to an existing project, so if performance is a key driver, Gatsby should be considered.

Auth0:

  • Quick and easy setup, and can be run entirely on the front end — I’m a front end dev with minimal back end/auth experience, and had it working within a few hours. This is a huge benefit in my eyes, as it would allow for a simple auth layer to be added to a project without needing someone with Cognito experience or similar.
  • JWT support in serverless applications out of the box with no cost.
  • Easy dashboard that can be used to edit settings even for a non-dev user. This may be useful for setting roles and permissions as a PM, or allowing clients to have visibility over private docs. These permissions are then passed as an object in to the application after the user is authenticated, and can be used programatically to show or hide content as needed.
  • Create rules in JS in-browser to edit permissions on the fly as users log in/out — this means that permissions do not need to be set to individual users, but can be created on an ad-hoc basis as they join if the necessary rules have been created.
  • Free with up to 7,000 active users and unlimited logins — this is plenty for a small scale project.

Shortcomings:

Gatsby:

  • May be unnecessarily complex for a very simple project such as this — developers will need to be familiar with GraphQL to best utilise Gatsby.
  • Regular CRA React app is faster to develop -> deploy a simple project if you’re familiar with the process.

Auth0:

  • Additional price to factor in, and is considerably more costly than AWS Cognito
  • Community support appears to be lacking for free tier customers, but dev level support starts at $13/month.
  • $23/mo for: Up to 50,000 External MAU, Unlimited Social Connections, Custom Domains, Role Management, Up to 5 Rules but only 100 active users monthly.
  • Cost scales exponentially, roughly $114/mo for 5000 active users, or $1000/mo for a developer pro account. Anything over 50k monthly active users requires contacting Auth0 for an enterprise solution.

What is still to do?

  • A strategy for publishing api specs to the code repo with as little friction as possible — I’d like to avoid needing to cherry pick commits, or force people to push their code to two places. This solution will only be useful if the spec sheets reflect the most up-to-date version of the API, and must be a source or truth.
  • Deployment pipeline that will allow the resources to be up to date. There is still an ongoing discussion on the best approach to solve this problem.
  • A way to port this app so that it can be easily used for a single project

Did this meet the needs & solve the problem?

  • Yes, I believe that it did. However, for a project of this size I believe using Gatsby would be an unnecessary overhead to introduce. I think that Auth0 was the stand out technology from this assessment, and I can see it having a place in a number of small to medium sized projects that need authentication functionality.

Any other alternatives:

  • Next.js is probably the biggest and most common alternative to Gatsby, and as it’s more mature/established it may mean that finding experts comes easier.
  • AWS Cognito for auth, while more complicated, is still tied in to the AWS suite, making data analytics easier. Cognito is also exponentially cheaper, however this comes as the cost of complexity.

--

--

CI&T Australia
CI&T Australia Tech Blog

CI&T partner with the world’s most valuable brands to build digital solutions that transform businesses