Frontend or Backend Where To Start? - Software Architectural Decisions

Every journey starts somewhere.  When we architect a solution, we need to decide whether to start at the frontend or the backend.  There are pros and cons to each approach.  Therefore, we need to look at each project to help us determine which method is best.  Let's look at the strengths of each of these starting points.

The frontend often feels like a comfortable way to start.  You can focus on user experience and the visual pieces of the solution.  This can hide complexity.  On the other hand, it is well suited to things like stories and clickable demos.  We will have visual designs and decisions that can easily be shared and assessed.  We also are pushing technical issues like validations, manipulations, and similar data issues off until later.  Nevertheless, a front-end approach does help us quickly design pieces of the solution that can be discussed and challenges (like validations, manipulations, and rules) highlighted as we see the vision move to something more real.

The frontend is not all pretty controls and user-experience widgets.  We also will be building out critical data items and interactions as well as the first steps for business rules and logic.  Do not underestimate how much of your architecture can be launched from the frontend.  Learn more from this article: User Experience Design For Developers.

We all tend to associate the backend with data.  Of course, that makes sense as the bulk of the backend is data and storing the same.  This approach may feel like a cold implementation that ignores the user experience.  However, it is not only a function over form approach.  There are many rules and performance decisions that drive this part of the architecture.  We will even be starting into user experience decisions like drop-downs or other selection approaches.  More importantly, we will be modeling data in a way that will smoothly lead to frontend requirements.

A good example is an address field.  We look at the ways an address can be stored, and this will directly inform the best approach (or approaches) for the frontend when handling this data.  This approach will even help us avoid re-architecting pieces that come from improper assumptions.  Of course, proper questions and attention to detail can provide the same result.

While we do not touch on it in this episode, you can start from both ends.  Your UI decisions can be used to help drive backend architecture and constraints.  Likewise, backend decisions can nail down frontend controls and needs.  While either approach works on its own, you can always alternate between the two methods to effectively "walk-in" the precision of your architectural design.