Hi folks!

This week I’ve been working with Next.js authentication with GraphQL APIs and thinking about the current state and future of open source software.

Next.js And GraphQL Authentication

On the live stream we’ve been building a podcast application using GRANDstack. So far we’ve focused on the backend and GraphQL API layer. This week we got started on the front end, using the Next.js React framework.

Next.js is a powerful hybrid framework that brings many additions to React. I’ve seen it described as a “batteries included” React framework that includes many built-in features and conventions you’d need to add to many non-trivial React applications anyway such as routing, server side rendering and data-fetching, image optimization, and the ability to add API routes.

In our GRANDcast.FM podcast application livestream this week I focused on setting up client-side authentication in Next.js using the GraphQL API we built out over the last few weeks. We explore how to add Apollo Client to our Next.js application, how to handle the sign-in flow using GraphQL, and make authenticated GraphQL requests once we've signed in. You can read the blog post "Getting Started With Next.js and GraphQL Authentication" or check out the video recording of the live stream.

Getting Started With Next.js and GraphQL Authentication

January 24, 2021 • 11 min read

Building A GRANDstack Podcast App: Episode 4

Next.js

Neo4j

GraphQL

GRANDstack

For this application we chose to implement all authentication functionality ourselves, instead of using a service like Auth0. I typically prefer to use services to handle as much "standard" functionality of my applications as possible, this allows me to instead focus on the functionality of my application where I can add value. But I wanted to roll our own auth functionality in GRANDcast.FM because I had several folks ask about that in the context of a GRANDstack application. It's apparent the value that outsourcing this functionality to a service provides. By implementing our own sign up, log in, managing users in the database, etc we can see the benefits we get from using a pre-baked solution. Auth0 for example has a great React SDK that we used last time in the Willow real estate search application which took care of much of the client-side authentication functionality we needed to implement.

The Future Of Open Source Software

I've been reading Working In Public: The Making And Maintenance of Open Source Software by Nadia Eghbal this week. I'm only halfway through the book but it's got me thinking a lot about the future of open source software (OSS).

A few interesting observations pointed out in the book that stood out to me:

• There's been a generational shift in OSS. Early proponents and participants were passionate about the concept and philosophy of free software (free as in speech, not free as in beer) and the licenses around their software. More recent open source developers seem to care less about the philosophy of OSS, but rather share their code because that's become the default in our share-first creator society.
• The long tail of OSS contributions. In many projects, the vast majority of contributions are made by a very small number of contributors, with many projects often being centered around a single developer.
• Github has lowered the barrier for and standardized the process of participating in OSS. This has lead to a significant increase in the number of open source contributors and placed a burden on project maintainers to handle these contributions.

The more I think about the state of open source software the more apparent it is to me that there are two seemingly divergent trends going on in the world of OSS:

1. Open source (infrastructure) companies are rethinking their approaches to open source in the face of competition from cloud service providers
2. The flourishing open source world of the JavaScript ecosystem (as one example) - largely made possible by npm and Github.

Trend 1 has been going on for several years but most recently the spat between Elastic and AWS around the relicensing and forking of Elasticsearch brought this front and center again. Critics of AWS point to AWS services that package open source software largely built by open source companies, without contributing or sharing profits with the companies responsible for building and maintaining the underlying software. Supporters of AWS point to AWS' upstream contributions to tooling like Lucene that ultimately benefit Elasticsearch as well. While AWS has been criticized for their approach, Google Cloud Platform (GCP) has chosen to partner with open source infrastructure companies to integrate cloud services run by these open source companies into Google Cloud Platform.

At the same time, many open source communities have never been healthier. For example, the JavaScript open source community has almost 1.5 million packages available on npm and 4.5 million open source JavaScript repositories on Github. Github announced in their State of the Octoverse that there were over 56 million developers on Github in 2020 and 60 million new repositories were created in the last year.

These two seemingly divergent trends are forcing the question:

What does open source look like in a cloud first world?

Some very smart people I know have told me they see this as the beginning of the end of open source software as we know it - that the threat of a massive cloud vendor service-ifying your open source software will either put OSS companies out of business or force them to no longer be truly open source. I don't think that's the case - I think the future is still bright for OSS but I do think the open source software community will need to continue to evolve to make sure that the ecosystem continues to thrive and the benefits of open source continues for generations.

I'm optimistic and looking forward to seeing what open source looks like in a cloud first world.

Cheers, Will Lyon

@lyonwj