Key Concepts Related to CS

Front-end

A Front-end developer builds how a website looks. Front-end developers primarily use three languages: HTML, CSS, and Javascript. Over the past few years, the role of the front-end developer has evolved, so professional front-end devs might also want to consider developing some more intermediate to advanced JavaScript skills, as well as building up experience using command line tools and a framework such as React. Front-end devs should have some skills with design tools like PhotoShop, Sketch or Figma. Front-end developers should also know the basics of web hosting and buying a domain.

Back-end

A Back-end developer builds how a website works. Back-end developers need to be proficient in programming languages that render on the server side of a website or application. The most popular back-end programming languages are PHP, Ruby, Python, Node.js, and Java. Typically, a good back-end developer will be a master at one of these languages and familiar enough to code in a 2nd or 3rd programming language. Back-end developers will also need to be proficient in working with databases like MySQL, Oracle, and SQL Server. A back-end dev is often debugging code as well as designing systems for how the user will interact with the website. Questions the back-end dev should be able to answer: Where is data stored? Is it stored securely? If the site's traffic 100x's overnight, will the site be able to scale without crashing? How can I add a new feature to the website without breaking the current functionality? How can I test a website (often on a staging platform and/or running tests using test-driven development) so that the end-user experiences as few errors and bugs as possible?

REST - What is it?

REST, or REpresentational State Transfer, is an architectural style for providing standards between computer systems on the web that makes it easier for systems to communicate with each other. REST-compliant systems, often called RESTful systems, are characterized by how they are stateless and separate the concerns of client and server.

Principles of REST

There are six guiding constraints of REST. These are:

Client-Server Mandate: This mandate underscores the fact that REST is a distributed approach via the nature of separation between client and server. Each service has multiple capabilities and listens for requests. Requests are made by a consumer and accepted or rejected by the server.
Statelessness: Due to the nature of statelessness, it is a guiding principle of RESTful architecture. It mandates what kind of commands can be offered between client and server. Implementing stateless requests means the communication between consumer and service is initiated by the request, and the request contains all the information necessary for the server to respond.
Cache: Cache mandates that server responses be labeled as either cacheable or not. Caching helps to mitigate some of the constraints of statelessness. An example would be a request that is cached by the consumer in an attempt to avoid re-submitting the same request twice.
Interface / Uniform Contract: RESTful architecture follows the principles that define a Uniform Contract. This prohibits the use of multiple, self-contained interfaces within an API. Instead, one interface is distributed by hypermedia connections.
Layered System: This principle is the one that makes RESTful architecture so scalable. In a Layered System, multiple layers are used to grow and expand the interface. None of the layers can see into the other.
Code-On-Demand: RESTful applications don't have to include Code-On-Demand, but they must have Client-Server, Statelessness, Caching, Uniform Contract, and Layered Systems. Code-on-Demand allows logic within clients to be separate from that within servers. This allows them to be updated independently of server logic.

Separation of Client and Server

In the REST architectural style, the implementation of the client and the implementation of the server can be done independently without each knowing about the other. This means that the code on the client side can be changed at any time without affecting the operation of the server, and the code on the server side can be changed without affecting the operation of the client.

As long as each side knows what format of messages to send to the other, they can be kept modular and separate. Separating the user interface concerns from the data storage concerns, we improve both the flexibility of the interface across platforms and its scalability by simplifying the server components. Additionally, the separation allows each component to evolve independently.

By using a REST interface, different clients hit the same REST endpoints, perform the same actions, and receive the same responses.

Statelessness

Systems that follow the REST paradigm are stateless, which means that the server does not need to know anything about what state the client is in and vice versa. In this way, both the server and the client can understand any message received, even without seeing previous messages. This constraint of statelessness is enforced through the use of resources rather than commands. Resources are the nouns of the Web - they describe any object, document, or thing that you may need to store or send to other services.

Because REST systems interact through standard operations on resources, they do not rely on the implementation of interfaces.

These constraints help RESTful applications achieve reliability, quick performance, and scalability, as components that can be managed, updated, and reused without affecting the system as a whole, even during operation of the system.

Communication between Client and Server

In the REST architecture, clients send requests to retrieve or modify resources, and servers send responses to these requests. Let's take a look at the standard ways to make requests and send responses.

Making Requests

REST requires that a client make a request to the server in order to retrieve or modify data on the server. A request generally consists of:

an HTTP verb, which defines what kind of operation to perform
a header, which allows the client to pass along information about the request
a path to a resource
an optional message body containing data

HTTP Verbs

There are 4 basic HTTP verbs we use in requests to interact with resources in a REST system:

GET - retrieve a specific resource (by id) or a collection of resources
POST - create a new resource
PUT - update a specific resource (by id)
DELETE - remove a specific resource by id

REST Application

Each REST command is centered around a resource. In REST, a resource is really anything that can be pointed to via HTTP protocol. For example, an image, a website, a document, or a weather service. The possibilities are almost endless.

REST: In a Nutshell

