From 506aecf4d576922c63e3d7c7fa1ab4e3424e12ac Mon Sep 17 00:00:00 2001 From: thomasabishop Date: Mon, 19 Feb 2024 08:28:35 +0000 Subject: [PATCH 1/6] save events --- zk/events.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/zk/events.md b/zk/events.md index cd7076d..dba2c0e 100644 --- a/zk/events.md +++ b/zk/events.md @@ -1,4 +1,6 @@ --- +id: events +aliases: [] tags: - backend - node-js @@ -15,12 +17,10 @@ Another way of putting this is to say that all events in Node inherit from the event. At bottom everything in Node is an event with a callback, created via event emitters. -Because Node's runtime is -[event-driven](Event_loop.md), it is -event-emitter cycles that are being processed by the Event Loop, although you -may know them as `fs` or `http` (etc) events. The call stack that the Event Loop -works through is just a series of event emissions and their associated -callbacks. +Because Node's runtime is [event-driven](Event_loop.md), it is event-emitter +cycles that are being processed by the Event Loop, although you may know them as +`fs` or `http` (etc) events. The call stack that the Event Loop works through is +just a series of event emissions and their associated callbacks. ## Event Emitters From ce3c352ce63c7c9ca8e626a46351db266051b0c3 Mon Sep 17 00:00:00 2001 From: thomasabishop Date: Mon, 19 Feb 2024 08:28:59 +0000 Subject: [PATCH 2/6] sort conflict --- zk/Events.md | 102 ------------------------------------------------- zk/events.md | 106 --------------------------------------------------- 2 files changed, 208 deletions(-) delete mode 100644 zk/Events.md delete mode 100644 zk/events.md diff --git a/zk/Events.md b/zk/Events.md deleted file mode 100644 index 2ec3671..0000000 --- a/zk/Events.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -tags: - - typescript - - react ---- - -# Events - -Building on the previous examples for React TypeScript we are going to add a -simple form that enables the user to add people to the list. This will -demonstrate how we type components that use event handlers. - -We are going to use the preexisting interface for recording the list items: - -```tsx -interface IState { - people: { - name: string; - age: number; - }[]; -} -``` - -Our form: - -```ts -import {IState as Props}; -``` - -```tsx - -interface IProps { - people: Props["people"] - setPeople: React.Dispatch> -} - -const AddToList = () => { - const [people, setPeople] = useState({}) - const [formVals, setFormVals] = useState({}); - - const handleChange = (e: React.ChangeEvent): void => { - setFormValues({ - ...input, - [e.target.name]: e.target.value, - }); - }; - - const handleClick = (): void => { - if (!input.name || !input.age) return - - setPeople({ - ...people, - { - name: input.name, - age: input.age - } - }) - } - -return ( -
- - -
- - ); -}; -``` - -This follows standard practise for -[controlled-components](Forms.md). The TS -specific additions: - -- We define the change event as being of the type `React.ChangeEvent` and state - that it corresponds to a generic - `HTMLInputElement`. So we are saying that - whenever this function is called we must be passing it an input element so - that we can extract the event associated with its `target` property. - -- We are passing around variations on the `IState` interface in order to type - the values that we are adding to the people array. - -## Further standard types for event handling - -### onClick - -```tsx -handleClick(event: MouseEvent) { - event.preventDefault(); - alert(event.currentTarget.tagName); -} -``` - -### onSubmit - -```tsx -handleSubmit(e: React.SyntheticEvent) { - event.preventDefault(); -} -``` - -> Most event types and their associated generics will be revealed by VS Code -> Intellisense so you don't need to memorize them all diff --git a/zk/events.md b/zk/events.md deleted file mode 100644 index dba2c0e..0000000 --- a/zk/events.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -id: events -aliases: [] -tags: - - backend - - node-js ---- - -# Node.js `events` module - -In most cases you won't interact with the `events` module directly since other -modules and third-party modules are abstractions on top of it. For instance the -`http` module is using events under the hood to handle requests and responses. - -Another way of putting this is to say that all events in Node inherit from the -`EventEmitter` constructor, which is the class you instantiate to create a new -event. At bottom everything in Node is an event with a callback, created via -event emitters. - -Because Node's runtime is [event-driven](Event_loop.md), it is event-emitter -cycles that are being processed by the Event Loop, although you may know them as -`fs` or `http` (etc) events. The call stack that the Event Loop works through is -just a series of event emissions and their associated callbacks. - -## Event Emitters - -- All objects that emit events are instances of the `EventEmitter` class. This - object exposes an `eventEmitter.on()` function that allows one or more - functions to be attached to named events emitted by the object. -- These functions are **listeners** of the emitter. - -## Basic syntax - -```js -const EventEmitter = require("events"); // import the module - -// Raise an event -const emitter = new EventEmitter("messageLogged"); - -// Register a listener -emitter.on("messagedLogged", function () { - console.log("The listener was called."); -}); -``` - -- If we ran this file, we would see `The listener was called` logged to the - console. -- Without a listener (similar to a subscriber in Angular) nothing happens. -- When the emission occurs the emitter works _synchronously_ through each - listener function that is attached to it. - -## Event arguments - -- Typically we would not just emit a string, we would attach an object to the - emitter to pass more useful data. This data is called an **Event Argument**. -- Refactoring the previous example: - -```js -// Raise an event -const emitter = new EventEmitter("messageLogged", function (eventArg) { - console.log("Listener called", eventArg); -}); - -// Register a listener -emitter.on("messagedLogged", { id: 1, url: "http://www.example.com" }); -``` - -## Extending the `EventEmitter` class - -- It's not best practice to call the EventEmitter class directly in `app.js`. If - we want to use the capabilities of the class we should create our own module - that extends `EventEmitter`, inheriting its functionality with specific - additional features that we want to add. -- So, refactoring the previous example: - -```js -// File: Logger.js - -const EventEmitter = require("events"); - -class Logger extends EventEmitter { - log(message) { - console.log(message); - this.emit("messageLogged", { id: 1, url: "http://www.example.com" }); - } -} -``` - -_The `this` in the `log` method refers to the properties and methods of -`EventEmitter` which we have extended._ - -- We also need to refactor our listener code within `app.js` so that it calls - the extended class rather than the `EventEmitter` class directly: - -```js -// File app.js - -const Logger = require('./Logger') -const logger = new Logger() - -logger.on('messageLogged', function(eventArg){ - console.log('Listener called', eventArg) -} - -logger.log('message') -``` From 6628aae8e923ea52def02ef29801c6ed49543860 Mon Sep 17 00:00:00 2001 From: thomasabishop Date: Mon, 19 Feb 2024 19:38:34 +0000 Subject: [PATCH 3/6] aws: notes on architecting --- zk/Elastic_Compute_Cloud.md | 40 ++++++++++++++++++++++++++++++++++++ zk/User_management_on_AWS.md | 27 +++++++++++++++++++++++- 2 files changed, 66 insertions(+), 1 deletion(-) create mode 100644 zk/Elastic_Compute_Cloud.md diff --git a/zk/Elastic_Compute_Cloud.md b/zk/Elastic_Compute_Cloud.md new file mode 100644 index 0000000..d8c99cf --- /dev/null +++ b/zk/Elastic_Compute_Cloud.md @@ -0,0 +1,40 @@ +--- +id: Elastic_Compute_Cloud +aliases: [] +tags: + - AWS + - vm +created: Monday, February 19, 2024 | 18:58 +last_modified: Monday, February 19, 2024 | 18:58 +since: just now +title: Elastic Compute Cloud (EC2) +--- + +# Elastic Compute Cloud (EC2) + +- Cloud-based or virtual server (virtual machine), basically a hypervisor + (compare [[zk/Docker_architecture]]) +- It is virtual because you are not responsible for its physical implementation +- Still needs considerable configuration compared to a serverless + [[zk/Lambda_programming_model]] +- Like lambdas has the benefit of easy scaling: you can add compute capacity on + demand (elasticity) + +The following needs to be considered: + +- Naming +- Application and OS image (known as "Amazon Machine Image"): + - Which OS you want to use (Linux distribution, Windows, etc) + - Applications you want pre-installed + - Block device mapping +- Instance type an size (basically the type of processor and how powerful you + want it to be) +- An encrypted key-pair for login +- Your network (typically managed via Amazon VPC (Virtual Private Cloud)) and + network security +- Storage: size and type (eg. GP3) +- Location and latency + +> EC2 is more expensive copared to serverless options. Accordingly it is better +> to run smaller servers (in terms of processor and memory) at higher capacity +> than larger servers under-capacity. diff --git a/zk/User_management_on_AWS.md b/zk/User_management_on_AWS.md index f45e9b7..424f394 100644 --- a/zk/User_management_on_AWS.md +++ b/zk/User_management_on_AWS.md @@ -1,5 +1,8 @@ --- -tags: [AWS] +id: User_management_on_AWS +aliases: [] +tags: + - AWS --- # User management and roles @@ -34,6 +37,28 @@ such as an S3 bucket or a DynamoDB table. Say you have a service that combines a lambda with a DynamoDB database. You could assign a role to the lambda and it would have access to the database. +## Distinction between _principal_ and _identity_ + +Both “principal” and “identity” refer to entities that can perform actions and +interact with AWS resources. However, there is a subtle difference in their +usage: + +> a principal is a specific type of entity that can take actions in AWS, while +> an identity is the unique identifier associated with that principal. + +1. Principal: In the context of IAM policies, a principal represents the entity + that is allowed or denied access to AWS rThe principal is specified in the + policy statement as the entity to which the permissions are granted or + deniedesources. It can be an IAM user, an IAM role, an AWS service. The + principal is specified in the policy statement as the entity to which the + permissions are granted or denied. +2. Identity: An identity, on the other hand, is a broader term that encompasses + both the principal and the authentication credentials associated with that + principal. It refers to the entity’s unique identifier, such as an IAM user’s + username or an IAM role’s ARN (Amazon Resource Name). An identity is used for + authentication purposes to verify the entity’s identity and determine its + permissions. + ## Cognito > Amazon Cognito provides authentication, authorization, and user management for From 7721519b5692e46f3d16d2add52bac21b9253f3d Mon Sep 17 00:00:00 2001 From: thomasabishop Date: Mon, 19 Feb 2024 19:39:19 +0000 Subject: [PATCH 4/6] aws: more notes on architecture --- zk/AWS_architecture_hierarchy.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 zk/AWS_architecture_hierarchy.md diff --git a/zk/AWS_architecture_hierarchy.md b/zk/AWS_architecture_hierarchy.md new file mode 100644 index 0000000..d13da79 --- /dev/null +++ b/zk/AWS_architecture_hierarchy.md @@ -0,0 +1,23 @@ +--- +id: oyubuqx2 +title: AWS architecture hierarchy +tags: [AWS] +created: Monday, February 19, 2024 | 19:17 +since: just now +last_modified: Monday, February 19, 2024 | 19:17 +--- + +# AWS architecture hierarchy + +From bottom up: + +```mermaid +flowchart TD + Data centres --> Availability Zones--> Regions +``` + +| Entity | Description | +| ------------------ | ------------------------------- | +| Data center | Warehouse full of servers | +| Availability Zones | A cluster of data centers | +| Region | A cluster of Availability Zones | From 63206e863e848dbaa14618bd03dfa42defea614f Mon Sep 17 00:00:00 2001 From: thomasabishop Date: Tue, 20 Feb 2024 08:28:46 +0000 Subject: [PATCH 5/6] refactor: remove automated frontmatter insertion --- zk/Elastic_Compute_Cloud.md | 3 +-- zk/User_management_on_AWS.md | 2 -- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/zk/Elastic_Compute_Cloud.md b/zk/Elastic_Compute_Cloud.md index d8c99cf..2194ab7 100644 --- a/zk/Elastic_Compute_Cloud.md +++ b/zk/Elastic_Compute_Cloud.md @@ -1,6 +1,5 @@ --- -id: Elastic_Compute_Cloud -aliases: [] +id: tags: - AWS - vm diff --git a/zk/User_management_on_AWS.md b/zk/User_management_on_AWS.md index 424f394..7661690 100644 --- a/zk/User_management_on_AWS.md +++ b/zk/User_management_on_AWS.md @@ -1,6 +1,4 @@ --- -id: User_management_on_AWS -aliases: [] tags: - AWS --- From 6c570f8e37ba9311f6ee0e82f82c493c111ea9a9 Mon Sep 17 00:00:00 2001 From: thomasabishop Date: Tue, 20 Feb 2024 08:44:07 +0000 Subject: [PATCH 6/6] aws: notes on VPC --- zk/virtual_private_cloud.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 zk/virtual_private_cloud.md diff --git a/zk/virtual_private_cloud.md b/zk/virtual_private_cloud.md new file mode 100644 index 0000000..52c11ca --- /dev/null +++ b/zk/virtual_private_cloud.md @@ -0,0 +1,29 @@ +--- +id: mdw5fe5a +title: Virtual Private Cloud +tags: [AWS, networks] +created: Tuesday, February 20, 2024 | 08:31 +since: just now +last_modified: Tuesday, February 20, 2024 | 08:31 +--- + +# Virtual Private Cloud + +AWS VPC is used to create a virtual network. This is typically used in concert +with [[zk/Elastic_Compute_Cloud]] to manage connections to a virtual server both +privately and accross the internet. + +You define a network address range and then create subnets for managing +different connections and functionality. You use a public subnet for resources +that must be connected to the internet and a private subnet for resources that +are to remain isolated from the internet. + +The diagram below details a basic VPC configuration: + +![](../img/aws-vpc-example.png) + +- Within a given AWS region we have created a VPC network. +- This comprises public and private subnets +- Both subnets host an EC2 instance +- The public subnet has a bridge to the internet through the Internet Gateway +- Both subnets have a routing table to manage requests and access