The Technology Behind React Finland

The website of a conference is often the entry point to it for a lot of people. We’ve developed it iteratively, and continue to do so. I believe it’s better to publish something that works soon than something that’s perfect too late. Given we are running the conference as volunteers, time is an issue as well as you have to get most out of it.

The site uses a LESS for styling at the time of writing. It’s not a popular choice but rather something that our designer picked and it stuck then.

It would have been simple to maintain this blog on top of the site but we decided to go with a Medium based blog instead since it has a potentially better reach within our target audience. Running a blog of your own is more of a long term strategy although it gives you more control and flexibility.

Early on it was clear that a part of the team wants to develop a mobile application for the conference. This led to a challenge. How to share the schedule, speaker information, and all other data with the site and the mobile application?

The content has evolved since and I moved from pure JSON to JavaScript as that’s more convenient to consume.

Having a content repository was a step forward and it cleaned up the site implementation. Some content, such as copywriting, remains on the site itself as it isn’t needed elsewhere. I have all the information I have to share at the npm package.

Although this was a step forward, we noticed another problem. What happens if we update the data? You have to update the content dependency at both the site and the mobile application. This is simple to do for the site and could be automated to a certain degree but it’s more complicated for the mobile.

If you update the application this way, you have to publish a new version for the users to download. That’s not ideal as we might want to perform changes to the data during the conference.

The current version of the GraphQL API is surprisingly simple and it could be simplified a notch further. Essentially it maps the data as a GraphQL API using the data definition. There’s a small function that generates the queries GraphQL expects.

Since data is modified only through the content repository, we didn’t have to worry about mutations. This kept the GraphQL portion simple.

The site consumes the content through GraphQL client. Whenever the content changes, it will trigger a series of webhooks which will eventually update the site as well as the site rebuilds itself against the new content.

Related posts:

I first came to Brighton Electric back in 2014 whilst rehearsing in numerous bands and studying at university. Electric soon became my favourite studio to rehearse at. Fast forward a few years and I…

I have talked a lot about a variety of subjects around self-care: how to do it if you’re stressed or depressed, how to build a ladder on a bad day, how to practice mindfulness

In early January 2020, I got off at the bus station to transfer to the next bus with about another forty minutes still until I got home, yet to my surprise, I ran into the charming man I’d only been…