How to Build Complex Web Applications using SDLC and Right Design Approach

Archit Singh
May 2 · 4 min read
Image for post
Image for post
Do you want to Build a Masterpiece Web Application? Let's do it

Whenever we get to work on a new requirement which could be a complete web Application or a small feature, the first question which comes into our mind what Technology should we use to implement it. I think before deciding the Technology, language to implement we should understand the problem and do multiple rounds of whiteboarding the problem. If we want to build a scalable UI solution this is an important step which is skipped by many developers because of many reasons. So what are the steps that should be considered while doing the whiteboarding, Design Thinking and important points to be kept in mind while developing a web Application -

1. Contract Discussion and Finalisation

Analyze the contract that the web application needs to consume. Please do not expect to get the perfect payload sent from the services 😆, yes this is the truth so you will have to write a transformer layer to convert it to the one ideal for UI to render. Again this could be done by two ways either we could write a service like a node server for transformation or it could be done in UI also, both has its pros and cons, I would suggest if transformation is not too costly it could be done in UI itself to reduce the extra hop.

2. Designing the UI store (here we need to finalize the framework to go forward)

I assume we are using the framework where the data flow would happen unidirectional such as Flux, Redux Apollo client. The most imp thing to keep in mind while using any of them is that store should be immutable because its the source of truth for the application, any discrepancy would result in UI going to toss😅.I have worked in all of the above-mentioned stores, but found the Redux easier to create, maintain, and a lot easier. Apollo is nice as it has a wonderful capability of caching the request(If you have GraphQl Schema layer in the backend service you should definitely go with Apollo Client). I would explain my learning of Apollo in a separate post. Try creating a store as simple as possible to understand.

I usually break my stores into smaller stores based on requirements from the Components.

3. Choosing the Right JavaScript Bundler

The most prominent bundler is without a doubt Webpack, it has all kinds of the capability to improve the performance of the bundle such as — Treeshaking, lazy loading which could be configured easily on the webpack.config.js file this is again a vast Topic which could be covered separately.

4. Using Functional Components

I would suggest using the Functional Components mostly at the unit level which does not have any local state and is independent of any data manipulation and is reusable. So many unit Functional Components can be placed under a Parent component which could have a local state and can listen to the data store any modification in data should be kept at this level. I would suggest updating the store at once only as it is a clearly complex operation than modifying the local state.

5. Using the perfect Css for your UI

Again there are many ways like giving CSS in class names, using SCSS or SASS. I would personally suggest using styled-components because it provides Freedom to build custom components with CSS and also Styled Components are unit testable isn’t it perfect. 🤩

6. Unit Test Cases and Integration Test Cases

Writing Test cases makes us confident of our code and is best practice for Engineering excellence at any Organisation that is called TDD(Test Driven Development). I have worked on a number of test case frameworks namely — jest, enzyme , intern , chai , jasmin, mocha.Testing could involve the snapshots Testing and the module testing both.

7. Browser Testing

This is also one of the important steps to verify everything works fine across all Browsers.

8. Accessibility

Yes this is one of the Equally Important things which must be taken care that UI should be accessible from the Keyboard along with it should be read in the Screen Reader

9. Responsive Across Devices

The Screen built should be responsive across all devices like mobile, Tablets. Mostly we get separate mockups specific for the screen.

10. Add Tracking of User Interactions

We should Track the Interaction of Users there are a number of analytics tools like — Google Analytics, Omniture, Amplitude

This helps in predicting User behavior like what is the most used feature by Users. Here everything the play of Events and is very easy😄.

You could Build Dashboards for those captured metrics.

11. Adding Fallback Screen On Failure

Any kind of failure should have a fallback screen. In React we can leverage the React Error Boundary.

12. Log the Errors

Any kind of failure should be logged in tools like Splunk. Any new release should be monitored with the Splunk Dashboard. I personally log only the Errors otherwise logger also has debug and info methods also.


When you are willing to learn from the design team, you are also learning different ways of thinking. I feel it’s continuous learning more we participate in others helping out with Design Thinking more we know about it.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store