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

101–108 of 108 posts

Re: Build Software from Front-to-Back

#101

Post by EGreg »

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…

You’re both right.

The data model is the thing that stays more invariant in an app, and you can start with that:

https://github.com/Qbix/architecture/wiki/Internet-2.0

But a centralized database is not the future. Client-first web apps are:

https://qbix.com/blog/2020/01/02/the-case-for-building-clien...

So your data will be stored client-side and synced, with Dat or MaidSAFE or IPFS etc.

Re: Build Software from Front-to-Back

#102

Post by stepbeek »

crdrost wrote: post #41

Oh man, Stephen, you're gonna get a lot of conflicting views on this one, posting it here. :) For what it's worth I am on your side given a bunch of constraints that match my prior experience. So I have typically worked on small scrappy IT teams at companies that are working on something else -- whether maintaining a Roku channel or putting together the heating ducts and plumbing assemblies for a building or making s…

Hey thanks for the in-depth feedback/discussion! I've definitely fallen prey to the anti-pattern you lay out here. And it's super hard to not fall in to a kind of sunk-cost fallacy where you begin to limp along until eventually giving in and - as you mention - throw it out to build with a better understanding of the domain.

> nice REST principle which you may wish to emulate if you can, called HATEOAS. If you can do it, it makes things so much simpler. The basic idea about HATEOAS is the exact inversion of what you are saying: a polymorphic frontend

Huh. I'd never really thought of HATEOAS in this way. I've used it before to build an API that can be consumed by another service in a flexible way, but have never really reached for it when building a UI. I guess this would solve the problem by only guaranteeing relationships rather than guaranteeing the full API?

This would definitely protect against churn when the structure of the URL's change, but doesn't this still depend on having a solid understanding of the domain from the get-go?

Re: Build Software from Front-to-Back

#103

Post by corebit »

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

Yup! And reference Ivar Jacobson's OOSE: Use Case Driven Approach for just how long of a history this successful approach has had.

Re: Build Software from Front-to-Back

#104

Post by corebit »

golemiprague wrote: post #59
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)…

In most cases API comes last, after the data and UI. This is just the state of things unless you intentionally building an api service from scratch. Data stays forever and in many times serves more than one application, UI changes all the time and might connect to more than one data source. API is the decoupling between those two and in most cases dictated by both, not the other way round.

No, the data is always coupled to how it is intended to be processed and useless otherwise. Integration is always a giant headache on projects that don't capture intent clearly with a good API.

Re: Build Software from Front-to-Back

#105

Post by crdrost »

stepbeek wrote: post #102
crdrost wrote: post #41

Oh man, Stephen, you're gonna get a lot of conflicting views on this one, posting it here. :) For what it's worth I am on your side given a bunch of constraints that match my prior experience. So I have typically worked on small scrappy IT teams at companies that are working on something else -- whether maintaining a Roku channel or putting together the heating ducts and plumbing assemblies for a building or making s…

Hey thanks for the in-depth feedback/discussion! I've definitely fallen prey to the anti-pattern you lay out here. And it's super hard to not fall in to a kind of sunk-cost fallacy where you begin to limp along until eventually giving in and - as you mention - throw it out to build with a better understanding of the domain. > nice REST principle which you may wish to emulate if you can, called HATEOAS. If you can do…

Look at it a different way: why is our domain model hard to change?

Is it, I suspect, mostly because we failed DRY and repeated ourselves at the various layers? (i.e. our domain model is echoed in our DB, Redis cache, API structure, App structure, stylesheets...)

If that's the core problem, it's solvable two ways... an app with no backend, or a front-end that is fully generic serving up a backend that calls the domain model shots.

Re: Build Software from Front-to-Back

#106

Post by crazygringo »

chii wrote: post #91
crazygringo wrote: post #76

Earlier quoted context omitted.

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

Obviously this is a complex topic but this applies equally well to agile as well as waterfall.

If you're planning your sprint, the point is to figure out the API call first together, before work starts on either front end or back end.

Real-world projects exist on a wide continuum between "maximum agile" and "maximum waterfall", and usually fall somewhere in between. You can't build AWS or Google Search purely out of 2-week sprints with no further advance planning or specification. :P

Re: Build Software from Front-to-Back

#107

Post by nohuhu »

jcadam wrote: post #43

As a "full-stack" developer who started out on the backend and took on front-end work later in my career, I used to build back-to-front. You generally end up with a cleaner, more scalable, and stable solution. That nobody wants. I've learned this lesson the hard way. Start with the UX and work your way backwards. I don't like it from an engineering perspective, but it's the only way to go to build products. Users jus…

> it's the only way to go to build products.

This! Back-to-front is a good way to build a scalable, performant, cleanly designed software. Front-to-back is the only viable way to build a usable product.

> Users just do not care what kind of horrible kludge is running behind the slick UI.

For 99.9(9)% of users, the UI is the product. Even those who do know what "back end" means, do not care.

Re: Build Software from Front-to-Back

#108

Post by dwaltrip »

UglyToad wrote: post #97
dwaltrip wrote: post #80

Earlier quoted context omitted.

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

That makes sense. Thanks for the response. It seems like some people in this comment section are coming from your perspective, where the feature has been somewhat defined already, while others are talking about the entire process from the initial idea or problem to working software.

I definitely agree that when possible it is very useful to enforce important constraints in the database.

Post reply on HN