What Could Be The Good Architecture – UI

What Could Be The Good Architecture – UI

I know this is not a universal Architecture and it vary project to project, maybe this structure contains some redundancy because it cannot suit your project but I guess It’s a good start point.

Creating a good and maintainable front-end architecture is an important step to start a web application or a website.

Best practices are important, but what about the architecture that can be maintainable in future?

Before we start, we need to understand couple of things:

  1. Is my project multi page? (a web app or website).
  2. Is my client required responsive website?
  3. Do I really want my final product maintainable?
  4. What about the adequate or excellent level of performance or efficiency.
  5. Do I need to focus on reusable template?



The Best tools which can help us

We have lot of nice tools that can help us creating the prefect (ok not perfect but good) application workflow. So, in respect of multi-page project and responsive website we need to breakpoint based CSS architecture that could help us for multiple devices.

So, too much of CSS and files can be very messy so we will implement CSS preprocessor (SASS)

For the excellent level of performance and efficiency module bundlers like webpack and yarn for task runner and yeoman for the reusable template.

Maintain the workflow

All the application always has libraries, plugins and js and css files for different purpose.

To maintain all files means working with different technologies and putting them together and build a good front-end architecture.

We have to manage a big workflow that contains different technologies and that’s why we need to organize in folders and maintain the best practice, good convention and standards to keep code and architecture clean.


We can divide our all components into different and separate group as below:

  • SCSS files
  • scripts
  • views

We can further divide the group.

  • SCSS
    • variables
    • mixins
  • js
    • libraries (Example: angularjs)
    • plugins (Example: angularjs plugins)
    • controllers (I mean controllers such as angularjs controllers)


So, This is how we should organize the architecture.









































Folders Details:


We will add all images files in Images folder: .png, .jpg, .jpeg , wallpapers etc.



We will add all all.js files in js folder and maintain in subfolders as follows:

\ controllers

This is the folder for controllers, each file has the name respective to the view. For example, if your index.html needs an angular controller, you should create a file like this: project\js\controllers\index.js.

\ libs

I created this folder for JavaScript libraries. When I say libraries I don’t mean plugins, that’s why I decided to distinguish between the first ones and the second ones, creating two different folders.
\ plugins
Plugin need dependencies to work. So here is why I created a different folder:
\ views
We created this folder for all the presentational stuff. each file has the name respective to the view. For example, if your index.html needs some js functionality and plugins initialization, you should create a file like this: project\js\views\index.js, that has its own document ready.



This folder contains all css from maintain the scss files. For example home.scss will generate the corresponding home.css file in this folder.

\ libs

Even for the CSS files I am distinguishing between libraries and plugins

\ plugins

Plugin folder contain the css that style the JavaScript plugins.

\ framework

We decided to put scss files of whole project pages in this directory

The framework folder will be organized as follows:
_variables.scss, _mixins.scss, _forms.scss,  _input.scss

\ layouts

And here is the responsive part., then just rewrite rules and declare them for any other screen resolution or use bootstrap.


The final Architecture

We know that Webpack is not a task runner, so should we use grunt or gulp now?



We need to do is define your tasks in the scripts section of your package. json file:


“scripts”: {

“build”: “node build.js”



You can use NPM or Yarn as a task runner:

$ yarn run build



I would recommend to create your own architecture or framework as per your requirement for better performance and without redundant stuff



No, REST is the way HTTP should be used.

Today we only use a tiny bit of the HTTP protocol’s methods – namely GET and POST. The REST way to do it is to use all of the protocol’s methods.

For example, REST dictates the usage of DELETE to erase a document (be it a file, state, etc.) behind a URI, whereas, with HTTP, you would misuse a GET or POST query like ...product/?delete_id=22.

Hence HTTP is an application protocol. REST is a service having set of rules, that when followed, enable you to build a distributed application that has a specific set of desirable constraints.

REST = Representational State Transfer

REST is a set of rules, that when followed, enable you to build a distributed application that has a specific set of desirable constraints.

REST is a protocol to exchange any(XML, JSON etc ) messages that can use HTTP to transport those messages.

REST = Representational State Transfer

REST is a set of rules, that when followed, enable you to build a distributed application that has a specific set of desirable constraints.

REST is a protocol to exchange any(XML, JSON etc ) messages that can use HTTP to transport those messages.


It is stateless which means that ideally no connection should be maintained between the client and server. It is the responsibility of the client to pass its context to the server and then the server can store this context to process the client’s further request. For example, session maintained by server is identified by session identifier passed by the client.

Advantages of Statelessness:

  1. Web Services can treat each method calls separately.
  2. Web Services need not maintain the client’s previous interaction.
  3. This in turn simplifies application design.
  4. HTTP is itself a stateless protocol unlike TCP and thus RESTful Web Services work seamlessly with the HTTP protocols.

Disadvantages of Statelessness:

  1. One extra layer in the form of heading needs to be added to every request to preserve the client’s state.
  2. For security we need to add a header info to every request.

HTTP Methods supported by REST:

GET: /string/someotherstring It is idempotent and should ideally return the same results every time a call is made

PUT: Same like GET. Idempotent and is used to update resources.

POST: should contain a url and body Used for creating resources. Multiple calls should ideally return different results and should create multiple products.

DELETE: Used to delete resources on the server.


The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The meta information contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request.


This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

HTTP Responses

Go here for all the responses.

Here are a few important ones: 200 – OK 3XX – Additional information needed from the client and url redirection 400 – Bad request
401 – Unauthorized to access
403 – Forbidden
The request was valid, but the server is refusing action. The user might not have the necessary permissions for a resource, or may need an account of some sort.

404 – Not Found
The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.

405 – Method Not Allowed A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via POST, or a PUT request on a read-only resource.

404 – Request not found
500 – Internal Server Failure
502 – Bad Gateway Error

Javascript Basics – 5

Symbol type

By specification, object property keys may be either of string type, or of symbol type. Not numbers, not booleans, only strings or symbols, these two types.

Till now we’ve only seen strings. Now let’s see the advantages that symbols can give us.


“Symbol” value represents an unique identifier with a given name.

A value of this type can be created using Symbol(name):

// id is a symbol with the name “id”

let id = Symbol(“id”);

Symbols are guaranteed to be unique. Even if we create many symbols with the same name, they are different values.

For instance, here are two symbols with the same name – they are not equal:

let id1 = Symbol(“id”);

let id2 = Symbol(“id”);

alert(id1 == id2); // false

Symbols don’t auto-convert to a string

Most values in JavaScript support implicit conversion to a string. For instance, we can alert almost any value, and it will work. Symbols are special. They don’t auto-convert.

For instance, this alert will show an error:

let id = Symbol(“id”);

alert(id); // TypeError: Cannot convert a Symbol value to a string

If we really want to show a symbol, we need to call .toString() on it, like here:

let id = Symbol(“id”);

alert(id.toString()); // Symbol(id), now it works