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

91–100 of 108 posts

Re: Build Software from Front-to-Back

#91

Post by chii »

crazygringo wrote: post #76
pydry wrote: post #69

Earlier quoted context omitted.

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…

> 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

that's because this methodology is called waterfall, and it has proven to not work, time and time again.

The project should not start with full requirements - it should start with a single requirement/feature (even if that feature by itself doesn't fullfil the purpose of the software). What is the topmost important feature? Do that part first, and have it working end to end. It should take as little time, and done as fast as possible. It should allow the design team to create as simplified a design as possible, and allow the backend to use as simplified a backend as possible. It should allow testing to be done well (good coverage, good unit testing etc).

Then once this is done, the client will judge it, and say what can be improved. Do that one improvement, only, before going back to the client and repeat.

This has been what most successful projects done.

Re: Build Software from Front-to-Back

#92

Post by unclebucknasty »

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)…

>Figure out the information necessary, and make sure it meets both front-end constraints

Seems to be a glaring contradiction. How would you know if it met front-end constraints if you haven't defined the front-end yet?

My experience is that front-end is king. It defines what the app must do. The API and back-end are the how. Obviously, you need the what before the how.

If you run into a constraint, then you figure out how to work around it, or what can be sacrificed while still having the front-end deliver the what.

Re: Build Software from Front-to-Back

#93

Post by aryehof »

How foreign the problem space is for me, and how focused much of the audience on HN seems to be on web/database software.

I'm involved with the two biggest types of software in general computing: control systems and large complex commercial transactional systems.

The former don't feature a UI or a database. While the latter have the primary issue of modeling a complex problem domain.

That complex model is by necessity produced without regard to any particular human or system interface, or data persistence. Are such concepts so alien to audiences here?

Re: Build Software from Front-to-Back

#94

Post by fioan89 »

Casey Muratori once made a similar point in https://caseymuratori.com/blog_0025.

Personally I think the approach is very similar to TDD and so for some of us it's easier to dive first on the front-end. It's like translating user specifications to tests and then writing the code for the tests to pass.

Re: Build Software from Front-to-Back

#95

Post by stepbeek »

skaber wrote: post #8

I 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).

> creating a design that covers most test cases of the app

I consider this be a very hard thing to accomplish. There are generally too many unknown unknowns. I almost always need exploratory work to figure things out.

Re: Build Software from Front-to-Back

#96

Post by UglyToad »

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.

There's no silver bullet I guess but I think the trap that one could fall into here is to think of "the" frontend. There's a bunch of additional consumers of the data model even for a single web-app. Auditing, security, reporting (prior to moving to a separate reporting database), internal tools, possible future mobile or desktop applications, etc. I have found the safest approach is to enforce invariants in the database rather than assume the application code will do the right thing. But as you highlight the schema can be refined by the needs of the front-end, especially where indexing is concerned.

Re: Build Software from Front-to-Back

#97

Post by UglyToad »

dwaltrip wrote: post #80
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.

Sure, I guess by first step I was referring to the first thing when I sit down to start coding.

There's all the stuff that comes before actually doing that, generally, though not always, the feature is driven by some front-end requirement and may have accompanying product specification and possibly even UX designs. But I try to take those and think about what the domain concept being addressed is, rather than the shape of the data the front-end requires. Almost always the front-end and requirements will change through iteration so I find that purely mapping the FE concepts directly to the data-structure is less robust than taking a step back and thinking about the actual data without consideration for the proposed front-end design. Though the front-end can still inform aspects of the database at this stage it should only provide minor optimizations to the schema through indexes or normalization choices.

I suppose in part it's taking a domain-driven design approach and making the first step encoding the domain in the database. It has been my experience that many headaches in applications I encounter could have been avoided if the constraints had been enforced against the data at the persistence level rather than assuming the application level code will handle it correctly.

Re: Build Software from Front-to-Back

#99

Post by pydry »

crazygringo wrote: post #76
pydry wrote: post #69

Earlier quoted context omitted.

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…

>Once you've verified that the API design works for the needs of both ends.

Which was easy to do in retrospect or half way through the task, but doing that verification step up front didn't work.

Re: Build Software from Front-to-Back

#100

Post by justanotherc »

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…

I tend to agree, and usually go straight for the schema when I start on a project, because the data structure is the model of the real world problem.

With regard to migrations though, I tend to disagree. Code is very easy to manage in version control, so the migration files are merely the data structure represented in code. I love migrations and they've vastly changed the way I work.

Post reply on HN