Validations in Full Stack Development

Full Stack Development, a quite tough to explain in a couple of lines. It takes ownership of the entire application from top to bottom. If you see a person as Full Stack Developer, he must be an all-rounder to develop an application from zero to high excellence. Full Stack Development includes 2 layers of architecture :

  1. Front-End Development (aka Client-Side / Presentation Layer)
  2. Back-End Development (aka Server-Side / Business Logic Layer)

Each Layer should have a data validations. Let’s dive in deeper,

Client-Side Validations

Validation takes place on the client side(web browser). It would be more frustrating to wait for the server response and re-enter the form that has nearly 100 inputs. So it is mainly for formatting data instantly and for the quick error recovery process.
Client-side validation gives the user feedback ASAP without having to wait for the server. It is an added topping, but not necessary. This will avoid the majority of validation issues and unnecessary processing from the server to perform data validations.


  • Faster than Server-Side Validation
  • Better user experience can be provided by responding quickly(like invalid phone number, required fields,etc..)
  • Saves network bandwidth, traffic API calls


  • Not Secure and useless if client-side scripts are disabled(javascript disabled)

Server-Side Validations

It is all about the data validation takes place on the server-side using the server-side scripting language. If you use server-side validation, you are developing a more secure application. Because client-side validations can be bypassed easily.

Let’s take a scenario. If a user is a technical guy/ a malicious user, he can pass invalid inputs through API testing tool or he can disable the javascript in client script or some malicious attack to skip client side validations. In these cases, validation will not happen. This may lead to incorrect entries, server downtime if any serious errors, etc, So we should verify on the server as well.

There are few libraries(eg., express-validator, etc) available to validate the inputs. Better, write a few code snippets for validations before continuing your business logic like‘/api’, async(req, res) => {

 let isValidationPassed= await validateAndHandleInputs(req);


  //continue the business logics




  • More Secure than Client-Side Validation
  • Validation Techniques and Logics cannot be viewed/modified by the user.


  • Comparatively slower execution



Understanding CSS: Precedence & Specificity

Have you faced a situation where you are trying to apply the CSS style to an element, but it does not apply? It seems the webpage is ignoring your code. This could be caused by conflicts in the cascade order.

Things will discuss here:

  1. Origins of Stylesheets
  2. Specificity
  3. Importance
  4. Cascade Order

Origins of stylesheets:

  1. Author stylesheet (Styles set by the web developers)
  2. User stylesheet (Custom styles set by a user – Browsers give you the option of extending the browser’s default style sheet)
  3. Browser stylesheet / User-agent style sheet (Browser defaults – if the author of a web page didn’t apply any styling, the styling details present in the default stylesheet installed within the browser is applied)


        An HTML element can be targeted by multiple CSS rules. If there are two or more conflicting CSS rules, the browser will apply the rule which is more specifically mentioned. Specificity will only apply when one element has multiple declarations to it. To understand in a better way, the specificity is expressed in the form (a, b, c, d). Lets see in detail,

Specificity Hierarchy (High to Low):

  • Inline style

o   ‘style’ attribute rather than a rule with a selector

o   The position ‘a’ – (a, b, c, d) – (1, 0, 0, 0)

  • ID Selectors

o   Eg. The element with id attribute, id=’example’(#example)

o   The position ‘b’ – (a, b, c, d) – (0, 1, 0, 0)

  • Class Selectors(.example), Attribute selectors([type=radio]) and pseudo-classes(:hover)

o   The position ‘c’ – (a, b, c, d) – (0, 0, 1, 0)

  • Type Selectors(h1) and pseudo-elements (::after)

o   The position ‘d’ – (a, b, c, d) – (0,0,0,1)


Selectors Specificity
*{ } 0,0,0,0
li{ } 0,0,0,1
li:first-line { }   0,0,0,2
ul li{ }   0,0,0,2
ul ol+li{ } 0,0,0,3
h1 + *[rel=up]{ } 0,0,1,1
ul ol  { } 0,0,1,3  { } 0,0,2,1
#exampleId{ } 0,1,0,0
style=”” 1,0,0,0

No Specificity:

  1. The universal selector (*,+, -,>, ~) has no specificity value.
  2. The pseudo-class :not() adds no specificity. The negation ‘ pseudo-class: not’ is not considered a pseudo-class in the specificity calculation. It counts as normal selectors

Origin Hierarchy:

Below is the priority order from highest to lowest for normal styles when there is equal specificity for the declarations. If it was an important style (! important), it is just the reverse.

  1. Author style sheet
  2. User style sheet
  3. User-agent (browser) stylesheet


  1. Normal declaration (p {color: red} )
  2. Important declaration (p {color: red !important} )


The !important value appended in a declaration along with the property value in any of the ruleset/rules will be taken as the most priority even if the rule has less specificity.

Override !important:

Either add Specificity to the declaration or have only one !important declaration, remove others.

Cascade Order:

        The cascading order depends on origin, specificity, importance and source order. Below is the precedence order from low to high,

  1. Declarations in user agent style sheets (e.g. the browser’s default styles, used when no other styling is set).
  2. Normal declarations in user style sheets (custom styles set by a user).
  3. Normal declarations in author style sheets (these are the styles set by the web developers).
  4. Important declarations in author style sheets
  5. Important declarations in user style sheets


  • Declaration with Same Importance and Same-Origin: More specific selectors will override more general ones
  • Source Order – Declaration with the Same Importance, Same Specificity, and Same-Origin: the later rule takes precedence

Best Practices:

  • Use Class selectors instead of ID selectors.
  • Avoid using multiple CSS rules that target the same HTML elements.
  • Do not use inline styles.
  • Use specificity before even considering !important .
  • Although ‘!important’ works, it is generally bad practice. It can make debugging a difficult process
  • Only use !important on page-specific CSS that overrides foreign CSS (from external libraries, like Bootstrap or normalize.css).