Diving in at Cogapp

The learning curve in my first six months at Cogapp has been exactly what I was looking for when I made the move from my previous role: steep.

Before Cogapp, I was working in an analytics role with a mostly Python background. My motivation was to get up to speed with Cogapp’s tools and processes as quickly as possible.

On the long list of cool clients we get to work with is the MIT Museum, who aim to open the door to the exploration and exchange of ideas at the intersection of science and art, innovation and research. They have a huge and varied collection and are part of a world-leading research institution, so they are quite well placed to meet these aims. Our job was to help them build a website to do this ambition justice.

I joined the MIT Museum project team part-way through the development. One of the first things I noticed was that at Cogapp, we like to explore the possibilities that new tech can offer, and this project was no different. Some of the technologies were new to the rest of the team but mostly they were familiar. In my case, most of it was new.

Dipping a toe

Tech we used that I had some knowledge of: GraphQL, React, Git, JavaScript, HTML, CSS (i.e. the basics).

Tech we used that I had no real knowledge of: Craft, TypeScript, Next.js, Storybook, Sass, Prisma, Jest (i.e. lots to learn).

Luckily, there have been a few people who’ve joined Cogapp from different backgrounds. People here make themselves available to help (even if you feel some of your own questions are rudimentary). I found this to be an invaluable resource, not just to get some pointers when you get stuck, but more so to discuss the reasoning behind the solution. This was particularly useful when hitting something tricky and niche, like React hydration errors on server-side rendered pages. (p.s. your solution could be here).

I knew what my knowledge gaps were, and colleagues on the project team knew what I’d be able to figure out with some support, so it was time to dive in.

Note: everything in this post is my take on things, it will almost certainly not use the correct terminology, definitions, etc.

Shallow end

One of the first stories (story = a unit of work to enable some feature) assigned to me was to enable Content Management System (CMS) users to add a table to a page. Not the most complicated task in the world, but on reflection it was a great way to learn about how the CMS and front end fit together.

First things first, getting my machine setup for development. Clone the repos, and follow the steps on the README (which worked first time — not my experience historically).

The CMS (Craft) was totally new to me, but fortuitously a training session was run by my colleague Luke (who also happened to be the Producer on the project — coincidence?). From that session I learnt that Craft is really intuitive, both for developers and content editors (which is why it’s being used more and more here at Cogapp). By the end of that day I’d created my branch on the CMS repository and added the new field which would allow users to add a table to any page:

For MIT Museum, we are using Craft as a headless CMS (it exposes an API to get page data). The front end needs to request the data from the CMS’s GraphQL API, to return the table’s data in the following format:

We used Storybook as a way to build and test components in a sandbox, i.e. in isolation. This makes it easier to focus on what the component accepts as properties, and what it needs to do with them. Once it’s ready, implementation on the front end is simply adding the component to the page and passing real data to it.

Knowing the data structure we can expect from the CMS, my initial thought for this component was something like: “we should just pass tableContent to the component, and keep all the render logic in there.” However, by discussing this with the other developers on the team, I realised that this approach wasn’t ideal. The component shouldn’t be expected to do the heavy lifting. Instead, the component should be as simple as possible. It should have an expected behaviour and it should be able to be reused in different contexts.

The component itself could simply be a wrapper around a <table> element, with some custom styling, and it should accept children. All a developer would need to do is pass data to it correctly, as shown below:

Now that the CMS was updated, and the component was created and tested in Storybook, it was over to the Next.js front end to plumb it all in.

On this project we used TypeScript, which requires you to define the type of your data structures, and in return it’ll help you avoid errors before they happen.

I could now update my types, based on my new CMS branch, so that my locally-run frontend knows about the new table’s data structure. Now, TypeScript would let me know that the data available is an array of objects that have the keys ‘label’ and ‘value’ and that both values are strings. So, if I tried to reference a key that wasn’t there, I’d get a helpful error message to tell me so:

All I had to do was add my component to the relevant pages, update the queries to request the table’s data, and pass this data into the component, and check that it all worked:

By building what felt like a tiny addition to the project I had touched lots of different technologies: Craft CMS, React, Next.js, Storybook, TypeScript, not to mention GitHub actions, Platform.sh, Vercel and lots of other lovely utilities the team had set up to make sure code was of a high standard.

More importantly, I started to learn more about how these things work, how they all fit together, and why they are needed.

Getting deeper

Since I’ve joined Cogapp and the MIT Museum project team, I’ve steadily widened my exposure to all aspects of the project:

• getting the most out of Next.js (such as server-side vs. client-side rendering, API routes to avoid exposing private endpoints)
• integrating third-party APIs (such as powering forms, and some elements of The Exchange)
• contributing to the Collections API which surfaces all of MIT Museum’s collection data
• building the collections search page
• building the collection resource pages (some of our favourites: Rolling Murderer robot, some cool holograms and an 1830's sketch of Cogapp’s hometown beach)
• learning how a banana reacts to being shot (see for yourself)

Life underwater

My summary of my first few months at Cogapp: learnt lots, lots to learn.

I was eased into things, rather than overwhelmed. I was surrounded by experts who are happy to help, no matter how big or small the question.

We have well-established processes and structures resulting in less wondering, more doing. There are many opportunities for training, be it self-directed or via a colleague delivering a Tech Tuesday talk (accompanied by a nice lunch).

There are regular hackdays of an uncategorisable nature. And the office has maybe one of the best views of Brighton.

I’m glad I took the plunge at Cogapp.

I’m not sure where the water metaphors have come from, probably too much time spent looking at the MIT Museum’s Nautical Collection.