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

21–30 of 108 posts

Re: Build Software from Front-to-Back

#21

Post by winrid »

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 would (should?) have a well defined schema with MongoDB. I know some people see this as one of the values of it, but personally it's not why I use it.

Re: Build Software from Front-to-Back

#22

Post by UglyToad »

winrid wrote: post #21
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 would (should?) have a well defined schema with MongoDB. I know some people see this as one of the values of it, but personally it's not why I use it.

If I understand it correctly this was a newer feature, from what I remember when it was first released it was schemaless?

Re: Build Software from Front-to-Back

#23

Post by MattyRad »

Not only does this approach help you determine what the backend actually needs to do/acquire, it has the added bonus of getting product teams to iron out critical business logic (which masquerades itself as the frontend) while you transition to backend work.

This is a huge timesaver, because if product decides to change the frontend, you haven't committed huge resources to the backend. Building software front-to-back helps people agree on what needs to get built.

Re: Build Software from Front-to-Back

#24

Post by pjettter »

stepbeek wrote: post #20
pjettter wrote: post #7

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

I love user-driven design as phrasing. Although I neglected to mention it, I quite often write basic cypress [1] tests early on to get a TDD-like experience. > For sure, it's not like building a bridge. It's super interesting how many processes are inherited from traditional engineering. [1] https://www.cypress.io/

Hm. Maybe. In my experience, tests is just more code, more bugs, more maintenance. If you need to write many tests, you're writing your code wrong. "Just my opinion, man" ;)

Re: Build Software from Front-to-Back

#25

Post by chasing »

Okay, but this is one of those "I've discovered I can work like this" sort of posts that doesn't take into account the vast range of projects and project teams.

So, sure: It's useful to be aware that you can work front-to-back, back-to-front, front-and-back-to-middle, etc. But you still can't make this choice without consideration and one size absolutely does not fit all.

Re: Build Software from Front-to-Back

#26

Post by agentultra »

I would be careful: if you're designing a REST API to be consumed by other developers and applications there are conventions and patterns you should stick to.

If your product or service doesn't exist without the UI then why bother with a REST API at all? Write a nice stateful application that is rendered server side. There are great frameworks for this in almost every language.

A good REST API is consumed by applications and developers and they expect you to stick to the conventions or they will turn to another provider if they can.

Re: Build Software from Front-to-Back

#27

Post by travisjungroth »

stepbeek wrote: post #17
gavinray wrote: post #11

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

> doing a walkthrough of the domain Any advice on how to do this without a domain expert to hand?

Somehow the domain has to get into the head of the person doing the modeling. If you're already a domain expert, then it's already there. If you have one next to you, this can happen through conversation. If you don't have an expert with you, you have to load it into your head yourself.

Books, videos, and watching people work are all good. You could also learn to do the thing yourself, if that's possible.

Re: Build Software from Front-to-Back

#28

Post by travisjungroth »

pjettter wrote: post #7

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

You can get something similar with back-to-front. You don't have to spend your time imagining.

With front-to-back, you mock out data. With back-to-front, you mock out interfaces. This is how I write Django projects. I write models, which I can start using right away. Sure it's in the REPL, tests, or admin pages. But I'm using real functionality with real data from the very beginning. Then the custom views and templates get added on top.

Re: Build Software from Front-to-Back

#29

Post by gavinray »

exacube wrote: post #18
gavinray wrote: post #11

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

> Personal experience/preference, but the thing that has (almost) never led me wrong was doing a walkthrough of the domain of the application, and then thinking about what the client-side pages and functionality are going to look like (page-by-page, user stories), and then implementing the backend. Finally, wire up the backend to the frontend mockups/design. I'm not totally clear on what you disagree with. it seems l…

Not actually sinking any time into designing and developing a UI before you've walked through it all on a whiteboard, from the perspective of what sort of models and infrastructure are needed to support the featuresets.

Here's an example: Recurring events.

Sounds simple, right? Well, that's what I thought too, until I spent two months learning about what the "rrule" and "rruleset" RFC specs are, and how nightmarishly complex it is to implement a mixture of single and recurring events with granular CRUD and associated records.

You need to allow updating or deleting all recurring events from a master record, or just a single instance of the recurring event, and to be able to attach DB records to specific virtually-generated dates of the recurrence pattern (this one was hell, since databases don't allow foreign-keys on views). Even had to submit a PR for a Postgres library for parsing rrule's to add the proper support that we needed.

In retrospect what should have happened was try to alter the business requirements so that the functionality was slightly different, but you'd never have known that if you go front-to-back.

Re: Build Software from Front-to-Back

#30

Post by stepbeek »

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 agree on the schema being the source of canonical truth. I also agree on ORMs - we use jdbi mainly. But I find it hard to reason about everything up front. There are generally too many unknown unknowns that emerge when the feature is more fully fledged out.
Post reply on HN