Developers October 26, 2020

Frontend vs Backend, where to start?

Vincent @onenull

The majority of my software development career I've focused on backend development, naturally I'm more comfortable there. However as I've started working on my product I've realized that designing the schema, data models, and API first isn't the most efficient use of my time because things change dramatically as I build out the frontend and discover my assumptions were wrong.

I did some research and came across this video on YouTube:

His recommendation is to begin with the frontend and figure out the user flow, then once that's understood you can start working on the backend. It seems to make a lot more sense so that way you have an idea of what you need before you build it given you're starting with what your end user sees.

Sharing my experience and looking to hear others!

  1. 7

    My recommendation is begin with the design mockups even before frontend. I make my frontend models off that. Then build frontend and backendpoints in chunks of the design.

  2. 4

    Back in the days I used to start with the backend as well. But just as you have discovered, when you finally hit the frontend, you'll often realize that some things won't work as planned and suddenly you are into heavy refactoring of stuff you haven't even used to begin with. My workflow has shifted toward the frontend while never going as far as working against a complete mock-backend but instead keeping the backend in sync as I go.

  3. 3

    Interesting dilemma. I am a Frontend developer, so from my perspective it is easier to start with Frontend and define the data models I eventually want to receive from the backend. In development, I use static JSON models to represent this data so it's easy to tweak the data model.

    Eventually, when a feature is ready in frontend, I start working on the backend. I never completely finish a project's frontend without spending any time on the backend. So, from that perspective I agree with @thewhitelynx: Polish them both in parallel, but, for me, frontend first makes the most sense.

  4. 3

    +1 - also more comfortable on the backend, but frontend makes a lot of sense.

    I like a bit of a middle ground where you get the minimum functionality in the FE in first up to the point of calling your various backends (perhaps with placeholders), and then figure out the backend, and then polish both in parallel.

    FE first helps you figure out exactly what you need.
    BE minimum gets to fully working product.
    Then polishing both in parallel allows you to focus your time wherever it will be most useful now that you see where the problems lie in both places.

  5. 2

    Where is your problem located? Build there first.

    If you are doing customer interviews, you should build or scaffold the part that you’ll demo to your customers. If they indicate that you’re solving the wrong problem, you won’t have sunk a lot of time into a functioning backend only to have to redesign your product altogether.

    A functioning and basic front end, however, can be hosted from your laptop with toy data to let users interact with it during a demo.

    I’m also a backend dev and CSS scares me so I feel your pain! But I’m planning on demoing the interface to see if I’m solving the right problem, so I’ll need to build that first.

  6. 2

    Like @aPleasantFellow mentioned, I like to start with design mockups before even starting on the frontend.

    That said, for a lot of things, it's easy to just build out all the boilerplate/whatever that you know will be common across the backend- users, accounts, comments, messages, or whatever common type of tables you know you'll have. I tend to have all of that built first, but it's also common across a bunch of applications I have, so I guess it's not really "building" it first, as it's already done?!

  7. 2

    In my experience, letting the frontend dictate your data structure ends very poorly in the long run. What if, down the road, you end up wanting to significantly redesign your front-end? Would you then refactor the structure of your data? What if you want to add an API that is accessible by your users? Maybe a mobile app?

    All of those use-cases have different access patterns and may require different forms of your data. The backend should be the single source of truth with a translation layer in between to service various "clients". What I typically do is design the MVP version of what my data is going to look like along with the corresponding API, and include tests for everything. This way, I can treat my front-end as a sort of consumer/client of my backend data.

    Since I typically split my backend and frontend into two separate services (NodeJS with express; server-side rendered React for the frontend), I have the flexibility of building a sort of backend-for-frontend for my React application. This way I can create front-end specific API routes that combine/aggregate together multiple backend calls to get the right data and format I need.

  8. 2

    At Loophole we always build our frontend first. Like the video, we always like to know what our users are going to see and understand how they're going to interact with our features.

    We'll usually mock up a hard-coded API and then use that data to test our frontend. Once we know what the end user experience should be we can start building the piping to make it happen. Obviously we have to go back and make changes but at the end of the day it only matters that your end users have a good experience. If it takes a couple extra lines of code to make that happen, so be it.

  9. 2

    This is absolutely the right approach if you are building an app for humans. If you are building API only products, then that is different. I have been a backend engineer for the first 10 years, then shifted to being frontend-first full-stack engineer.

    I still am not good at UI itself and trying to put more time into it. But I work on very high level when working with a team, so there is always someone with focus on UI. As a solo founder I build quick React mockup with mock JSON. Once a couple screens of user interaction are clear, then I go into the backend.

  10. 2

    Because the frontend is what users interact with, it probably makes good sense to start here. Think "what" rather than "how" in the first place. What value do you bring to your users? When the "what" is clear, start building a usable feature, not too big, so you can learn along the way while bringing some value. Expose that work to real users, gather feedback, iterate...

  11. 2

    I usually take the skateboard - bike - car approach to the stack as well as the product. Build and ship little end to end slices of value that work, iterate, profit. Well I'm working on the profit bit...

    1. 1

      Well I'm working on the profit bit...


  12. 2

    It depends on the focus of the application.

    For Podcast Ping, I started with the backend. For me it made sense to figure out how to build all the uptime checks/monitors I needed for the application, this is the core of the application.

    For PodcastHostingReview, I started with the FE because it's mostly a user focused application, so focusing on the user flow, and what they see made more sense.

    So yeah I've done it both ways, often I think about what is harder or just more interesting and start with that.

  13. 2

    I absolutely hate starting on the front end. Multiple reasons for this, but first and foremost is that I tend to design more than I'm actually capable of developing on the backend within a reasonable time frame. This is essentially exactly the same issue I have when developing backend first.

    In the meantime I tried finding a middle ground. The difficulty here is that I despise things I call 'context switches'. Just switching between the two projects gets me out of my flow. Could probably be solved by switching to a stack such as Ruby on Rails, but then I'd be missing out on much goodness I'm already familiar with.

    The approach I'm currently using is that I develop a minimum amount of functionality in the backend to get started on the frontend, and go on from there trying to integrate the context switches within my development flow. As that requires me to run my whole project all at once there is another looming problem, which is 'yak shaving'. When I'm running my whole project at once it means there are about 10 different (and beefy) services running at the same time. Basically it requires me to wear the developer, operations, and designer hats all at once, which is tiring. Additionally, sometimes you'd simply sink into a devops hole to fix stuff while you only intended to do a little design work.

    The best approach against this all is to ship a little but often. A weekly release cycle at most makes it that you know you can rely on your tech stack, which makes it easier to focus on only a little area at a time.

    Regardless of this all I consider back end development to be an area where it pays off not to cut corners. On a previous job I have worked myself into a hole by trying to keep up with outside demands, heavily cutting corners. Nowadays I do not really mind if I spend several weeks on a backend iteration, knowing it will save me an enormous amount of time in the nearby future. Quality is key to staying somewhat sane in this all.

  14. 1
    • Creating a mockup in Figma first helps to reduce time on tweaking things on the front-end side
    • Developing both front-end and API ensures that every new commit / PR has a working incremental update, yet you avoid implementing stuff upfront on the API, just the bare minimum in order to implement the next feature or fix a bug
    • Implementing API with GraphQL helps to avoid refactorings as much as possible yet ensure that there is a minimum set of exposed "endpoints" (GraphQL fields) that can be used universally for different UI screens

    See Node.js / GraphQL starter kit:

  15. 1

    Frontend is even worse.

Recommended Posts