<aside> 👋 This was a proposal I wrote to Zach & the HQ team for doing some contract work to modernize Hack Club’s web services. It’s preserved as it originally was, but that’s why it lacks much context. Capitalized projects are for the most part referring to GitHub repositories, such as API, DS, Site, Hackathons, Apply.

</aside>

Note: this proposal is excluding Bank, since it’s under its own team/care.

Looking back

API/DS & a lot of Hack Club engineering from that era failed for several reasons, but I/we’ve learned a bunch of things.

• DS was incredibly brittle for trying to account for all cases, needing major breaking changes for even small flexibility, and I was the only person who understood it fully/contributed.
• Writing content in JSX/DS code made it so I was the only person really working on it, which was unsustainable for the org—even small things, like the Updates page (which died for other reasons), were somewhat blocked by the need for engineering.
• Putting content (Workshop Projects, Challenges, etc) in API meant the minimum barrier to entry for systematizing anything inside Hack Club was: committing to a (realistically-unchangeable) structure, Zach/Max building a Rails API, then building stuff like Challenge & Admin on the frontend. This meant we couldn’t experiment without weeks of engineering on both frontend & backend, so we used systems with a lot of maintenance for a limited duration, then gave up.
• Having everything bundled together inside two monolith codebases (API & Site) meant the cost of making any changes was significant. On the backend, years-outdated legacy code was intertwined with new features (see: Hackbot making PRs to update Site submodules). On the frontend, design changes to our marketing site broke Admin, Apply, Challenge, etc. Unbundling Apply, for example, was a great decision, as that site has never since broken, versus regular issues previously.

Since then, we’ve had a bit of a revolution (especially for ops), through Airtable. It’s given us flexible structure with UI from the beginning, & now we can make systems without coding. It’s become clear that we need this same situation for web tools.

Vision

I want all Hack Club web services (excluding Bank, they’re doing their own thing) to be Airtable-powered, small-scoped, low-code, & super fast to develop. The smaller services architecture just seems better suited to Hack Club. Bank works great but only with a team continuously attached—API & Leaders & Site are going bad without continuous maintenance.

We currently use Airtable to prototype data structure & add data to Airtable, then Airtable Forms for getting input. This is great, because it reduces the barrier to entry so much. But we should be able to make little web tools, on top of the Airtables, when they make sense.

• Sites like Hackathons or Map, to expose data from Airtable onto the public web
• Sites like Apply or Packages, which have login/forms/etc but with data to/from Airtable

This is critically not code-first, it’s coding things when they provide clear benefit. For example, on the new Hackathons site, an Airtable Form has been working great for submitting events, but when we can see a clear improvement that can come from custom code (the Hackathons cards creator), we can make a better product without coding that in the first place (& possibly preventing the project from shipping early because of it). Plus, we can do this with one person (building the site with no backend changes), and without adding to an unmaintainable pile (Admin portal on Site), by adding a frontend that submits back to Airtable just like the Airtable Form did.

Thinking about technical debt

One of the big issues with Site/DS/etc was all the dependencies upgrading, leaving the codebase behind. Especially in JavaScript but regardless of language (see Leaders), there will be technical debt & things that go wrong.

I want none of these services to be critical in the way they used to be. For example, Admin was basically the only way to edit data in the Rails API. As we’re seeing with Hackathons, if all the data is always accessible/editable on Airtable, we’re never locked out from it (Admin portal breaking), & if the structure needs change, an entire replacement site can be made in 3 hours (that’s what I did) without touching any other parts of the org. We can edit the sites, or entirely rewrite them, at any time, very quickly, without leaving ourselves stranded.

We can make the best technical choices we can right now, but ultimately the org is probably going to have different problems & want to use different tech down the line. So I think a better approach is, in the meantime, reducing our critical dependency on whatever tech we end up using. We should be able to cut entire projects, build replacements, & not be locked into any technical choices too closely. What’s important is that we always have something functional, at every stage—Airtable + Airtable Forms works, the sites on top are just augmentation.

By keeping the data in Airtable, then making our sites small & single-purpose (opposite of Admin, Challenge as part of Site), we can make sure the data is never stranded, the sites can be disposable if needed, and we can stay shipping instead of stranded.