Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Build Software from Front-to-Back

happyvalley.dev

Post reply on HN
Print view View original

71–80 of 108 posts

Re: Build Software from Front-to-Back

#71

Post by lonelappde »

UglyToad wrote: post #19

Always interesting to read how others work. I'm a backend dev who does quite a bit of frontend though I deeply dislike the current state of frontend (bring back Webforms) For me it all starts with the database, always. Code, ux, network is all ephemeral. The schema, the invariants and the data are forever. (this is also why I think microservices are often the wrong approach, you're solving a code problem at the expen…

What goes in the database? The whole universe? What do you leave out? What do you denormalize and index? These questions are answered by the frontend.

Re: Build Software from Front-to-Back

#72

Post by disposedtrolley »

When I worked on full-stack projects, I'd always start by understanding what the frontend needed to display but not necessarily how, which translated well into a database schema and some type definitions.

I would then mock these out so I could start prototyping the rest of the frontend. This usually involved setting up UI components, pages, and linking them up with actions. The goal of the prototype was to demonstrate a few end-to-end (albeit mocked) flows to the user. With the flows and data types in place, it was trivial to design a set of API endpoints and build out the backend.

Re: Build Software from Front-to-Back

#73

Post by aaronschroeder »

UglyToad wrote: post #19

Always interesting to read how others work. I'm a backend dev who does quite a bit of frontend though I deeply dislike the current state of frontend (bring back Webforms) For me it all starts with the database, always. Code, ux, network is all ephemeral. The schema, the invariants and the data are forever. (this is also why I think microservices are often the wrong approach, you're solving a code problem at the expen…

100% agree, though a good ORM handling migrations can be nice as it documents how the schema has changed. Just be sure there is no schema logic that exists only in the ORM and not at the database layer itself.

Re: Build Software from Front-to-Back

#74

Post by ravenstine »

Just go with an approach that it's your talent stack.

For instance, if your product has a lot of UX nuances, and you aren't artistically inclined, it can make sense to build out the interface first, work out the UX, and then proceed to the backend from there. However, someone with the ability to build wireframes should probably do that first, work on the API, and come back to the frontend.

I'm good at backend stuff, but have a hard time keeping interest in a project I'd I spend all my time in the backend. The frontend keeps me interested because it's visual and helps me see what my goal is.

Re: Build Software from Front-to-Back

#76

Post by crazygringo »

pydry wrote: post #69
crazygringo wrote: post #44

I'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…

I'm not disagreeing with the architect part -- that's what I meant by "Once you've verified that the API design works for the needs of both ends".

An architect working in a vacuum is only going to result in unmitigated disaster in my experience. :)

But I disagree where you say that it's usually obvious from a mock-up that the backend is going to be too complex. In my experience that never occurs to people at all. All too often I've seen designers spend months mocking up fantasy functionality while the backend team is drawing up tables, shards and microservices, only for it to eventually collide in total incompatibility, when the front-end developers say "but the back end doesn't let us do three-quarters of this!" and the back-end developers say "but obviously you can't get the data that way, what ever made you think you could?"

Forcing the API conversation/specification to happen at the start, rather than in the middle, forces extreme clarity for both sides, so that necessary critical compromises are hashed out at the beginning, instead of discovering a horrible incompatible collision midway through.

Re: Build Software from Front-to-Back

#77

Post by wolco »

lonelappde wrote: post #71
UglyToad wrote: post #19

Always interesting to read how others work. I'm a backend dev who does quite a bit of frontend though I deeply dislike the current state of frontend (bring back Webforms) For me it all starts with the database, always. Code, ux, network is all ephemeral. The schema, the invariants and the data are forever. (this is also why I think microservices are often the wrong approach, you're solving a code problem at the expen…

What goes in the database? The whole universe? What do you leave out? What do you denormalize and index? These questions are answered by the frontend.

You store the entire universe or whatever reporting requirement demand. You define the database structure based on the requirements of your business logic.

The frontend requirements can help define what api's are required but if you treat your database as dumping tables you limit what your data can do.

You add can add and remove indexes at any point. If you made a bad decision or no decision you would add those when more information is available.

Re: Build Software from Front-to-Back

#78

Post by [deleted] »

UglyToad wrote: post #19

Always interesting to read how others work. I'm a backend dev who does quite a bit of frontend though I deeply dislike the current state of frontend (bring back Webforms) For me it all starts with the database, always. Code, ux, network is all ephemeral. The schema, the invariants and the data are forever. (this is also why I think microservices are often the wrong approach, you're solving a code problem at the expen…

[deleted]

Re: Build Software from Front-to-Back

#79

Post by thomk »

stock_toaster wrote: post #56
UglyToad wrote: post #19

Always interesting to read how others work. I'm a backend dev who does quite a bit of frontend though I deeply dislike the current state of frontend (bring back Webforms) For me it all starts with the database, always. Code, ux, network is all ephemeral. The schema, the invariants and the data are forever. (this is also why I think microservices are often the wrong approach, you're solving a code problem at the expen…

> For me it all starts with the database, always. I agree, though I generally reduce this question to, "what is the shape of my data?".

I was just thinking something like this as well. The best term for it is 'schema' but that moniker seems so, ill-fitting. For lack of a better term the 'schema' isn't really designed, it's discovered.

Thats how I know I'm on the right path. I start to organize the data and new things that appear fit naturally into what I've already discovered.

This is the epitome of organic design because you are simply the conduit between the truth and a schema definition. If you force yourself to not be clever and just interpret what you've found, your database model will be solid.

Re: Build Software from Front-to-Back

#80

Post by dwaltrip »

UglyToad wrote: post #19

Always interesting to read how others work. I'm a backend dev who does quite a bit of frontend though I deeply dislike the current state of frontend (bring back Webforms) For me it all starts with the database, always. Code, ux, network is all ephemeral. The schema, the invariants and the data are forever. (this is also why I think microservices are often the wrong approach, you're solving a code problem at the expen…

> Of course you need to know roughly what the data will be used for ...

Can you talk about how you figure this part out? As you imply, this seems like it is your actual first step, not designing the database.

Post reply on HN