[deleted]
Build Software from Front-to-Back
61–70 of 108 posts
Re: Build Software from Front-to-Back
#62In my experience, the only reliable way to design an API is to cycle through "hats" like gradient descent until the API stops changing. There are no shortcuts! And there are more hats to consider than just frontend and backend. There's security, testability, teachability, performance, upgradability, there are likely many uses for the API, and more. This is why API design is hard.
Re: Build Software from Front-to-Back
#63I would disagree, having been on both sides of this half a dozen times each. When you write front-to-back, you don't get an immediate sense of what the deeper relationships and nuances of your data models are going to look like. You're designing for what you immediately think you want to see. This approach can work well, until you run into things that end up being a lot more difficult to implement behind-the-scenes t…
Having TL'ed both Frontend and Backend at Google, I don't think it's front first or back first. It's "contract first", and here is why: - Assuming PRD and UX are ready. The Frontend team take a look and come up with the Frontend data model they want. The focus is on making sure it's easiest for them to maintain and develop the client side. - The Backend team take a look and come up with the Storage data model that is…
Favorited.
Also, I thought "aip.dev" might be a typo but that's also a helpful resource.
Thanks for sharing! :)
Re: Build Software from Front-to-Back
#64I'm going to disagree with both approaches, and suggest (for lack of a better term) "middle-out". Always define the API first . Figure out the information necessary, and make sure it meets both front-end constraints (e.g. no information is missing, does it need to be one call or multiple calls, etc.) and back-end constraints (can this be efficient to retrieve from the database, does one server have all the info, etc)…
IMO backend constraints are usually less stringent than the frontend part. Mocking the front first avoids a lot of designing round trips I think. For instance if on the frontend you need to display an infinite list of items, how you get your data can be heavily influenced by your interface. If you plan on having a super fast scroll with the user flying through the items, you might want to do it differently than for a…
Front (prototype) -> middle -> out
Re: Build Software from Front-to-Back
#65The other reason to design front end first is that the client mostly cares about that.
Plenty of projects I have worked on will sacrifice anything to have a frontend match a drawing. A friend currently works on a project where finding the purchase button requires you to scroll two inches in a widget where they hid the scroll bar to see the purchase button on a standard 15 inch laptop (as the mockup was built on a wide monitor).
On my current project, if there is so much as a semi-colon out of place, communications will see it. Forget a background process? Nobody notices that.
Re: Build Software from Front-to-Back
#66I'm going to disagree with both approaches, and suggest (for lack of a better term) "middle-out". Always define the API first . Figure out the information necessary, and make sure it meets both front-end constraints (e.g. no information is missing, does it need to be one call or multiple calls, etc.) and back-end constraints (can this be efficient to retrieve from the database, does one server have all the info, etc)…
The change I'd make here is around "locking down" the API design.
One of the biggest benefit of starting with the API is that both the backend and frontend devs can start playing with that contract, and discovering the nitty-gritty ways where it's less ideal than you'd hoped when you designed it pre-code.
So you get to pressure test it, and iterate on it, from both sides, instead of just from one of them.
Re: Build Software from Front-to-Back
#67I'm going to disagree with both approaches, and suggest (for lack of a better term) "middle-out". Always define the API first . Figure out the information necessary, and make sure it meets both front-end constraints (e.g. no information is missing, does it need to be one call or multiple calls, etc.) and back-end constraints (can this be efficient to retrieve from the database, does one server have all the info, etc)…
> Always define the API first
Impossible. What will the API serve? A list of horses? Wouldn't work if the user needs a mortgage calculator. There is no choice but to define the front-end first. The question is whether it's defined nebulously or with thought - it's rare for thoughtlessness to be the optimal strategy.
Re: Build Software from Front-to-Back
#68I would disagree, having been on both sides of this half a dozen times each. When you write front-to-back, you don't get an immediate sense of what the deeper relationships and nuances of your data models are going to look like. You're designing for what you immediately think you want to see. This approach can work well, until you run into things that end up being a lot more difficult to implement behind-the-scenes t…
Having TL'ed both Frontend and Backend at Google, I don't think it's front first or back first. It's "contract first", and here is why: - Assuming PRD and UX are ready. The Frontend team take a look and come up with the Frontend data model they want. The focus is on making sure it's easiest for them to maintain and develop the client side. - The Backend team take a look and come up with the Storage data model that is…
> Then both teams meet to negotiate the "Contract"
What you describe is pretty much front-end first with the tweak that when the teams negotiate, the burden of proof lies on the back-end. The back-end should contort as much as possible to satisfy the needs of the front-end, allowing it to remain as clean and nimble as possible. Only when it matters should the back-end be able to materially affect the shape of the api. In most cases "mattering" means balancing the needs of this front-end with another that also consumes the back-end.
Re: Build Software from Front-to-Back
#69I'm going to disagree with both approaches, and suggest (for lack of a better term) "middle-out". Always define the API first . Figure out the information necessary, and make sure it meets both front-end constraints (e.g. no information is missing, does it need to be one call or multiple calls, etc.) and back-end constraints (can this be efficient to retrieve from the database, does one server have all the info, etc)…
Ugh, last time I worked on a project that did this the API ended up designed by "an architect" to provide data that the back end didn't have and the front end didn't want. It was an unmitigated disaster.
Outside in drives a much more effective requirements discussion as you work your way down the stack. If the front end asks for data that's "too complex to retrieve" then that's usually obvious from the mock up and it is cheaper to change it at that point before code lower down the stack has been written.
It leads to much cleaner API design and better negotiations about what should go where since the written code of the layer above effectively drives the requirements for the layer below.
Re: Build Software from Front-to-Back
#70I'm going to disagree with both approaches, and suggest (for lack of a better term) "middle-out". Always define the API first . Figure out the information necessary, and make sure it meets both front-end constraints (e.g. no information is missing, does it need to be one call or multiple calls, etc.) and back-end constraints (can this be efficient to retrieve from the database, does one server have all the info, etc)…
> Always define the API first Impossible. What will the API serve? A list of horses? Wouldn't work if the user needs a mortgage calculator. There is no choice but to define the front-end first. The question is whether it's defined nebulously or with thought - it's rare for thoughtlessness to be the optimal strategy.
For backend engineers who have trouble understanding that the front end is what all the work is in service of, tell them that the frontend us the Tests for their Test Driven Design.
I say this as a backend engineer. The backend genius shines when we figure out how to serve the frontend efficiently (low compute cost) and adapt to rapidly changing frontend requirements without delaying releases.