After my first contact with a computer in the 1980's, I taught myself to program in BASIC and Z80 assembler. I went on to study Computer Science and have enjoyed a long career in Software Engineering.
Viktoria,
This is a good questions but there is another answer - inside-out. I have found it very important to define the interface between front and back as early as possible.. This enables both sides of the stack to commence development in parallel with a high degree of confidence (even if it evolves, in a controlled manner, later.) If there is a single developer (as suggested by your article) features can be developers incrementally front and back.
I love this approach. I can imagine this approach is a basic concept inside a team at a company. Yes my article is mostly in the a view of a single developer. But I am curious how it actually works as a team.
After my first contact with a computer in the 1980's, I taught myself to program in BASIC and Z80 assembler. I went on to study Computer Science and have enjoyed a long career in Software Engineering.
Viktoria,
When working in a team having a common understanding (not assumptions) of how components (front and back) need to communicate and work together is vital. I would like to stress the interface definition is 'controlled' not fixed. As implementation progresses (especially in an agile project) the interface is bound to evolve. "Control" means the interface changes through the mutual agreement of both sides and not independently - that way lies chaos.
After my first contact with a computer in the 1980's, I taught myself to program in BASIC and Z80 assembler. I went on to study Computer Science and have enjoyed a long career in Software Engineering.
Koire, API-first works for me but that suggests (in my mind) some initial implementation. My thinking was to capture the interface definition (between front and back = API) as a specification. Words are easier to change (discuss and evolve) than code and tests. But as I stated earlier, you are not wrong, API-first will still enable front- and back-end development to commence independently, and enable the delivery of one feature at a time end-to-end.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Viktoria,
This is a good questions but there is another answer - inside-out. I have found it very important to define the interface between front and back as early as possible.. This enables both sides of the stack to commence development in parallel with a high degree of confidence (even if it evolves, in a controlled manner, later.) If there is a single developer (as suggested by your article) features can be developers incrementally front and back.
I love this approach. I can imagine this approach is a basic concept inside a team at a company. Yes my article is mostly in the a view of a single developer. But I am curious how it actually works as a team.
Viktoria,
When working in a team having a common understanding (not assumptions) of how components (front and back) need to communicate and work together is vital. I would like to stress the interface definition is 'controlled' not fixed. As implementation progresses (especially in an agile project) the interface is bound to evolve. "Control" means the interface changes through the mutual agreement of both sides and not independently - that way lies chaos.
I didn't scroll down enough, you call it inside out I call it API first.
Getting the interface between front and back established can save you so much later.
Koire, API-first works for me but that suggests (in my mind) some initial implementation. My thinking was to capture the interface definition (between front and back = API) as a specification. Words are easier to change (discuss and evolve) than code and tests. But as I stated earlier, you are not wrong, API-first will still enable front- and back-end development to commence independently, and enable the delivery of one feature at a time end-to-end.