Net Centric
Net Centric
CSC 401
Distributed Computing is a much broader technology that has been around for more than three
decades now. Distributed computing is computing over distributed autonomous computers that
communicate only over a network. Distributed computing systems are usually treated differently
from parallel computing systems or shared-memory systems where multiple computers share a
common memory pool that is used for communication between the processors. Distributed memory
systems use multiple computers to solve a common problem, with computation
distributed among the connected computers (nodes) and using message- passing to communicate
between the nodes.
Example of distributed computing is the grid computing where the nodes may belong to different
administrative domains. Another example is the network-based storage virtualization solution which
uses distributed computing between data and metadata servers.
One of the main advantages of using distributed computing is that efficient scalable programs can be
designed so that independent processes are scheduled on different nodes and they communicate only
occasionally to exchange results – as opposed to working out of a shared memory with multiple
simultaneous accesses to a common memory.
It is obvious that cloud computing is also a specialized form of distributed computing, where
distributed Software as a Service (SaaS) applications utilize thin clients (such as browsers) which
offload computation to cloud-hosted servers (and services).
Distributed computing, virtualization, service orientation, and Web 2.0 form the core technologies
enabling the provisioning of cloud services from anywhere on the globe.
Distributed computing is a foundational model for cloud computing because cloud systems are
distributed systems. Besides administrative tasks mostly connected to the accessibility of resources
in the cloud, the
extreme dynamism of cloud systems—where new nodes and services are provisioned on demand—
constitutes the major challenge for engineers and developers.
3.0 Web 2.0 technologies
Web 2.0 technologies constitute the interface through which cloud computing services are delivered,
managed, and provisioned. Besides the interaction with rich interfaces through the Web browser,
Web services have become the primary access point to cloud computing systems from a
programmatic standpoint.
3.1 Service Orientations
Service orientation is the underlying paradigm that defines the architecture of a cloud computing
system. Cloud computing is often summarized with the acronym XaaS meaning, Everything-as-a-
Service—that clearly underlines the central role of service orientation. Infrastructure-as-a-Service
solutions provide the capabilities to add and remove resources, but it is up to those who deploy
systems on this scalable infrastructure to make use of such opportunities with wisdom and
effectiveness.
Platform-as-a-Service solutions embed into their core offering algorithms and rules that control the
provisioning process and the lease of resources. These can be either completely transparent to
developers or subject to fine control. Integration between cloud resources and existing system
deployment is another element of concern.
3.2 Virtualization
Virtualization is another element that plays a fundamental role in cloud computing. This technology
is a core feature of the infrastructure used by cloud providers. Virtualization concept is more than 40
years old but cloud computing introduces new challenges, especially in the management of virtual
environments, whether they are abstractions of virtual hardware or a runtime environment.
Mobile is a computing device that not require any network connection or any connection to transfer
data or information between devices. For example laptops, tablets, smartphones, etc. Mobile
computing allows transferring of the data/information, audio, video, or any other document without
any connection to the base or central network. These computing devices are the most widely used
technologies nowadays.
There are some wireless/mobile computing technologies given below:
1. Global System for Mobile Communications (GSM) :
GSM is a Current circuit-switched wireless data communication technology. It is established in
Europe by ETSI (European Telecommunications Standards Institute) in the mid-1980s. GSM
network has 4 different parks that who’s functions are different: Mobile Station, BSS (Base Station
Subsystem), NSS (Network Switching Subsystem), OSS (Operation and Support Subsystem).
As the name suggests, GSM is widely used for the mobile communication system. It operates in the
frequency band 900-MHz, 1800-MHz, and 1900-MHz. GSM is developed using TDMA (Time
Division Multiple Access) for better communication using mobile. It is the most widely used mobile
communication system and is mostly required nowadays. It can achieve maximum data transmission
speed or data transmission rate up to 9.6Kbps (Kilobits per second).
In this service, less time is required for communication. It does not require any Internet connection
for sending text messages. It allows the transmission of short messages i.e. up to 160 characters in
length. SMS uses standardized communication protocols. SMS is received by Short Message Service
Center (SMSC).
Figure 3.1 below shows the Internet and various devices connected to it wirelessly for
communication all over the world.
3.5.2 Smartphones
• It combines the features of a PDA with that of a mobile phone or camera
phone
• It has a superior edge over other kinds of mobile phones.
• Smartphones have the capability to run multiple programs concurrently
• These phones include high-resolution touch screens, web browsers that
can:
• access and properly display standard web pages rather than just mobile-
optimized sites
• high-speed data access via Wi-Fi and high speed cellular broadband.
• The most common mobile Operating Systems (OS) used by modern
smartphones include:
a. Google's Android
b. Apple's iOS
c. Nokia's Symbian
d. RIM's BlackBerry OS
e. Samsung's Bada
f. Microsoft's Windows Phone, and embedded Linux distributions such as Maemo
and MeeGo. Such operating systems can be installed on different phone models,
and typically each device can receive multiple OS software updates over its
lifetime.
4G is the fourth generation of broadband cellular network technology that precedes 5G. A 4G
system must provide capabilities defined by ITU in IMT Advanced. Recent applications include
amended mobile web access, IP telephony, gaming services, high-definition mobile TV, video
conferencing, and 3D television.
• WIMAX standard was first-released commercially and deployed in South Korea in 2006 and
has since been deployed in most parts of the world.
• Long Term Evolution (LTE) standard was first-released commercially and deployed in Oslo,
Norway, and Stockholm, Sweden in 2009, and has since been deployed throughout most
parts of the world. It was to be considered as 4G LTE. The 4G wireless cellular standard was
defined by the International Telecommunication Union (ITU) and specifies the key
characteristics of the standard, including transmission technology and data speeds.
3G or third generation
• 3G mobile telecommunications is a generation of standards for mobile phones and mobile
telecommunication services fulfilling the International Mobile Telecommunications-2000
(IMT-2000) specifications by the International Telecommunication Union. Application
services include wide-area wireless voice telephone, mobile Internet access, video calls
and mobile TV, all in a mobile environment.
Global Positioning System (GPS)
• The Global Positioning System (GPS) is a space-based satellite navigation system that
provides location and time information in all weather, anywhere on or near the Earth,
where there is an unobstructed line of sight to four or more GPS satellites
• The GPS program empowers the military, civil and commercial users around the world
• It (GPS) is the backbone for modernizing the global air traffic system, weather, and
location services.
Long Term Evolution (LTE)
• LTE is a standard for wireless communication of high-speed data for mobile phones and
data terminals
• It is based on the GSM/EDGE and UMTS/HSPA network technologies, increasing the
capacity and speed using new modulation techniques
• It is related with the implementation of fourth Generation (4G) technology.
WiMAX
• WiMAX (Worldwide Interoperability for Microwave Access) is a wireless
communications standard designed to provide 30 to 40 megabit-per-second data rates,
with the latest update providing up to 1 Gbit/s for fixed stations
• It is a part of a fourth generation or 4G wireless-communication technology
• WiMAX far surpasses the 30-metre wireless range of a conventional Wi-Fi Local Area
Network (LAN), offering a metropolitan area network with a signal radius of about 50 km
• WiMAX offers data transfer rates that can be superior to conventional cable-modem and
DSL connections, however, the bandwidth must be shared among multiple users and thus
yields lower speed in practice
Near Field Communication
• Near Field Communication (NFC) is a set of standards for smartphones and similar
devices to establish radio communication with each other by touching them together or
bringing them into close proximity, usually no more than a few centimeters
• Present and anticipated applications include contactless transactions, data exchange, and
simplified setup of more complex communications such as Wi-Fi. Communication is also
possible between an NFC device and an unpowered NFC chip, called a "tag"
NETWORK SECURITY
INTRODUCTION
The transmission of data from one point A on the network to the other point, B is a great
concern and therefore, there is the need to deploy measure that can secure the transmission
of data away from unauthorized individuals. Hence, the need for network security.
Network security is a term that describes the security tools, tactics and security policies
designed to monitor, prevent and respond to unauthorized network intrusion, while also
protecting digital assets, including network traffic. Network security includes hardware and
software technologies (including resources such as savvy security analysts, hunters, and
incident responders) and is designed to respond to the full range of potential threats
targeting your network.
Network security is the defense you use to protect yourself against ever- increasing
cybercrime.
The Three Key Focuses of Network Security
There are three key focuses that should serve as a foundation of any network security
strategy: protection, detection and response.
Protection entails any tools or policies designed to prevent network security intrusion.
Detection refers to the resources that allow you to analyze network traffic and quickly
identify problems before they can do harm.
Response is the ability to react to identified network security threats and resolve them as
quickly as possible.
CLIENT-SERVER COMPUTING
There are two configurations of networks: Client-Server and Peer-to-Peer networks. In
client server, the client requests resources while the server serves same. In Peer-to-peer
configuration, each node is free to communicate with others or not. The nodes under
this configuration are not over-seen by any node or the other, they relate in a
workgroup.
Client Server Computing
In client-server computing, the client requests a resource and the server provides that
resource. A server may serve multiple clients at the same time while a client is in
contact with only one server. Both the client and server usually communicate via a
computer network, as pictured in figure 1.4.1, but sometimes they may reside in the
same system.
The client server computing works with a system of request and response. The client
sends a request to the server and the server responds with the desired information.
The client and server should follow a common communication protocol so they can
easily interact with each other. All the communication protocols are available at the
application layer.
A server can only accommodate a limited number of client requests at a time. So it uses a
system based to priority to respond to the requests.
Denial of Service (DoS) attacks hinders servers’ ability to respond to authentic client
requests by inundating it with false requests.
An example of a client server computing system is a web server. It returns the web pages
to the clients that requested them.
1.2 Differences between Client-Server and Peer-to-Peer Computing
The major differences between client-server computing and peer-to-peer computing are
as follows:
In client server computing, a server is a central node that services many client nodes. On
the other hand, in a peer-to-peer system, the nodes collectively use their resources and
communicate with each other.In client server computing, the server is the one that
communicates with the other nodes. In peer-to-peer computing, all the nodes are equal
and share data with each other directly.
Client-Server computing is believed to be a sub-category of the peer-to-
peer computing.
1.3 Advantages of Client-Server Computing
All the required data is concentrated in a single place i.e. the server. So it is easy to
protect the data and provide authorisation and authentication.
The server need not be located physically close to the clients yet, the data can be
accessed efficiently.
It is easy to replace, upgrade or relocate the nodes in the client-server model because all
the nodes are independent and request data only from the server.
All the nodes i.e clients and server may not be built on similar platforms yet, they can
easily facilitate the transfer of data.
1.4 Disadvantages of Client Server Computing
If all the clients simultaneously request data from the server, it may get overloaded. This
may lead to congestion in the network.
If the server fails for any reason, then none of the requests of the clients can be fulfilled.
This leads to failure of the client-server network.
The cost of setting and maintaining a client-server model are quite high.
Discussion
What makes the Client Server configuration peculiar from the Peer-to- peer? Discuss
Characteristics of Client Server Computing
The characteristics of the client-server computing are as follows:
The client server computing works with a system of request and response.
The client sends a request to the server and the server responds with the
desired information.
The client and server should follow a common communication protocol
so they can easily interact with each other. All the communication
protocols are available at the application layer.
A server can only accommodate a limited number of client requests at a
time. So it uses a system based to priority to respond to the requests.
Denial of Service (DoS) attacks hinders servers’ ability to respond to
authentic client requests by inundating it with false requests.
An example of a client server computing system is a web server. It returns
the web pages to the clients that requested them.
BUILDING WEB APPLICATIONS
1.0 INTRODUCTION
A Web app
An interactive computer program, built with web technologies (HTML, CSS, JS),
which stores (Database, Files) and manipulates data (CRUD), and is used by a team or
single user to perform tasks over the internet. The HTML and the CSS serves as the
front-end to receive data from the user while the database, programming like Javascript
and PHP serves as the back-end.
2.0 INTENDED LEARNING OUTCOMES (ILOS)
At the end of this unit, students will able to:
Explain the concept of an App
Enumerate the prerequisite for building a web application
3.0 Describe the steps for building a web application
3.1 Building a Web Application (app)-Prerequisites for Building a Web
Application
To make a data-centric web app from the bottom-up, it is advantageous to understand:
Backend language (e.g. Python, Ruby) - control how your web app works
Web front end (HTML, CSS, Javascript) - for the look and feel of your web app
DevOps (Github, Jenkins) - Deploying / hosting your web app
If you do not have any experience with the points above, you need not worry. You have
two options:
1. Learn the points above - there are lots of resources online to help you. Codecademy is
recommend .
2. Use a web app builder like Budibase - As a builder, Budibase will remove the need to
learn a backend language. On top of that, Budibase will also take care of a lot of your
DevOps tasks such as hosting.
Nobody wants to experience that, so it is important to dive deep into the market and
source the wisdom of:
1. Your Web App’s target market - Share your web app idea on forums related to your
target market. If you know anyone who works within your target market, explain your
idea to them. The more you talk and receive validation from your target market, the
better.
2. Google Trends - A quick search of your web app idea will reveal relating trends.
3. SEO tool – MOZ/Ahrefs is recommended. Google’s keyword planner will suffice. Write
a list of keywords relating to your web app. If it is an ‘OKR tool’, use the tools to search
‘OKR tool’, ‘OKR app’, and ‘objectives and key results software’. If the SEO tool
indicates there are lots of people searching for your keyword terms, this is a small
indicator you have a target market.
4. Social Media - Jump over to Twitter/Facebook groups and present your idea to your
target market.
5. Events - If there is a local event in your area attracting people from your target market,
go to it. Share your idea and record the feedback.
After completing the above steps, you should have enough information to understand if
there is a market for your product. If there is a market for your product, and there is
also established competition, it is important to research them.
3.2.3 Step 3 - Define your web apps functionality
You have got your idea, you have validated the market, it is now time to list everything
you want your app to do. A common mistake here is to get carried away. The more
functionality you add, the longer it will take to build your web app. Quite often, the
longer a web app takes to build, the more frustration you will experience.
Only define functionality which solves your target markets problems. Remember, your
web app is a work in progress and the first goal is version
1. It will still have cool features and delight your users, but you must keep things
simple.
For direction, I have included a list of basic functions required for a simple CRM app.
Users can create an account
Users can retrieve lost passwords
Users can change their passwords
Users can create new contacts
Users can upload new contacts
Users can assign a value to contacts
Users can write notes under contacts
Users can label a contact as a lead, customer, or associate
Users can filter contacts by lead, customer, or associate
Users can view the total value of leads, customers and associates
The above list will help you define your features. Once you are done, roll up your
sleeves. It is time to get creative! Moving from the Ideation stage, to design stage.
3.2.4 Step 4 - Sketch your web app
There are multiple stages of designing a web app. The first stage is sketching using a
notebook (with no lines) and pen/pencil. After step 1, 2 and 3, you should have an idea
of what your web app is, who your users are, and the features it will have. Sketch out
the wireframe of your web apps UI (User Interface) - it does not have to be exact - this
is just a sketch. When sketching, consider the following:
Navigation
Branding
Forms
Buttons
Any other interactive elements
Sketch different versions of your web app. Consider how your web app’s functionality
will affect the overall design. Annotate your sketch and
outline how your app should work. Taking notes will help you clarify and understand
why you have designed certain elements at a later stage. Overcomplicating the design
at this stage will only lead to frustration.
After you have finished analysing your competitor’s web apps, it is time to write down
different workflows for your app. Consider the following points:
How does a user signup
Do they receive a verification email
How does a user log in
How does a user change their password
How does a user navigate through the app
How does a user change their user settings
How does a user pay for the app
How does a user cancel their subscription
All of a sudden our one-page web app turns into a 10-page web app. Write a list of all
the different pages your web application will have. Consider the different states of
pages. For example, the homepage will have two states; logged in and logged out.
Logged in users will see a different page than logged out users.
Ok, now you have got great feedback and product validation. It is time to start building
your web app.
A Database
A database is simply a collection of data! Data can be stored to disk, or in memory on a
server, or both. You could create a folder on your hard drive, store a few documents,
and call it a database. A Database Management System (DBMS) is a system that
provides you with consistent APIs to (most commonly):
Create databases, update and delete databases
Read and write data to databases
Secure access to a database by providing levelled access to different areas and functions
What data you need to store and what your users need to do, will determine the type of
database required to run your web app.
Database Types
There are many types of database for many different purposes. A web app will most
commonly use one of the following:
a. SQL
You should use a SQL database if your data is very relational. Your data is relational if
you have multiple, well defined record types that have relationships between them. For
example, a “Customer” may have many “Invoices” stored against their record.
Typically, you would create a Customer table and an Invoice table - which could be
linked together by “Foreign Key” columns. E.g. Customer.Id = Invoice.CustomerId.
SQL databases have an extremely powerful query language that allows you to present
your data in all sorts of useful ways. They have been around for decades, are very well
understood, and usually a safe choice.
MySQL, Postgresql, Microsoft SQLServer are some of the most common - along with
many more modern offerings.
The downside of SQL databases is that you must declare all your tables and columns
up front. There can be a lot of overhead to manage. If you have never used one before –
you are in for a pretty steep learning curve. However, there are plenty of learning
resources available, and it is always a great skill to have.
b. Document Database
You should use a document database if your data is not very relational. Document
databases store “documents”. Each record in your database is simply a big blob of
structured data - often in JSON format. If you need to store relationships between your
records, you will have to write code to manage this yourself. However, many other
aspects of using document databases are much simpler. Your database can be
“schemaless” - meaning that you do not have to declare your records’ definitions up
front. Generally speaking, the bar to entry to a document database is much lower. They
also tend to be much more scalable than SQL databases. They usually offer some
querying capabilities, although sometimes not as powerful as SQL. Examples of
document databases are: MongoDb, CouchDb, Firebase (serverless), Dynamo Db
(AWS).
Decide how to segregate your data
Each of your clients has their own, private dataset. One of the worst things that can
happen to your app is for one client’s data to be seen by another client.
Even if there is only a small amount of non-sensitive leaked data, and no damage is
done, an event like this will massively erode trust in the security of your app. You must
architect a solid strategy for segregating your clients’ data to make sure that this never
happens. Broadly speaking, you have two options - Physical Separation and Logical
Separation.
Physical separation
Every one of your clients has a separate database (although could share a database
server with others). This makes it much more difficult to make a mistake that leads to
data leakage.
Pros:
Most secure
More scalable
Cons:
Managing, maintaining and upgrading is more complex
Query all your clients’ data together is more difficult
For example, listing all Invoices in a database will only return Invoices for one of your
clients. In order to get another Client’s invoices, you need to connect to another
database.
Since each of your client’s data is in its own database, you can easily spread them all
across many database servers, without the need for “sharding”. Your app will be much
easier to scale this way.
The code you will need to write:
When creating a new client, you need to create a new database and populate with any
seed data.
You need to keep a record somewhere of all your clients, and how to connect to each
client’s database.
If you need to upgrade your database (e.g. add a new table), you need to code to upgrade
each separately.
If you need to query all your client’s data into one, you need to pull the data out of each
and aggregate it.
Logical separation
All of your clients are stored in one giant database. Every time you need to get data for
a single client, you must remember to include a filter for the client. E.g. ‘select’ from
customers where customerClientId = “1234” Pros:
Easier to get started
Easier to maintain and upgrade
Can easily query all your clients’ data with one query
Cons:
Easy to make a mistake that will result in a data breach
More difficult to scale
You now only have one database to manage. Setting this up and connecting to your
database is easy. Your speed to market increases. When you need to upgrade your
database, you can do so with a few clicks, or by typing a few commands. It is very easy
to add new features. As you gain more users, your database will grow to millions of
rows. Put some effort into how your database handles this extra volume and load. You
will have to start tuning your queries.
When you’re under pressure, it is so easy to forget to include that “where clientId =
1234” filter. Doing so could result in a business ending data breach.
Ensure your database is secured. You should look into best practices for securing
your particular database. Some databases come with a default administrator login,
which people often forget to change. This could leave your data open to the world.
From the start, you should create a login with “Just Enough” access. If your app only
reads and writes data, then it should authenticate to your database using a login with
only data reading and writing access.
A frontend
The Frontend is the visual element of your web application. It defines what you see and
interact with. The frontend is developed with HTML, CSS, and JavaScript.
If using server pages, getting started is super easy. Your backend framework is all set
up and ready to start building. This is where the huge benefit lies with server pages.
With SPA, it’s a little trickier.
First, you need to set up your development environment. The components of this will
be:
1. A code editor, such as VS Code, Sublime Text
2. A compilation, and packaging framework:
Webpack
Gulp
Grunt
This is also used for serving and “Hot Loading” your application at development time,
on a nodejs web server, running on localhost.
3. A frontend framework (strictly not necessary, but highly advised unless
you are an experienced frontend developer):
React
Ember
Vue
Svelte
The list is endless!
4. Configuring your packaging tool to talk to your backend - which is most likely running
on a different port on localhost. Usually, this is done using Node’s HTTP proxy. Most
packaging solutions have this option built-in, or available as plugins. This point
commonly gets people stuck, and may need a diagram. Remember - if you write your
backend API in C Sharp (for example) then at development time, you will be running it
on a local web server, through your code editor. i.e. your frontend and backend are
running on 2 different web servers, in development. However, in production, your
frontend should (probably) be running on the SAME web server as your backend -
mainly because you want them to run under the same domain.
This means a few things:
At dev (development) time, your frontend should make API requests to its own (Nodejs
server - e.g. Webpack dev server). This Nodejs server should then proxy all “/api”
request to your backend server.
When building for production, you need to get your compiled frontend files into your
backend server - so they can be served as static files. You can copy and paste the files in
when you deploy, but you will want to set up some sort of script to do this.
There is always a significant time required to set up your dev (development)
environment for a SPA. There are plenty of boilerplate templates out there for your
frameworks of choice. However, I have never written an app that has not eventually
needed some custom code on top of the boilerplate.
Still, I always choose a SPA.
The end product for a web app is a much more usable application.
When you are up and running with your dev environment, I find SPAs much more
productive to work with - which is more likely to do with the capabilities of modern
javascript frameworks than anything else.
Writing a SPA is really the only way to make a Progressive Web Application.
You should now have a better idea of how to setup your frontend and define the look
and feel of your web app. In most cases, I build the frontend and backend together.
“But is not this the frontend?” - I hear you say. Yes! But your choice will affect how
you develop your backend.
If you have chosen Server Pages, your backend will also be generating your frontend
and serving it to your user.
With a single page app, the backend will simply serve your static frontend files (i.e.
your “Single Page” and it is related assets).
When choosing your backend:
Go with what is familiar.
Try Budibase
Server Pages / SPA should inform your decision of framework choices
within your chosen language. For example, a SPA will only require an
API only framework. Server pages need their own framework.
o Django
o Express
o Flask
Login/User & Session Management
How will users authenticate?
o Username and password?
o Open ID (i.e. sign in as Google, FB, etc)
Be sure to read up on security best practices. I highly recommend:
OWASP
What user levels will you create in the system?
Environments. You will usually need to create multiple environments. For example:
Testing - for all the latest development features.
Beta - to give early releases to clients.
Production - Your live system.
Choosing one of these hosting options will almost certainly provide you with
everything you need. They have ample documentation and community supports, and
are generally reliable options.
3.2.13 Step 12 - Deploy your web app
You have sourced your idea, validated it, designed and developed your web app, and
chosen your hosting provider. You are now at the last step. Well done!
The deployment step includes is how your web application gets from your source
control on your computer to your cloud hosting from step 11. How does your
application get from Source Control / Your computer to your cloud hosting provider?
The following development tools provide continuous integration and will help you with
deploying your web app to your cloud hosting:
GitLab
Bitbucket
Jenkins
To start with, you can just deploy directly from your machine of course. You have
made a web application. Well done. You should take some time to celebrate this
achievement. You are the proud owner of a new web app.
Discussion
How can cybercrime be mitigated? Discuss
4.0 SELF-ASSESSMENT/EXERCISE
1. Mention and explain the Database types.
There are many types of database for many different purposes. A web app will most
commonly use one of the following:
a. SQL
You should use a SQL database if your data is very relational. Your data is relational if
you have multiple, well defined record types that have relationships between them. For
example, a “Customer” may have many “Invoices” stored against their record.
Typically, you would create a Customer table and an Invoice table - which could be
linked together by “Foreign Key” columns. E.g. Customer.Id = Invoice.CustomerId.
SQL databases have an extremely powerful query language that allows you to present
your data in all sorts of useful ways. They have been around for decades, are very well
understood, and usually a safe choice. MySQL, Postgresql, Microsoft SQLServer are
some of the most common - along with many more modern offerings.
The downside of SQL databases is that you must declare all your tables and columns
up front. There can be a lot of overhead to manage. If you have never used one before –
you are in for a pretty steep learning curve. However, there are plenty of learning
resources available, and it is always a great skill to have.
b. Document Database
You should use a document database if your data is not very relational. Document
databases store “documents”. Each record in your database is simply a big blob of
structured data - often in JSON format. If you need to store relationships between your
records, you will have to write code to manage this yourself. However, many other
aspects of using document databases are much simpler. Your database can be
“schemaless” - meaning that you do not have to declare your records’ definitions up
front.
Generally speaking, the bar to entry to a document database is much lower. They also
tend to be much more scalable than SQL databases. They usually offer some querying
capabilities, although sometimes not as powerful as SQL. Examples of document
databases are: MongoDb, CouchDb, Firebase (serverless), Dynamo Db (AWS).
2. What do we mean by the backend, the types and what determine your backend choice?
Explain.
The backend is typically what manages your data. This refers to databases, servers, and
everything the user cannot see within a web application. Building your backend is one
of the toughest parts of web app development. If you feel overwhelmed, a tool
like Budibase can take away many of the complexities - including the following tasks.
If you feel confident, continue.
When building your web app, you need to choose between:
Server Pages (Multiple Page Application) and
Single Page Application
“But is not this the frontend?” - I hear you say. Yes! But your choice will affect how
you develop your backend.
The primary jobs of the backend will be to:
o Provide HTTP endpoints for your frontend, which allow it to operate on your data. E.g.
Create, Read, Update and Delete (“CRUD”) records.
o Authenticate users (verify they are who they say they are: a.k.a log them in).
o Authorization. When a logged in user makes a request, the backend will determine
whether they are allowed (authorized) to perform the requested action.
o Serve the frontend
If you have chosen Server Pages, your backend will also be generating your frontend
and serving it to your user.
With a single page app, the backend will simply serve your static frontend files (i.e.
your “Single Page” and it is related assets).