Frontend/Backend Linking Fiestas and the Importance of Planning

Written by Trevor Du, JAMHacks Organizer

Typically, projects that use the interwebz are composed of a frontend and a backend. The frontend is what the user sees, while the backend is what wrangles data and serves it up to the frontend. IDEALLY, a clean, well-designed frontend works with an efficient, well-designed backend to form one cohesive unit. USUALLY (from personal experience), hackathon projects end up becoming a Godzilla frontend and an eldritch horror of a backend held together by a couple threads.

The trigger is time-pressure and the culprit is a lack of planning—something I’m often VERY VERY guilty of. One of my most vivid memories was during “cram hour” (the hour before the project deadline): the backend needed to serve image files to the frontend. The problem was, the two ends used two completely different methods of communication. Forty minutes were left on the clock and… chaos ensued. Luckily, we managed to stitch together a (very) sketchy fix just in the nick of time.

Usually, when working on your own (on, say, a side-project), you have a pretty good idea of how the frontend functions, how the backend does stuff, and how and when the two ends communicate. However, given the need to make a sophisticated project under the tight time constraints of a hackathon, teams usually like to split into “frontenders’’ and “backenders”.

But in this scheme, where you only work on one segment of the project, things can easily go south if there’s no unified plan of how the project’s going to work. The reason why things went (deep) south in my personal anecdote was because we didn’t bother to plan.

So far, I’ve been giving you an earful about why we need to plan, but let me talk about how to plan. Usually, I like to draw out some sort of flowchart on a chalkboard/whiteboard. Typically, it depicts the flow of information through the backend, to the frontend, and then to the user. Off to the side, we have a to-do list that, well, lists any TO-DOs we have (to do). I think this is a pretty good framework for planning and has worked well for almost all eight of the hackathons I’ve been to.

Just to make it clear, though, this method is what has been working for me. People are different and I’m not some sort of know-all hackathon guru (actually, I’m pretty inexperienced in comparison to some people I know). Anyhow, I encourage you to experiment with different ways of doing things until you find something that works.

Oh and, one final note: never forget to plan, but don’t plan too much either. What’s the point of planning if there’s no time to actually enact the plan, right? It might sound difficult to strike a balance, but trust me, it gets easier and easier over time.

Anyways, that’s all I really had to say. Good luck out there and keep thriving at hackathons!