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

31–40 of 108 posts

Re: Build Software from Front-to-Back

#31

Post by marcosdumay »

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…

That's also my way.

First design the data. This will tell you how this part of the solution integrates with what everybody else is doing, and will make very obvious some problems that otherwise you may only discover after the system is mature into usage.

Then design the UX and users processes. Programmers get to design only half of those, but both have to be set at the same time.

Then you can do everything else.

And yes, letting an ORM dictate migrations guides people into a completely wrong sequence.

Re: Build Software from Front-to-Back

#32

Post by gavinray »

travisjungroth wrote: post #27
stepbeek wrote: post #17

Earlier quoted context omitted.

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

This, pretty much. If you don't have one person with a clear understanding of the backing domain/model of the problem, you're going to be in for a lot of hurt. The person doesn't have to be technical, as long as they understand the business area then you just sit with them and ask them to describe things, while you translate that in your head/on paper to data models.

Almost nothing else about an application matters besides your data models. The UI and other niceties are just a (very replaceable) skin around CRUD-And-CRUD-Accessories on data models. If you screw those up, you have a nice looking, useless theme. Which is pretty ironic given how much disproportionate value non-technical businesspeople place on the UI of things because they can see it/interact with it.

(Not that the UI isn't massively important, but you can still interact with an API minus a frontend. The opposite scenario gives you nice-looking pictures.)

Re: Build Software from Front-to-Back

#33

Post by bdcravens »

UglyToad wrote: post #22
winrid wrote: post #21

Earlier quoted context omitted.

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?

A schema is just a definition and a set of constraints; in a "schemaless" database, you implement the schema in your application.

Re: Build Software from Front-to-Back

#34

Post by bdcravens »

agentultra wrote: post #26

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

In REST, the API is the front-end. You can still do the front-to-back approach, mocking the data etc until you get the interface right. Then you work on how the application delivers data to the interface, which is the backend.

Re: Build Software from Front-to-Back

#35

Post by travisjungroth »

gavinray wrote: post #32
travisjungroth wrote: post #27

Earlier quoted context omitted.

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.

This, pretty much. If you don't have one person with a clear understanding of the backing domain/model of the problem, you're going to be in for a lot of hurt. The person doesn't have to be technical, as long as they understand the business area then you just sit with them and ask them to describe things, while you translate that in your head/on paper to data models. Almost nothing else about an application matters b…

You can also be in a lot of hurt even if you have that person. I've seen a domain expert brought onto teams three times, and they were never of any real help. Those products have either struggled or died btw, so I think it says more about the team than the experts.

Re: Build Software from Front-to-Back

#36

Post by jimbokun »

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?

If you don't have a domain expert, you should stop everything until you either get one or become one.

Re: Build Software from Front-to-Back

#38

Post by DEADB17 »

BrainlingPdx wrote: post #6

Not trying to be mean, but you really don't make any sort of case for doing this here. You just note you did it because you've become more comfortable with the front end. It also seems like you're designing and implementing an entire system by yourself in which case you can do whatever you want. When dealing with a team, and an API layer that has to be used by more than just your client, I don't see any compelling ca…

The techniques are not mutually exclusive, it depends on the context. When you don't have a clear idea of the requirements starting "front to back" helps to understand and gather them while building something that validates them. For your example "back to front" sounds like a better fit.

Re: Build Software from Front-to-Back

#39

Post by agentultra »

bdcravens wrote: post #34
agentultra wrote: post #26

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

In REST, the API is the front-end. You can still do the front-to-back approach, mocking the data etc until you get the interface right. Then you work on how the application delivers data to the interface, which is the backend.

If you are designing a REST interface then I recommend a domain driven design approach. I've had a fair bit of success with that.

I also like to think in terms of denotational semantics which works rather well with REST APIs. The entities represent the domain objects which model what the system does. The state transfer operations become the game between the client and the system. If the domain maps cleanly the client and the server never have to guess or assume the state of the other. You can follow the operations from the URLs (HATEOS, etc).

What I find happens to some systems where the design is driven by the UI are domain models that span both the client and the server. This leads to routes that fill data for specific UIs, entities that have different representations based on which route they're fetched from, and the dreaded "RPC over HTTP," that the OP seems aware of.

A lot of this can be avoided if you never intend to expose your REST API to external developers. Just don't have one. Less to worry about.

Designing front-to-back that way makes a lot of sense. I just find that if you do that from a UI through a REST API that a lot of teams and developers skip on maintaining the REST conventions and then end up sad when their project becomes difficult to maintain and onboard new developers to.

Re: Build Software from Front-to-Back

#40

Post by cellularmitosis »

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…

+1 :)

"For example, I previously tended to use a bottom-up approach to development. However, SICP showed me the benefits of what it calls "wishful thinking" with a more top-down approach."

https://news.ycombinator.com/item?id=13920125

Post reply on HN