Build Software from Front-to-Back
happyvalley.dev
Build Software from Front-to-Back
1–10 of 108 posts
Re: Build Software from Front-to-Back
#2I'm a back-end dev who's transitioned to being more full stack in the last couple of years. I've written a little bit here on a workflow that I kind of fell into that I've corrected recently and figured it might be useful for other people in the same boat.
Re: Build Software from Front-to-Back
#3That’s what is usually called “top-down programming”, right?
Re: Build Software from Front-to-Back
#4I agree with this article. There are many developers who think of the database schema first especially in ORM heavy frameworks like rails. Also because of this a lot of people confuse data modeling with the database schema.
Re: Build Software from Front-to-Back
#5I think going in either direction is gonna have flaws. Sometimes frontend informs the backend (rich user flow -> data dependencies) and sometimes backend informs the frontend (often suggesting more composable and maintainable designs)
I've worked on projects that were very front-to-back and without having a constant eye towards the backend, the UI requirements would have ended up dictating a non-composable, non-extensible backend. But I guess applying taste and knowledge to these problems is kind of the point of being "full stack"
Re: Build Software from Front-to-Back
#6Not trying to be mean, but you really don't make any sort of case for doing this here. You just note you did it because you've become more comfortable with the front end. It also seems like you're designing and implementing an entire system by yourself in which case you can do whatever you want. When dealing with a team, and an API layer that has to be used by more than just your client, I don't see any compelling case presented here to start designing API's specifically for UX use cases.
Re: Build Software from Front-to-Back
#7I always write "front-to-back". I write the code that uses a module, abstraction, api, etc. Then I write that layer until the code works. This goes on layer to layer.
To make it not become a tour-de-force, I start with a golden path, then various aspects (validation, additional operations on data besides rendering, etc). If the data doesn't exist yet, it's mocked. Then later, it's implemented (or made 'live') according to the mocked "schema".
It's not exactly TDD (I rarely write a test except for integration tests or the occasional "let's make sure it's not off-by-one"). It's not top down either, exactly. Perhaps you could call it "needs driven development" or "user driven development". You need it from the start and you use it as soon as possible. From then on, it's just improvements.
If you work back-to-front, you won't have anything working until late in the game. You're constantly imagining all the non-consequential "what-ifs".
But in a way, front-to-back is like TDD except you're not testing via unit tests. You're testing by using. And you will be using it so much that it will be tested thoroughly. You iterate continuously while the top layer / front end keeps working.
Sure, there can be an overarching design. There can be an architecture. There should be. But after that, it's about slowly molding the system towards that design. If you have understood the design, you know when you're veering off course. For sure, it's not like building a bridge.
Re: Build Software from Front-to-Back
#8I think the issue here is that there's a sole developer working on the whole app with the difficult choice of choosing where to start. I think that creating a design that covers most test cases of the app would then let you start from either section of the app.
I am surprised OP doesn't mention anything around GraphQL (why or why not it could help).
Re: Build Software from Front-to-Back
#9I think going in either direction is gonna have flaws. Sometimes frontend informs the backend (rich user flow -> data dependencies) and sometimes backend informs the frontend (often suggesting more composable and maintainable designs) I've worked on projects that were very front-to-back and without having a constant eye towards the backend, the UI requirements would have ended up dictating a non-composable, non-exten…
The risks of building the frontend first take several forms. There is the eternal problem of the strategy people not understanding that the code can look like it works but not actually work.
And the risk of using mock data to populate a UI (to build it without any backend) is that we don't have good tools for tracking all of the places that we are still using mock data. This can lead to blind spots that make estimating delivery schedules very difficult. Because you may discover late in the process that some corner cases are still using fake data. And, it's a miserable way to work, trying to push through to a milestone when you have no idea how much further you have to go.
Re: Build Software from Front-to-Back
#10It's what I call customer experience design. You can build this in terms of user stories, UI mocks, OpenAPI spec etc depending on your customer. This makes the expectations from the API interface very clear. Of course, it may also mean that I'd have to deviate from pure REST but that's easy when you see the customer value. Then the tradeoff between fast, easy and cheap is restricted to components that don't impact the end user and can be changed later. The last thing I'd want is to change my customer's workflow because my entity relationships change.