Sleek v2.0 public release is here
Lorem ipsum dolor sit amet, consectetur adipiscing elit lobortis arcu enim urna adipiscing praesent velit viverra sit semper lorem eu cursus vel hendrerit elementum morbi curabitur etiam nibh justo, lorem aliquet donec sed sit mi at ante massa mattis.
- Neque sodales ut etiam sit amet nisl purus non tellus orci ac auctor
- Adipiscing elit ut aliquam purus sit amet viverra suspendisse potent i
- Mauris commodo quis imperdiet massa tincidunt nunc pulvinar
- Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti
What has changed in our latest release?
Lorem ipsum dolor sit amet, consectetur adipiscing elit ut aliquam, purus sit amet luctus venenatis, lectus magna fringilla urna, porttitor rhoncus dolor purus non enim praesent elementum facilisis leo, vel fringilla est ullamcorper eget nulla facilisi etiam dignissim diam quis enim lobortis scelerisque fermentum dui faucibus in ornare quam viverra orci sagittis eu volutpat odio facilisis mauris sit amet massa vitae tortor condimentum lacinia quis vel eros donec ac odio tempor orci dapibus ultrices in iaculis nunc sed augue lacus
All new features available for all public channel users
At risus viverra adipiscing at in tellus integer feugiat nisl pretium fusce id velit ut tortor sagittis orci a scelerisque purus semper eget at lectus urna duis convallis. porta nibh venenatis cras sed felis eget neque laoreet libero id faucibus nisl donec pretium vulputate sapien nec sagittis aliquam nunc lobortis mattis aliquam faucibus purus in.
- Neque sodales ut etiam sit amet nisl purus non tellus orci ac auctor
- Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti
- Mauris commodo quis imperdiet massa tincidunt nunc pulvinar
- Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti
Coding collaboration with over 200 users at once
Nisi quis eleifend quam adipiscing vitae aliquet bibendum enim facilisis gravida neque. Velit euismod in pellentesque massa placerat volutpat lacus laoreet non curabitur gravida odio aenean sed adipiscing diam donec adipiscing tristique risus. amet est placerat in egestas erat imperdiet sed euismod nisi.
“Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum”
Real-time code save every 0.1 seconds
Eget lorem dolor sed viverra ipsum nunc aliquet bibendum felis donec et odio pellentesque diam volutpat commodo sed egestas aliquam sem fringilla ut morbi tincidunt augue interdum velit euismod eu tincidunt tortor aliquam nulla facilisi aenean sed adipiscing diam donec adipiscing ut lectus arcu bibendum at varius vel pharetra nibh venenatis cras sed felis eget dolor cosnectur drolo.
Photo by NordWood Themes on Unsplash
SUFFER
As Front-end developers, “waiting for the server (or API)” can sometimes become a daily mantra.
Whether we’re happy to get some rest from integration work or pissed off over our heads because the feature was supposed to be done yesterday but server isn’t ready yet (or broken or was just updated and changed or any one of a million other reasons), it’s never a good moment when the server stops responding.
Recently we’ve experienced this on one of our own projects and so decided to see how this situation get handled better in the future.
During the integration phase (let’s say after 50%-75% of our Front-end work is completed) there’s not much we can do except complain and maybe try the API again (and again and again).
However – as experienced FE devs we know it’s gonna happen. There’s no question about it, IT IS GONNA HAPPEN. It’s just a matter of when and how much of our work on that day / week will get blocked.
So knowing it’s headed that way, what can we do?
PREPARE
We’ve identified the way to tackle this as being split into 2 parallel processes:
- Fine-grained Integration planning
- Fallback mocks
Fine-grained Integration planning would come into being as identifying the app joint client-server flows and performing integration flow by flow.
It could be for example Login flow, Registration, load a dashboard page, edit user settings etc. – any complete user story which could be considered as a feature and that is mostly autonomous.
That way, we can complete full parts of the application full-cycle (client + server) and prevent going into a full-fledged integration phase which could easily result in frustration and missing our deadline.
While that can help making things smoother, Fallback mocks is the real deal. This means we create our own json-based simple mocks which can replace the server side on any call to the server.
This is done in many ways from light manual mocks, to semi-automated tools such as mimicjs and more.
The main idea is to spend some effort in the beginning and throughout the project to make sure that at any point, we can go “server-less” and avoid waiting for the server in order to fix the shade of that submit button deep in a modal window that only exists under certain data conditions which are either non-existent yet or hard-to-simulate with real data.
WIN
Ultimately, we discovered that by good FE + BE team collaboration and agreement on applying both principals above, we’re able to minimize costs & frustration of final integration and adhere to meeting our deadlines.
What do you think? Do you know any better ways to accomplish this?
Nadav Lebovitch
Nadav Lebovitch is the Founder & CTO of nSoft, helping VC-backed startups build scalable web and mobile solutions. With 18+ years of experience, he has led hundreds of projects using modern technologies like React, Node.js, and PostgreSQL.
