lab_server/notes.md

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