Merge branch 'master' of github.com:thomasabishop/eolas
This commit is contained in:
commit
d0f25888b7
6 changed files with 115 additions and 209 deletions
23
zk/AWS_architecture_hierarchy.md
Normal file
23
zk/AWS_architecture_hierarchy.md
Normal file
|
@ -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 |
|
39
zk/Elastic_Compute_Cloud.md
Normal file
39
zk/Elastic_Compute_Cloud.md
Normal file
|
@ -0,0 +1,39 @@
|
||||||
|
---
|
||||||
|
id:
|
||||||
|
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.
|
102
zk/Events.md
102
zk/Events.md
|
@ -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<React.SetStateAction<Props["people"]>>
|
|
||||||
}
|
|
||||||
|
|
||||||
const AddToList = () => {
|
|
||||||
const [people, setPeople] = useState<IState["people"]>({})
|
|
||||||
const [formVals, setFormVals] = useState({});
|
|
||||||
|
|
||||||
const handleChange = (e: React.ChangeEvent<HTMLInputElement>): 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 (
|
|
||||||
<form>
|
|
||||||
<input type="text" name="name" value={input.name} onChange={handleChange} />
|
|
||||||
<input type="text" name="age" value={input.age} onChange={handleChange} />
|
|
||||||
</form>
|
|
||||||
<button onClick={handleClick}>Add to list</button>
|
|
||||||
);
|
|
||||||
};
|
|
||||||
```
|
|
||||||
|
|
||||||
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<HTMLButtonElement>) {
|
|
||||||
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
|
|
|
@ -1,5 +1,6 @@
|
||||||
---
|
---
|
||||||
tags: [AWS]
|
tags:
|
||||||
|
- AWS
|
||||||
---
|
---
|
||||||
|
|
||||||
# User management and roles
|
# User management and roles
|
||||||
|
@ -34,6 +35,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
|
lambda with a DynamoDB database. You could assign a role to the lambda and it
|
||||||
would have access to the database.
|
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
|
## Cognito
|
||||||
|
|
||||||
> Amazon Cognito provides authentication, authorization, and user management for
|
> Amazon Cognito provides authentication, authorization, and user management for
|
||||||
|
|
106
zk/events.md
106
zk/events.md
|
@ -1,106 +0,0 @@
|
||||||
---
|
|
||||||
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')
|
|
||||||
```
|
|
29
zk/virtual_private_cloud.md
Normal file
29
zk/virtual_private_cloud.md
Normal file
|
@ -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:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
- 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
|
Loading…
Add table
Reference in a new issue