Hi, we’re JP and Sam, we work as software engineers at the Centre for Effective Altruism (CEA). We’re answering questions about our work on some of the projects many EAs use every day (including this Forum, Giving What We Can, EA Funds, and a bunch of other behind the scenes stuff).
Also, CEA and GWWC are both hiring software engineers, so it’s a good opportunity to ask questions about what it’s like to work here before you apply!
We’ll be answering questions on Tuesday, March 16th.
CEA and GWWC are both hiring software engineers. We build and maintain the tech that any new engineers will be working with (including this Forum), and we know what it’s like to work here. AMA!
JP previously worked at an aerospace startup detecting methane emissions with spectrometers on airplanes. He’s interested in table tennis, plants and economics.
Sam started at GWWC back in 2015, then built EA Funds from the ground up over the course of a few months while CEA was in Y Combinator. He has a past life in party politics.
Ask us about:
- Working on a small team
- Non-profit vs startups
- Our tech stacks
- Anything!
NB: EA Funds is now largely an independent org, so Sam will generally be talking about what it was like working at CEA until very recently. However we still work closely together because we make a good team and are working on very related projects.
Bonus: Although Ben West is no longer primarily an engineer, he built a popular healthcare analytics platform and founded a successful startup. He’ll be managing the new CEA engineer. You can also ask him anything.
TL;DR; – For Funds/GWWC, the frontends are React (via NextJS) running on Vercel (previously a React SPA running on Netlify). The backend is a bunch of Node.js microservices running on Heroku, connected to a Postgres DB (running on RDS), and wired together with RabbitMQ. We’ve migrated most things to TypeScript, but a lot of the backend is still JS. A lot of business logic is written in SQL/plpgSQL.
---
EA Funds and GWWC have been on the same platform since 2017, and share the same backend.
The frontend was a pretty standard React SPA written in JavaScript, but we’re currently in the process of deprecating this for a NextJS app written in Typescript (which has been a huge win in terms of productivity). EA Funds has been ported (compare the new with the old) already, and the incoming GWWC developer will be working with me on porting the existing SPA functionality to the same NextJS-based system. The new sites are in a Git monorepo managed with Yarn Workspaces, meaning that eventually all EA Funds + CEA sites will be able to share components/login architecture/backend connections etc.
Down the React rabbithole a bit: We connect to the backend using Apollo to manage GraphQL queries, we use Immer for immutable state management as needed (though we don’t use Redux or any other global state management). UI components are provided with Material-UI.
I used to use Netlify to host the EA Funds/GWWC frontend, but we’ve moved to Vercel for their first-class NextJS support.
The backend is a collection of quasi-microservices running on Heroku, all written as Node.js apps:
---
In addition to EA Funds/GWWC, I’ve also helped set up a bunch of other sites used by CEA (e.g. EffectiveAltruism.org, EAGlobal.org, CentreForEffectiveAltruism.org, the GivingWhatWeCan.org homepage). Most of these are currently using the Metalsmith static site generator, which generates static HTML files that are served via Netlify. This setup has been fantastic for performance and reliability, but eventually these sites will be ported over to the NextJS monorepo for better maintainability.
---
In terms of pain points, it’s generally been a pretty solid system. The biggest challenges have been maintenance. E.g. we’ve migrated to NextJS, partly for the improved performance and DX, but also because the previous SPA was running an outdated version of React, and because of the way the boilerplate I used was architected, upgrading to a more modern version (which many packages now require) was more trouble than it was worth. Similarly, all the static sites have historically been hosted in their own repositories, which has meant that they all have slightly different ways of doing things, and improvements made to one don’t propagate to the others. Hence, the move to a monorepo, where we can share components/logic between sites. Also, the more I use TypeScript, the more I hate using vanilla JS, so I guess that’s something of a pain point in the parts of the backend that haven’t been migrated yet!