Frontend Development: The part of a website that the user interacts with directly is termed the front end. It is also referred to as the ‘client side’ of the application. It includes everything that users experience directly: text colors and styles, images, graphs and tables, buttons, colors, and navigation menu. HTML, CSS, and JavaScript are the languages used for Front End development.

Backend Development: Backend is the server-side of the website. It stores and arranges data, and also makes sure everything on the client-side of the website works fine. It is the portion of software that does not come in direct contact with the users. The parts and characteristics developed by backend designers are indirectly accessed by users through a front-end application. Activities, like writing APIs, creating libraries, and working with system components without user interfaces or even systems of scientific programming, are also included in the backend.

How does the front-end and backend communicate?

The backend and frontend both work together to serve a single goal. It’s pretty helpful to keep it in mind at all times. They are made, so a user can access them. In detail this interaction can look like this:

• The user points their browser to one of your website’s urls
  • This makes the browser send out one or more requests to your server
  • The browser waits to receive responses from your server
  • Every response is used to render a part of the site
• The user waits for the browser to render the page
• The user sees a useful and usable page
• The user interacts with the page
  • Causing more requests to be sent out, to get more data and display new information, and so on. It’s all about the user.

The front- and backend make this possible by causing requests to be sent and answering with responses.

What are the important programming languages used?

The frontend portion is built by using popular programming languages like:

• HTML: HTML stands for Hypertext Markup Language. It is used to design the front-end portion of web pages using a markup language. The markup language is used to define the text documentation within the tag which defines the structure of web pages.
• CSS: Cascading Style Sheets fondly referred to as CSS is a simply designed language intended to simplify the process of making web pages presentable. CSS allows you to apply styles to web pages.
• JavaScript: JavaScript is a famous scripting language used to create magic on the sites to make the site interactive for the user. It is used to enhancing the functionality of a website to running cool games and web-based software.

On the other side, the backend is usually built with the following languages:

• PHP
• C++
• Java
• Python
• JavaScript
• Node.js

Sources:

How Does the Frontend Communicate with the Backend? · vsupalov.com

Front End vs. Back End Development | Flatiron School

Frontend vs Backend – GeeksforGeeks

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

Unified Modeling Language (UML) is a general-purpose modelling language. The main aim of UML is to define a standard way to visualize the way a system has been designed. UML is not a programming language, it is rather a visual language. We use UML diagrams to portray the behavior and structure of a system. UML helps software engineers, businessmen and system architects with modelling, design and analysis.

Why use UML?

• Complex applications need collaboration and planning from multiple teams and hence require a clear and concise way to communicate amongst them.
• Most clients do not understand code. So UML becomes essential to communicate with non-programmers essential requirements, functionalities and processes of the system.
• A lot of time is saved down the line when teams are able to visualize processes, user interactions and static structure of the system.

Here are structural UML Diagrams :

• Class Diagram – The most widely use UML diagram is the class diagram. It is the building block of all object-oriented software systems. We use class diagrams to depict the static structure of a system by showing system’s classes, their methods and attributes. Class diagrams also help us identify relationship between different classes or objects.
• Composite Structure Diagram – We use composite structure diagrams to represent the internal structure of a class and its interaction points with other parts of the system. Itdiagram represents relationship between parts and their configuration which determine how the classifier (class, a component, or a deployment node) behaves.
• Object Diagram – An Object Diagram can be referred to as a screenshot of the instances in a system and the relationship that exists between them. Since object diagrams depict behaviour when objects have been instantiated, we are able to study the behaviour of the system at a particular instant. An object diagram is similar to a class diagram except it shows the instances of classes in the system. We depict actual classifiers and their relationships making the use of class diagrams. On the other hand, an Object Diagram represents specific instances of classes and relationships between them at a point of time.
• Component Diagram – Component diagrams are used to represent the how the physical components in a system have been organized. We use them for modelling implementation details. Component Diagrams become essential to use when we design and build complex systems. Interfaces are used by components of the system to communicate with each other.
• Deployment Diagram – Deployment Diagrams are used to represent system hardware and its software. It tells us what hardware components exist and what software components run on them. They are primarily used when a software is being used, distributed or deployed over multiple machines with different configurations.
• Package Diagram – We use Package Diagrams to depict how packages and their elements have been organized. A package diagram simply shows us the dependencies between different packages and internal composition of packages.

