generated from mwc/lab_server
81 lines
5.1 KiB
Markdown
81 lines
5.1 KiB
Markdown
# Project Server Notes
|
|
|
|
## Checkpoint 1
|
|
|
|
1. Lots of software today connects to remote servers, and can't work offline.
|
|
What are some advantages of using a program or an app which uses a remote
|
|
server? What are some advantages of using a program or an app which is
|
|
completely local?
|
|
# "By shifting data storage and processing from a local machine to a centralized server,
|
|
# users can access applications from anywhere, reduce hardware requirements,
|
|
# and ensure data consistency. [Client/server architecture] offers significant advantages
|
|
# regarding flexibility, performance, security, and maintenance." - Google Search
|
|
|
|
# Of course, if you lose the connection, you have to figure out how to get the connection
|
|
# back, so that you can perform all these tasks!
|
|
|
|
# "Advantages of a completely local app:
|
|
# 1) Superior data privacy and security 2) High performance and speed 3) Full offline functionality
|
|
# 4) Customization and control 5) Potential long-term cost savings -
|
|
# Data Control: Because data stays on your local device and is not sent to a cloud server,
|
|
# you have total control over who accesses it.
|
|
# Reduced Risk: The risk of data breaches or leaks, which are common with third-party,
|
|
# internet-connected servers, is significantly minimized.
|
|
# Confidentiality: For AI applications or sensitive documents, local processing ensures
|
|
# your input data is not used to train external models." - Google Search
|
|
|
|
|
|
2. You just ran a server on your own computer, and connected to it as a client
|
|
on the same computer. In what other situations might it be useful to run a
|
|
server on your computer, where you're the only client, on the same computer?
|
|
# It's useful to perform coding and data updates and maintenance, as Administrator.
|
|
# Many maintenance tasks require that ONLY the Administrator can connect, while nobody
|
|
# else is allowed to connect, to prevent the data from getting corrupted, or the program from crashing.
|
|
# Also, you can tell, if you're connecting as a regular client, if the program is running properly.
|
|
|
|
|
|
## Checkpoint 2
|
|
|
|
3. Choose a program (Steam), web app (Google Docs), or app (Weather) that you use
|
|
frequently. You can't observe the calls this program is making to its server
|
|
(unless you have fancy tools), but you can infer some of the calls based on the
|
|
program's behavior. Describe a few routes which you think may exist for your
|
|
chosen program's backend server.
|
|
# https://www.weather.gov/
|
|
# https://forecast.weather.gov/MapClick.php?lat=41.6523491&lon=-74.6956932 is a GET call.
|
|
# https://forecast.weather.gov/showsigwx.php?warnzone=NYZ062&warncounty=NYC105&firewxzone=NYZ208&local_place1=Monticello%20NY&product1=Winter+Storm+Warning&lat=41.6523&lon=-74.6957 is a GET call.
|
|
# There aren't any POST calls on this server from a regular client's point-of-view.
|
|
# However, obviously, this server and website are being constantly updated by a whole team of programmers
|
|
# who have certain rights and access. So, from a regular client's point-of-view,
|
|
# the data is viewed in "read-only" mode.
|
|
|
|
|
|
4. In your own words, what is an exception? When might it be useful to handle an
|
|
exception? When is it better not to handle an exception, and instead let the
|
|
program crash?
|
|
# An exception is more than invalid data. An exception should "handle" a data-type mismatch,
|
|
# an out-of-range input or a null input that causes a divide-by-zero process,
|
|
# and situations where the Internet connection fails during a "submit" of data for processing.
|
|
# According to Google Search, there are many scenarios where an exception should not or cannot
|
|
# be handled:
|
|
|
|
# "A program should crash immediately when it encounters an unrecoverable error,
|
|
# corrupted state, or illegal operation that threatens data integrity or system stability.
|
|
# Rather than continuing with incorrect data, crashing allows for immediate
|
|
# error identification and prevents further, more severe damage.
|
|
# Key Scenarios for a Program Crash:
|
|
# Data Corruption: When internal data structures become invalid, it is safer to crash than to risk saving corrupt data.
|
|
# Failed Invariants: When assertions fail (e.g., code reaches a spot that 'should never be reached'), the program should terminate.
|
|
# Unrecoverable Resource Depletion: Running out of critical resources like memory or disk space.
|
|
# Unexpected System State: When an operation occurs that the program is not designed to handle,
|
|
# such as unexpected hardware failures or missing critical files.
|
|
# Illegal Operations: Actions disallowed by the operating system, such as invalid memory access (segmentation faults) or division by zero.
|
|
# 'Crash Early' Principle:
|
|
# This philosophy encourages developers to make software fail loudly as soon as an unexpected event occurs,
|
|
# rather than masking the error and continuing in a broken state. This makes debugging easier and prevents
|
|
# invalid data from being processed.
|
|
# When NOT to Crash:
|
|
# Programs should not crash on routine, expected errors, such as invalid user input
|
|
# (e.g., text in a numeric field) or minor networking issues, but should instead handle them gracefully." - Google Search
|
|
|