Build software from front-to-back

I’ve transitioned over the last few years (through a combination of interest and necessity) to being a full-stack developer. In this time my front-end-fu has definitely improved a great deal. Yet, I know that I’m not going to win any awards for innovative contributions to CSS Tricks. I do not think I will even be as comfortable as I am working on back-end changes.

As a result of this bias, when implementing full stack changes I’ve always started with the back-end. I’ll build out a service layer, create a database schema, write a bunch of tests, and eventually build the API around the structure of my data. It felt nice to start in the part of the stack in which I’m strongest and to figure out the rest later.

This is all backwards and it leads to heartache. You might even say that it’s back-to-front (pause for applause).

I’ve often ended up with API endpoints that are not quite right, which has led to the temptation to aggregate some resources on the client side. I’m not a huge fan of aggregation logic in the view layer, so I have generally submitted follow-up merge requests to alter the API before it hit prime time. This churn wastes time, and is pretty frustrating for both me and the reviewer.

I’ve been doing something a little different recently. I’ve been working front-to-back. I’ve been creating the user experience I’d like to see on the UI up-front with mocked data. I do this by hard-coding data in a client-side store for a single-page app, or by hard-coding models in the controller for a multi-page app. In this way, I can try some things on for size and get feedback from the team before I’ve invested too much time. I can even deploy it behind a feature toggle and let some alpha users give feedback very early in the dev cycle.

I now have a much more well-defined idea of what I’m trying to achieve throughout the work. At first, I thought that my REST-ish approach to the API would devolve into RPC over HTTP. I worried that it would tightly couple UI features to the API, but this hasn’t been the case. My endpoints are a little heavier, but they’re structured in a much more sensible way.

It’s interesting to realize that I’m now comfortable enough across the stack that feature-rich/data-light changes are implemented much faster in this way. I’ve recently been using StimulusJS (I’ve talked about it here) and have been treating HTML forms as the basic building block of my application. Maybe Visual Basic’s form-centric approach was onto something after all?

I would guess that my prior inclination to build changes from the back-end up came more from seeking safety than any explicit decision. I’m curious to find out whether other back end developers go through this process when transitioning. Do front-end devs end up having the opposite thing happen?

Update: there’s some really good discussion around this on the hacker news post.