Sources:

What is Unified Modeling Language (UML)? (visual-paradigm.com)

What is UML? Everything You Need to Know About Unified Modeling Language | Gliffy by Perforce

What is Unified Modeling Language (UML)? – Definition from Techopedia

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

MongoDB is a source-available cross-platform document-oriented database program, classified as a NoSQL database. The data objects are stored as separate documents inside a collection instead of storing the data into the columns and rows of a traditional relational database.     

NoSQL databases like MongoDB are a good choice when your data is document-centric and doesn’t fit well into the schema of a relational database, when you need to accommodate massive scale, when you are rapidly prototyping, and a few other use cases. The motivation of the MongoDB language is to implement a data store that provides high performance, high availability, and automatic scaling. Documents hold semi structured data, usually represented in a format like JSON or XML, and each document is associated with a unique key. Key values are typically a path or a URI that can be used to retrieve the associated document from the database. The keys are indexed, making it efficient to retrieve the associated documents.  

Key Components of MongoDB Architecture:

1. _id: This is a field required in every MongoDB document it represents a unique value in the MongoDB document. If you create a new document without an _id field, MongoDB will automatically create the field.

2. Collection: This is a grouping of MongoDB documents. A collection is the equivalent of a table which is created in any other RDMS such as Oracle or MS SQL. Collections don’t enforce any sort of structure.

3. Cursor: This is a pointer to the result set of a query. Clients can iterate through a cursor to retrieve results.

4. Database: This is a container for collections like in RDMS wherein it is a container for tables. Each database gets its own set of files on the file system. A MongoDB server can store multiple databases.

5.  Document: A record in a MongoDB collection is basically called a document. The document, in turn, will consist of field name and values.

6. Field: A name-value pair in a document. A document has zero or more fields. Fields are analogous to columns in relational databases.

7. JSON: This is known as JavaScript Object Notation. This is a human-readable, plain text format for expressing structured data. JSON is currently supported in many programming languages.

Difference between MongoDB & RDBMS

In RDBMS, the table contains the columns and rows which are used to store the data whereas, in MongoDB, this same structure is known as a collection. The collection contains documents which in turn contains Fields, which in turn are key-value pairs.

In RDBMS, the row represents a single, implicitly structured data item in a table. In MongoDB, the data is stored in documents.

In RDBMS, the column denotes a set of data values. These in MongoDB are known as Fields.

In RDBMS, data is sometimes spread across various tables and in order to show a complete view of all data, a join is sometimes formed across tables to get the data. In MongoDB, the data is normally stored in a single collection, but separated by using Embedded documents. So there is no concept of joins in MongoDB.

Sources:

When to Use (and Not to Use) MongoDB – DZone Database

MongoDB – WikipediaWhen to Use NoSQL and MongoDB | Blog | Fivetran

MongoDB – Wikipedia

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

An Architectural Pattern is a named collection of architectural design decisions that are applicable to a recurring design problem parameterized to account for different software development contexts in which that problem appears.

An Architectural Style is a named collection of architectural design decisions that (1) are applicable in a given development context, (2) constrain architectural design decisions that are specific to a particular system within that context, and (3) elicit beneficial qualities in each resulting system.

In simple words, the main difference between them is that An Architectural Pattern is a way of solving a recurring architectural problem. MVC, for instance, solves the problem of separating the UI from the model. Sensor-Controller-Actuator, is a pattern that will help you with the problem of actuating in face of several input senses.

An Architectural Style, on the other hand, is just a name given to a recurrent architectural design. Contrary to a pattern, it doesn’t exist to “solve” a problem. Pipe&filter doesn’t solve any specific problem, it’s just a way of organizing your code. Client/server, Main program & subroutine and Abstract Data Types / OO, the same.

A single architecture can contain several Architectural Styles, and each Architectural Style can make use of several Architectural Patterns. An Architecture Patterns can be a subset of an Architectural Styles targeting a specific scope.

