5 ms·

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

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 than the data you just expect to appear on the page in front of you. 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. For more complex systems, there are things that need to be ironed out in their entirety and have their modeling/relationships, and functionality proven on the API side of things before you decide to start writing UI elements for them. On the flipside, having worked on projects where there have been major, multi-month setbacks, it was nearly always because the models/domain weren't well thought out and it needed major components to be re-worked (either UI or backend) before we could proceed.

stepbeek 6y ago
> doing a walkthrough of the domain Any advice on how to do this without a domain expert to hand?
- travisjungroth 6y ago
  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.
  - gavinray 6y ago
    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.)
    - travisjungroth 6y ago
      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.
- jimbokun 6y ago
  If you don't have a domain expert, you should stop everything until you either get one or become one.
exacube 6y ago
> 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 like you're suggesting roughly what the article is saying -- figure out the front-end and then implement the backend. what is the diff between what this article is saying and what you're saying?
- gavinray 6y ago
  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.
thanhhaimai 6y ago
Having TL'ed both Frontend and Backend at Google, I don't think it's front first or back first. It's "contract first", and here is why: - Assuming PRD and UX are ready. The Frontend team take a look and come up with the Frontend data model they want. The focus is on making sure it's easiest for them to maintain and develop the client side. - The Backend team take a look and come up with the Storage data model that is flexible enough for short term future. The Backend should anticipate the growth of the product and try not to be put in a situation where they have to redesign the database/infrastructure. - Then both teams meet to negotiate the "Contract", which is the API layer. In some case, the API is more similar to the Frontend data model. In some case, the API is more similar to the Storage data model. In other case, there is a translation layer between Storage <-> API <-> Frontend (not as desirable, but not the end of the world). There are standard on how API should be designed (https://aip.dev/ https://aip.dev/). - When the contract is established, both teams can run more independently to each other, release at different times, and only needs to sync when there is a need for the contract to change. The API is designed to be easily extended, but not changed or deleted. The Backend team doesn't care if the Frontend data model exists. The Frontend team doesn't care what kind of Storage the Backend uses. It's an abstraction. The complexity of the project can't be entirely eliminated. A good TL makes explainable trade offs on which parts of the system bear the complexity. It's their job to think not only about the architecture, but also how the development can be sustained in the future. This is especially true when the product is developed by a medium-large team. The focus is no longer on having the leanest/optimal code base. The focus is on making sure many parts of the system can move more independently, in parallel, and that it's scale-able to the growing business needs. It's a classic case of Amdahl's Law applicable to real life. Of course, this is not always applicable to small projects that is never intended to have more than a couple engineers. Even then, when I work on solo full stack projects, I still unconsciously do this contract first approach.
- chrisweekly 6y ago
  Favorited. Also, I thought "aip.dev" might be a typo but that's also a helpful resource. Thanks for sharing! :)
- thinkloop 6y ago

stepbeek 6y ago

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

travisjungroth 6y ago
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.
- gavinray 6y ago
  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.)
  - travisjungroth 6y ago
    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.
jimbokun 6y ago
If you don't have a domain expert, you should stop everything until you either get one or become one.

exacube 6y ago

> 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 like you're suggesting roughly what the article is saying -- figure out the front-end and then implement the backend. what is the diff between what this article is saying and what you're saying?

gavinray 6y ago
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.

thanhhaimai 6y ago

Having TL'ed both Frontend and Backend at Google, I don't think it's front first or back first. It's "contract first", and here is why: - Assuming PRD and UX are ready. The Frontend team take a look and come up with the Frontend data model they want. The focus is on making sure it's easiest for them to maintain and develop the client side. - The Backend team take a look and come up with the Storage data model that is flexible enough for short term future. The Backend should anticipate the growth of the product and try not to be put in a situation where they have to redesign the database/infrastructure. - Then both teams meet to negotiate the "Contract", which is the API layer. In some case, the API is more similar to the Frontend data model. In some case, the API is more similar to the Storage data model. In other case, there is a translation layer between Storage <-> API <-> Frontend (not as desirable, but not the end of the world). There are standard on how API should be designed (https://aip.dev/ https://aip.dev/). - When the contract is established, both teams can run more independently to each other, release at different times, and only needs to sync when there is a need for the contract to change. The API is designed to be easily extended, but not changed or deleted. The Backend team doesn't care if the Frontend data model exists. The Frontend team doesn't care what kind of Storage the Backend uses. It's an abstraction. The complexity of the project can't be entirely eliminated. A good TL makes explainable trade offs on which parts of the system bear the complexity. It's their job to think not only about the architecture, but also how the development can be sustained in the future. This is especially true when the product is developed by a medium-large team. The focus is no longer on having the leanest/optimal code base. The focus is on making sure many parts of the system can move more independently, in parallel, and that it's scale-able to the growing business needs. It's a classic case of Amdahl's Law applicable to real life. Of course, this is not always applicable to small projects that is never intended to have more than a couple engineers. Even then, when I work on solo full stack projects, I still unconsciously do this contract first approach.

chrisweekly 6y ago
Favorited. Also, I thought "aip.dev" might be a typo but that's also a helpful resource. Thanks for sharing! :)
thinkloop 6y ago