REST refers to a set of defining principles for developing API. It uses HTTP protocols like GET, PUT, POST to link resources to actions within a client-server relationship. In addition to the client-server mandate, it has several other defining constraints. The principles of RESTful architecture serve to create a stable and reliable application that offers simplicity and end-user satisfaction.

CRUD Application

CRUD is an acronym for CREATE, READ, UPDATE, DELETE. These form the standard database commands that are the foundation of CRUD.

Many software developers view these commands as primitive guidance, at best. That's because CRUD was not developed as a modern way to create API. In fact, CRUD's origins are in database records.

By definition, CRUD is more of a cycle than an architectural system. On any dynamic website, there are likely multiple CRUD cycles that exist.

For instance, a buyer on an eCommerce site can CREATE an account, UPDATE account information, and DELETE things from a shopping cart

Principles of CRUD

As mentioned above, the principles of the CRUD cycle are defined as CREATE, READ/RETRIEVE, UPDATE, and DELETE.

Create: CREATE procedures generate new records via INSERT statements.
Read/Retrieve: READ procedures read the data based on input parameters. Similarly, RETRIEVE procedures grab records based on input parameters.
Update: UPDATE procedures modify records without overwriting them.
Delete: DELETE procedures delete where specified.

Frameworks Vs Library

Framework: Framework is defined as open or unimplemented functions or objects which the user writes to create a custom application. (C++/Java users will understand this as it is much like implementing an abstract function). Because a framework is itself an application, it has a wider scope and includes almost everything necessary to make a user application per one's own needs. Wikipedia makes it more clear:

"In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software"

Thus, the key difference is in the "Inversion of Control," commonly abbreviated as IoC. When we call a method from a library, we are in control. But in framework, the control is inverted i.e. the framework calls us. It defines a skeleton where the application defines its own features to fill out the skeleton.

Library: A library provides a set of helper functions/objects/modules which your application code calls for specific functionality. Libraries typically focus on a narrow scope (e.g., strings, IO, sockets), so their APIs also tend to be smaller and require fewer dependencies. It is just a collection of class definitions. Why do we need them? The reason being very simple i.e. code reuse, use the code which has already been written by other developers. For example, some library has a method named findLastIndex(char) to find the last index of a particular character in a string. We can straightaway call the findLastIndex(charToFind) function of the library and pass the characters whose position we need to find as a parameter in the function call.

Database

Database: A database is a collection of information that is organized so that it can be easily accessed, managed and updated. Computer databases typically contain aggregations of data records or files with information about sales transactions or interactions with specific customers. In a relational database, digital information about a specific customer is organized into rows, columns and tables, which are indexed to make it easier to find relevant information through SQL or NoSQL queries. In contrast, a graph database uses nodes and edges to define relationships between data entries and queries requiring a special semantic search syntax. As of this writing, SPARQL is the only semantic query language that is approved by the World Wide Web Consortium (W3C).

Typically, the database manager provides users with the ability to control read/write access, specify report generation and analyze usage. Some databases offer ACID (atomicity, consistency, isolation and durability) compliance to guarantee that data is consistent and transactions are complete.

Types of Databases

Cloud database

A cloud database is a database that has been optimized or built for a virtualized environment, either in a hybrid cloud, public cloud or private cloud. Cloud databases provide benefits such as the ability to pay for storage capacity and bandwidth on a per-use basis, and they provide scalability on demand, along with high availability. A cloud database also gives enterprises the opportunity to support business applications in a software-as-a-service deployment.

NoSQL database

NoSQL databases are useful for large sets of distributed data.

NoSQL databases are effective for big data performance issues that relational databases aren't built to solve. They are most effective when an organization must analyze large chunks of unstructured data or data that's stored across multiple virtual servers in the cloud.

Object-oriented database

Items created using object-oriented programming languages are often stored in relational databases, but object-oriented databases are well-suited for those items.

An object-oriented database is organized around objects rather than actions, and data rather than logic. For example, a multimedia record in a relational database can be a definable data object, as opposed to an alphanumeric value.

Graph database

A graph-oriented database, or graph database, is a type of NoSQL database that uses graph theory to store, map and query relationships. Graph databases are basically collections of nodes and edges, where each node represents an entity, and each edge represents a connection between nodes. Graph databases are growing in popularity for analyzing interconnections. For example, companies might use a graph database to mine data about customers from social media.

Graph databases often employ SPARQL, a declarative programming language and protocol for graph database analytics. SPARQL has the capability to perform all the analytics that SQL can perform. Plus, it can be used for semantic analysis, which is the examination of relationships. This makes it useful for performing analytics on data sets that have both structured and unstructured data. SPARQL allows users to perform analytics on information stored in a relational database, as well as friend-of-a-friend (FOAF) relationships, PageRank and shortest path.

If you want more practice on Databases, visit our Database Tutorial

Sources:

https://learn.onemonth.com/frontend-vs-backend-developers/

https://www.bmc.com/blogs/rest-vs-crud-whats-the-difference/

https://www.geeksforgeeks.org/software-framework-vs-library/

https://searchsqlserver.techtarget.com/definition/database

https://www.codecademy.com/articles/what-is-rest

You can find a full list of all the pages on the Handbook here....