Here are some examples of architectural patterns:

• Multitier architecture
• Model–view–controller: divides an interactive application in to 3 parts as,
  • model — contains the core functionality and data
  • view — displays the information to the user (more than one view may be defined)
  • controller — handles the input from the user

• Domain-driven design: the idea is to design software based on the Business Domain, its elements and behaviors, and the relationships between them.
• Blackboard pattern: This pattern is useful for problems for which no deterministic solution strategies are known. The blackboard pattern consists of 3 main components.
  • blackboard — a structured global memory containing objects from the solution space
  • knowledge source — specialized modules with their own representation
  • control component — selects, configures and executes modules.

• Sensor–controller–actuator
• Presentation–abstraction–control

Here are some examples of architectural styles:

• Component-based
• Monolithic application
• Layered: This pattern is used to structure programs that can be decomposed into groups of subtasks. It partitions the concerns of the application into layers.
• Pipes and filters: It consist of any number of components, called Filters, that transform or filter data, before passing it to other components through connectors called Pipes.
• Event-driven: Also called EDA, this pattern organizes a system around the production, detection and consumption of events.
• Publish-subscribe
• Plug-ins
• Client-server: This pattern consists of two parties; a server and multiple clients. The server component will provide services to multiple client components.
• Service-oriented

Helpful resources:

10 Common Software Architectural Patterns in a nutshell | by Vijini Mallawaarachchi | Towards Data Science

List of software architecture styles and patterns – Wikipedia

Architectural Styles and Architectural Patterns | by Mátyás Lancelot Bors | Medium

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

Code smell is a term used in software development to describe surface-level observations in design that indicate deeper systemic issues leading to negative outcomes. This term was coined by Martin Fowler and Kent Beck in the 1999 book Refactoring: Improving the Design of Existing Code (1).

Code smells are not bugs or errors. Instead, these are violations of the fundamentals of developing software that decrease the quality of code.

Here are the three common level of smells:

• Application Level Smells(Duplicate code, Shotgun Surgery, Contrived Complexity,…)
• Class Level Smells(Large Class, Parallel Inheritance Hierarchy,…)
• Method Level Smells(Long Method, Long Method,…)

How can developers get rid of code smell?

Code smells knowing or unknowingly are introduced in the source code, and may also form if you are solving other smells. Developers discard most of the smells consciously because they seem to have a marginalized effect or are just too hard to explain.

When developers find a smelly code, the next step they do is refactoring. Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the software yet improves its internal structure. It may be the single most important technical factor in achieving agility.

The goal is to stay within reasonable operating limits with limited continual damage. By staying within these limits, you keep costs low, because costs relate nonlinearly to the amount of repair necessary. Refactoring is a process in which the code is divided into smaller sections according to the identified smells.

A decision is then made to either remove them or replace them with a better series of code that may increase code quality and enhance some nonfunctional quality – simplicity, flexibility, understandability, performance. After refactoring, run tests to ensure things still work correctly. Sometimes this process has to be repeated until the smell is gone.

A faster way to solve this issue is by using automated code review tools that can identify smells.  Identifying and removing code smells, as seen above, is a tiresome and indefinite process with no particular result if the software would be smell free or not. Also, as it’s near impossible to find and remove all smells manually, using automated code review tools that can identify smells becomes a necessity.

Source:

What are Code Smells? | How to detect and remove code smells? (codegrip.tech)

Code Smell (a.k.a. Software Design Smells) – αlphαrithms (alpharithms.com)

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

A REST API (also known as RESTful API) is an application programming interface (API or web API) that conforms to the constraints of REST architectural style and allows for interaction with RESTful web services. REST is an acronym for Representational State Transfer and an architectural style for distributed hypermedia systems. It was created by computer scientist Roy Fielding.

An API is a set of definitions and protocols for building and integrating application software. It’s sometimes referred to as a contract between an information provider and an information user—establishing the content required from the consumer (the call) and the content required by the producer (the response).

REST has a set of rules that developers follow when they create their API. One of these rules states that you should be able to get a piece of data (called a resource) when you link to a specific URL. Each URL is called a request while the data sent back to you is called a response.

