First of I am a codenewbie so this article is my little experience with the topic and any advice and comments are highly appreciated!
I want to talk about how I feel to write a full stack project with some missing part.
Case nr.1 - Writing full stack project with limited back end knowledge
Yes, you read it right. I started a full stack project idea a few months ago without actually knowing back end. So obviously I started to build a front end part up. Here I dont mean just the design and interactivity but also sending http request to the back end (without actually having any). As the project went forward and I learnt more and more about NodeJs back end, I started to build the back end side with receiving and sending data.
Case nr.2 - Writing full stack project with limited front end knowledge
That might sound weird, as I just stated above I know front end. This is an ongoing project where I want to build an full stack application with React front end and NodeJS back end. Now here comes the tricky part as I dont know much (yet) about React. So I started to build the back end part of the project.
What is the main difference?
It felt more natural to write front end first, because this way I always knew exactly what data is going to be sent to the back end.
Writing back end first, I need to make notes what data and data structure I expect later from the front end. And that is okay but I am little skeptic that I can really send these data later. The reason for this is probably just because my React knowledge is so small right now that I do not see how all things going to get together alter.
All in all writing back end first felt little weird, but still manageable.
So all the experienced (back end) developer out there, please tell me how I should imagine writing just back end in real life? What information you get before starting a project?
Top comments (18)
What to write first?
Backend <-> Frontend communication specification and documentation ;) Then both sides can base on it and implement it. Frontend can use some mock servers based on spec, backend just implement spec on their side. Then frontend can change mocks to real backend responses and test integration.
Yeah I heard (and know) specification and documentation is really crucial working as a team.
A useful technique I use occasionally is c4model.com/, check it out.
Thank you, I am gonna definitely check it out !
Depending on the size and novelty of the idea... you might choose to:
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 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.
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.
For me it's what's the intended purpose of your front end. Like if you will submit forms then design your front-end variables first then write the back-end. I think this way it will reduce development time.
Here’s my favourite workflow for full-stack:
I use a text wireframe tool to define the scope of the project with the stakeholders. The tool is interactive so that when we’re done the stakeholders are confident that the project specifications are captured fully. I’m no designer unfortunately, but at this point I would either take a stab at static mock-ups or the client would hire a designer to produce them.
Once the designs were approved I would build out all the front-end, JavaScript, image and CSS assets, markup, all of it. I would do it in React or Angular, complete with an API service for the data model. The only difference is that instead of actually hitting a back-end and returning live data, I would have static JSON that would get returned instead, as a mock response. This serves two very important purposes:
I can work rapidly to make sure that the stakeholders are happy with the implementation of the design, and any user interactions. This is important because most times the stakeholders don’t know and don’t care how the back-end will be developed — they only care about what they can see and touch. We want to load all the clients’ feedback up front so that they’re 100% confident that their needs are captured, and also so that we can respond to requests for changes/additions as quickly as possible. Front-end changes are way easier to do than front-end, back-end and database changes.
With the front-end mock JSON approved, I now have data contracts that I can use to write up the specifications for the database. I now know what each call to the API I have to write will receive for input, and what it should respond with for output. This means that now there is absolutely no guess-work, and because I know the stakeholders approved everything, so long as I follow the data contract I don’t need any more approvals.
As each endpoint is completed, I replace the static mock in the front-end with the connection to the live API, and test the interaction to make sure it’s still functional. Rinse and repeat for every mock in the front-end until the whole application is using live API calls.
Now all that’s left is to deploy the front-end, back-end and database to staging servers, and get final sign-of by the stakeholders, and then once that’s received deploy to the production environment.
Front-end first means we can work quickly with all the necessary checkpoints for stakeholder approval. We can build out the back-end and database with minimal feedback from the client. And, we guarantee that the user interactions are designed in the mental model of the stakeholders and end users, rather than being a byproduct of the needs of our engineers working on the back-end.
Hope that helps!
I would say API first if you're separating front from back. (And of course if you already have the idea developed)
Basically make a contract deciding what the request and what the response is, and then backend and frontend can develop against it and communicate via API spec changes
+1 for the inside out approach. Think first about the data interaction you will need and shape your data to accommodate. You can then mock out the front end according the data shape and simultaneously build the APIs to fetch and store the data. If you are working as part of a team this data 'contract' is essential to allow both halves to progress independently
Why not write multiple articles that enable you to give appropriate detail to each section?
Writing front end takes time so i thinks it better to start with backend
I agree, front end might be more time consuming because of the implementation of features and design.
I prefer writing Backend first and then mock the data out on Frontend. Though UI can be designed simultaneously of Backend development.