Skip to content

Build software from front-to-back

Last updated on May 15, 2020

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.

Published inTechnical


  1. Jim Jim

    I have been dabbling in full-stack for about 2 years now. Being a embedded C++ dev full-time and using web technology for tools, etc., I find the back of the stack easier to implement. However, I have found the quicker I address the hard stuff, the quicker the entire project gets completed, and more accurately with less re-factoring. For me the hard stuff is the front-end. Recently I started using Angular 9 and I’ve found even the hard stuff is easier.

    • Oh man that’s a far tougher jump than I had to make – I was still working on HTTP endpoints most of the time as a back-end dev. I really liked React/Vue.js when I first transitioned for the structure they gave. They let me think in familiar terms to the back-end work I was doing.

      Recently though, I feel like the connected document model of the web has really clicked for me and my need for JS has dropped significantly. I’m really happy now building sites like it’s 2006 with some MVC framework then sprinkling JS on top at the end. I still reach for SPA’s every so often but I feel like my plain ol HTML powers are now solid enough that I can get 90% of the way there without them. Ymmv of course.

  2. It sounds like you have just re-invented the completion-backwards principle. I just went through about a dozen search pages to find a link to this but the webosphere seems completely polluted by the Tubes album of that name so I’ll just wing it from memory.

    The completion-backwards principle is based on the idea of starting with what you want to end up with and working backwards from there. I recall it from pre-internet days of coding but have no source.

    • Haha, I appreciate the effort to find something to link to. I guess there’s nothing new under the sun?

      On the hacker news discussion it was mentioned that this approach is the one advocated by SICP. Could this be where you learned it?

      What funny about this, is that I’ve written back-end code like this for years. I build out static types and function signatures then fill in the details. It just took me a long time to realise it could apply in a broader sense.

      • There is a pedagogical strategy called Understanding By Design which does something similar – you start with where you want to get to and then plan backwards from there.

  3. I’ve also had pretty similar experiences while transitioning to full stack from backend. Doing front to back dev is something i have thought about in the past but not yet acted upon. Your post has given me the confidence to try it out in my next side project! Thanks!

    • Glad to hear it! I’ll be writing more on this soon in our primary tech stack (kotlin w/Spring Boot), so check back if that fits your tech well.

  4. Saksham Saksham

    Since, I am a fullstack developer as well, I related to the issues you described.
    I haven’t tried this approach till now, but do let me know have you tried JSON server to generate the client side database for mocking the API’s.
    Also like to know your views on GraphQL, is it a game changer for these situations in a fullstack developer’s experience.

    • I’ve tried a couple of more technical approaches to this over the last couple of years but they’ve never quite been worth the up-front cost. We’re a very small company and we generally let individuals fly solo for the first couple of weeks on a project though. Similarly, we don’t really build API’s that are consumed by many different clients so GraphQL is a little overkill for us. I can totally see how that approach would work on a larger team, or in a larger company where multiple teams are loosely collaborating.

  5. Nikki Nikki

    After 20 years in web development across the whole stack, sometimes by myself, I have come to a “middle out” philosophy. Build the API first, let that be the contract between the front and back; they can then go and write a UI to that contract and on the back end a data model.

Leave a Reply

Your email address will not be published. Required fields are marked *

Creative Commons License
Except where otherwise noted, Happy Valley IO Blog by Happy Valley IO is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
You are welcome to buy a license for any post on this site by contacting