In order for an API to be considered RESTful, it has to conform to these criteria:

• A client-server architecture made up of clients, servers, and resources, with requests managed through HTTP.
• Stateless client-server communication, meaning no client information is stored between get requests and each request is separate and unconnected.
• Cacheable data that streamlines client-server interactions.
• A uniform interface between components so that information is transferred in a standard form. This requires that:
  • resources requested are identifiable and separate from the representations sent to the client.
  • resources can be manipulated by the client via the representation they receive because the representation contains enough information to do so.
  • self-descriptive messages returned to the client have enough information to describe how the client should process it.
  • hypertext/hypermedia is available, meaning that after accessing a resource the client should be able to use hyperlinks to find all other currently available actions they can take.
• A layered system that organizes each type of server (those responsible for security, load-balancing, etc.) involved the retrieval of requested information into hierarchies, invisible to the client.
• Code-on-demand (optional): the ability to send executable code from the server to the client when requested, extending client functionality. 

In conclusion, here are 3 good reasons to use rest api’s:

• Scalability. This protocol stands out due to its scalability. Thanks to the separation between client and server, a product may be scaled by a development team without much difficulty.
• Flexibility and portability. With the indispensable requirement for data from one of the requests to be properly sent, it is possible to perform a migration from one server to another or carry out changes on the database at any time. Front and back can therefore be hosted on different servers, which is a significant management advantage.
• Independence. With the separation between client and server, the protocol makes it easy for developments across a project to take place independently. In addition, the REST API adapts at all times to the working syntax and platform. This offers the opportunity to use multiple environments while developing.

resources:

https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/

https://restfulapi.net/

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

Object-oriented programming (OOP) is a computer programming model that organizes software design around data, or objects, rather than functions and logic. An object can be defined as a data field that has unique attributes and behavior. OOP focuses on the objects that developers want to manipulate rather than the logic required to manipulate them. Object-Oriented-Programing allows programmers to think of software development as if they are working with real-life entities.

4 Pillars of Object-Oriented Programming

• Encapsulation. This principle states that all important information is contained inside an object and only select information is exposed. The implementation and state of each object are privately held inside a defined class. Other objects do not have access to this class or the authority to make changes. They are only able to call a list of public functions or methods. This characteristic of data hiding provides greater program security and avoids unintended data corruption 
• Abstraction. Objects only reveal internal mechanisms that are relevant for the use of other objects, hiding any unnecessary implementation code. The derived class can have its functionality extended. This concept can help developers more easily make additional changes or additions over time.
• Inheritance Classes can reuse code from other classes. Relationships and subclasses between objects can be assigned, enabling developers to reuse common logic while still maintaining a unique hierarchy. This property of OOP forces a more thorough data analysis, reduces development time and ensures a higher level of accuracy.
• Polymorphism Objects are designed to share behaviors and they can take on more than one form. The program will determine which meaning or usage is necessary for each execution of that object from a parent class, reducing the need to duplicate code. A child class is then created, which extends the functionality of the parent class. Polymorphism allows different types of objects to pass through the same interface.

The difference between concepts of encapsulation and abstraction is that encapsulation is about the packaging of the class (like how data should be accessed (setters/getters) and what data should be accessed (access specifiers)), whereas abstraction more about what the class does for you at a conceptual level. Encapsulation is hiding unnecessary data in a capsule or unit and Abstraction is showing essential feature of an object

Important advantages include:

• Objects comprise data that define its state and methods that define its behavior. Each object encapsulates these two entities.

• The internal implementation of object methods is invisible to the user. This way objects abstract state changes under a simplified external API.
• Objects are instances of classes. Classes are blueprints to build objects. The class of an object is also its type.
• Classes can inherit both state and behavior from other classes. Based on this notion, objects of the subclass support casting into objects of the parent class.
• This form of casting gives rise to polymorphism. The program can implicitly cast an object of a class to an object of the class’s ancestors.

Resources:

The Four Pillars of Object Oriented Programming (keylimeinteractive.com)

6 Pros and Cons of Object Oriented Programming – Green Garage (greengarageblog.org)

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.