Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added getting started to documentation #5500

Merged
merged 6 commits into from
Jan 12, 2022
Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -3,53 +3,7 @@ uid: tutorial-1
title: Part 1. Top-level Architecture
---

# Part 1: Top-Level Architecture

In this and the following chapters, we will build a sample Akka.NET application
Aaronontheweb marked this conversation as resolved.
Show resolved Hide resolved
to introduce you to the language of actors and how solutions can be formulated
with them. It is a common hurdle for beginners to translate their project into
actors even though they don't understand what they do on the high-level. We will
build the core logic of a small application and this will serve as a guide for
common patterns that will help to kickstart Akka.NET projects.

The application we aim to write will be a simplified IoT system where devices,
installed at the home of users, can report temperature data from sensors. Users
will be able to query the current state of these sensors. To keep things simple,
we will not actually expose the application via HTTP or any other external API,
we will, instead, concentrate only on the core logic. However, we will write
tests for the pieces of the application to get comfortable and proficient with
testing actors early on.

## Our Goals for the IoT System

We will build a simple IoT application with the bare essentials to demonstrate
designing an Akka.NET-based system. The application will consist of two main
components:

* **Device data collection:** This component has the responsibility to maintain
a local representation of the otherwise remote devices. The devices will be
organized into device groups, grouping together sensors belonging to a home.
* **User dashboards:** This component has the responsibility to periodically
collect data from the devices for a logged in user and present the results as
a report.

For simplicity, we will only collect temperature data for the devices, but in a
real application our local representations for a remote device, which we will
model as an actor, would have many more responsibilities. Among others; reading
the configuration of the device, changing the configuration, checking if the
devices are unresponsive, etc. We leave these complexities for now as they can
be easily added as an exercise.

We will also not address the means by which the remote devices communicate with
the local representations (actors). Instead, we just build an actor based API
that such a network protocol could use. We will use tests for our API everywhere
though.

The architecture of the application will look like this:

![box diagram of the architecture](/images/arch_boxes_diagram.png)

## Top Level Architecture
# Part 1: Top Level Architecture

When writing prose, the hardest part is usually to write the first couple of
sentences. There is a similar feeling when trying to build an Akka.NET system:
Expand Down Expand Up @@ -98,7 +52,7 @@ from user, or system, actors end up.
> has. This special entity is called the "Bubble-Walker". This special entity is
> invisible for the user and only has uses internally.

### Structure of an IActorRef and Paths of Actors
## Structure of an IActorRef and Paths of Actors

The easiest way to see this in action is to simply print `IActorRef` instances.
In this small experiment, we print the reference of the first actor we create
Expand Down Expand Up @@ -141,7 +95,7 @@ The last part of the actor reference, like `#1053618476` is a unique identifier
of the actor living under the path. This is usually not something the user needs
to be concerned with, and we leave the discussion of this field for later.

### Hierarchy and Lifecycle of Actors
## Hierarchy and Lifecycle of Actors

We have so far seen that actors are organized into a **strict hierarchy**. This
hierarchy consists of a predefined upper layer of three actors (the root
Expand Down Expand Up @@ -196,7 +150,7 @@ The family of these lifecycle hooks is rich, and we recommend reading [the actor
lifecycle](xref:untyped-actor-api#actor-lifecycle) section of the reference for
all details.

### Hierarchy and Failure Handling (Supervision)
## Hierarchy and Failure Handling (Supervision)

Parents and children are not only connected by their lifecycles. Whenever an
actor fails (throws an exception or an unhandled exception bubbles out from
Expand Down Expand Up @@ -240,7 +194,7 @@ see how the output changes.
For the impatient, we also recommend looking into the [supervision reference
page](xref:supervision) for more in-depth details.

### The First Actor
## The First Actor

Actors are organized into a strict tree, where the lifecycle of every child is
tied to the parent and where parents are responsible for deciding the fate of
Expand Down Expand Up @@ -280,7 +234,7 @@ All we need now is to tie this up with a class with the `main` entry point:
This application does very little for now, but we have the first actor in place
and we are ready to extend it further.

## What Is Next?
# What Is Next?

In the following chapters we will grow the application step-by-step:

Expand Down
57 changes: 57 additions & 0 deletions docs/articles/intro/getting-started/tutorial-overview.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
---
uid: tutorial-overview
Aaronontheweb marked this conversation as resolved.
Show resolved Hide resolved
title: Tutorial Overview
---

# Tutorial Overview

In this and the following chapters, we will build a sample Akka.NET application
to introduce you to the language of actors and how solutions can be formulated
with them. It is a common hurdle for beginners to translate their project into
actors even though they don't understand what they do on the high-level. We will
build the core logic of a small application and this will serve as a guide for
common patterns that will help to kickstart Akka.NET projects.

The application we aim to write will be a simplified IoT system where devices,
installed at the home of users, can report temperature data from sensors. Users
will be able to query the current state of these sensors. To keep things simple,
we will not actually expose the application via HTTP or any other external API,
we will, instead, concentrate only on the core logic. However, we will write
tests for the pieces of the application to get comfortable and proficient with
testing actors early on.

## Our Goals for the IoT System

We will build a simple IoT application with the bare essentials to demonstrate
designing an Akka.NET-based system. The application will consist of two main
components:

* **Device data collection:** This component has the responsibility to maintain
a local representation of the otherwise remote devices. The devices will be
organized into device groups, grouping together sensors belonging to a home.
* **User dashboards:** This component has the responsibility to periodically
collect data from the devices for a logged in user and present the results as
a report.

For simplicity, we will only collect temperature data for the devices, but in a
real application our local representations for a remote device, which we will
model as an actor, would have many more responsibilities. Among others; reading
the configuration of the device, changing the configuration, checking if the
devices are unresponsive, etc. We leave these complexities for now as they can
be easily added as an exercise.

We will also not address the means by which the remote devices communicate with
the local representations (actors). Instead, we just build an actor based API
that such a network protocol could use. We will use tests for our API everywhere
though.

The architecture of the application will look like this:

![box diagram of the architecture](/images/arch_boxes_diagram.png)

This tutorial is divided into four parts:

* [Part 1: Top-level Architecture](../getting-started/tutorial-1.html)
* [Part 2. The Device Actor](../getting-started/tutorial-2.html)
* [Part 3. Device Groups and Manager](../getting-started/tutorial-3.html)
* [Part 4. Querying a Group of Devices](../getting-started/tutorial-4.html)
10 changes: 10 additions & 0 deletions docs/articles/intro/tutorial-1.html
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
<!DOCTYPE html>
<html>
<head>
<title>Part 1. Top-level Architecture</title>
<meta http-equiv = "refresh" content="1;url=../intro/getting-started/tutorial-1.html" />
</head>
<body>
<p>This page has been moved to <a href="../intro/getting-started/tutorial-1.html">Part 1. Top-level Architecture</a>.</p>
</body>
</html>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this and the rest, this is for backward compatibility.

10 changes: 10 additions & 0 deletions docs/articles/intro/tutorial-2.html
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
<!DOCTYPE html>
<html>
<head>
<title>Part 2. The Device Actor</title>
<meta http-equiv = "refresh" content="1;url=../intro/getting-started/tutorial-2.html" />
</head>
<body>
<p>This page has been moved to <a href="../intro/getting-started/tutorial-2.html">Part 2. The Device Actor</a>.</p>
</body>
</html>
10 changes: 10 additions & 0 deletions docs/articles/intro/tutorial-3.html
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
<!DOCTYPE html>
<html>
<head>
<title>Part 3. Device Groups and Manager</title>
<meta http-equiv = "refresh" content="1;url=../intro/getting-started/tutorial-3.html" />
</head>
<body>
<p>This page has been moved to <a href="../intro/getting-started/tutorial-3.html">Part 3. Device Groups and Manager</a>.</p>
</body>
</html>
10 changes: 10 additions & 0 deletions docs/articles/intro/tutorial-4.html
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
<!DOCTYPE html>
<html>
<head>
<title>Part 4. Querying a Group of Devices</title>
<meta http-equiv = "refresh" content="1;url=../intro/getting-started/tutorial-4.html" />
</head>
<body>
<p>This page has been moved to <a href="../intro/getting-started/tutorial-4.html">Part 4. Querying a Group of Devices</a>.</p>
</body>
</html>
20 changes: 12 additions & 8 deletions docs/articles/toc.yml
Original file line number Diff line number Diff line change
Expand Up @@ -6,18 +6,22 @@
href: intro/what-problems-does-actor-model-solve.md
- name: Akka.NET Libraries and Modules
href: intro/modules.md
- name: Part 1. Top-level Architecture
href: intro/tutorial-1.md
- name: Part 2. The Device Actor
href: intro/tutorial-2.md
- name: Part 3. Device Groups and Manager
href: intro/tutorial-3.md
- name: Part 4. Querying a Group of Devices
href: intro/tutorial-4.md
- name: Use-case and Deployment Scenarios
href: intro/use-case-and-deployment-scenarios.md
- name: Production Users and Use Cases for Akka.NET
href: intro/akka-users.md
- name: Getting Started
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To put all tutorials under this section

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so rather than have one giant toc.yml here we should probably have each folder use its own toc.yml and then just reference that from the main articles/toc.yml - we need to add this as part of our DocFx Hygiene Guidelines

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it

items:
- name: Tutorial Overview
href: intro/getting-started/tutorial-overview.md
- name: Part 1. Top-level Architecture
href: intro/getting-started/tutorial-1.md
- name: Part 2. The Device Actor
href: intro/getting-started/tutorial-2.md
- name: Part 3. Device Groups and Manager
href: intro/getting-started/tutorial-3.md
- name: Part 4. Querying a Group of Devices
href: intro/getting-started/tutorial-4.md
- name: Concepts
items:
- name: Terminology, Concepts
Expand Down
26 changes: 2 additions & 24 deletions src/common.props
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
<PropertyGroup>
<Copyright>Copyright © 2013-2021 Akka.NET Team</Copyright>
<Authors>Akka.NET Team</Authors>
<VersionPrefix>1.4.28</VersionPrefix>
<VersionPrefix>1.4.32</VersionPrefix>
Aaronontheweb marked this conversation as resolved.
Show resolved Hide resolved
<PackageIcon>akkalogo.png</PackageIcon>
<PackageProjectUrl>https://github.com/akkadotnet/akka.net</PackageProjectUrl>
<PackageLicenseUrl>https://github.com/akkadotnet/akka.net/blob/master/LICENSE</PackageLicenseUrl>
Expand Down Expand Up @@ -32,29 +32,7 @@
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
</PropertyGroup>
<PropertyGroup>
<PackageReleaseNotes>Maintenance Release for Akka.NET 1.4**
Aaronontheweb marked this conversation as resolved.
Show resolved Hide resolved
Akka.NET v1.4.28 is a minor release that contains some enhancements for Akka.Streams and some bug fixes.
New Akka.Streams Stages**
Akka.NET v1.4.28 includes two new Akka.Streams stages:
[`Source.Never`](https://getakka.net/articles/streams/builtinstages.html#never) - a utility stage that never emits any elements, never completes, and never fails. Designed primarily for unit testing.
[`Flow.WireTap`](https://getakka.net/articles/streams/builtinstages.html#wiretap) - the `WireTap` stage attaches a given `Sink` to a `Flow` without affecting any of the upstream or downstream elements. This stage is designed for performance monitoring and instrumentation of Akka.Streams graphs.
In addition to these, here are some other changes introduced Akka.NET v1.4.28:
[Akka.Streams: `Source` that flattens a `Task` source and keeps the materialized value](https://github.com/akkadotnet/akka.net/pull/5338)
[Akka.Streams: made `GraphStageLogic.LogSource` virtual and change default `StageLogic` `LogSource`](https://github.com/akkadotnet/akka.net/pull/5360)
[Akka.IO: `UdpListener` Responds IPv6 Bound message with IPv4 Bind message](https://github.com/akkadotnet/akka.net/issues/5344)
[Akka.MultiNodeTestRunner: now runs on Linux and as a `dotnet test` package](https://github.com/akkadotnet/Akka.MultiNodeTestRunner/releases/tag/1.0.0) - we will keep you posted on this, as we're still working on getting Rider / VS Code / Visual Studio debugger-attached support to work correctly.
[Akka.Persistence.Sql.Common: Cancel `DBCommand` after finish reading events by PersistenceId ](https://github.com/akkadotnet/akka.net/pull/5311) - *massive* performance fix for Akka.Persistence with many log entries on SQL-based journals.
[Akka.Actor: `DefaultResizer` does not reisize when `ReceiveAsync` is used](https://github.com/akkadotnet/akka.net/issues/5327)
If you want to see the [full set of changes made in Akka.NET v1.4.28, click here](https://github.com/akkadotnet/akka.net/milestone/59).
| COMMITS | LOC+ | LOC- | AUTHOR |
| --- | --- | --- | --- |
| 16 | 2707 | 1911 | Sean Killeen |
| 8 | 1088 | 28 | Ismael Hamed |
| 6 | 501 | 261 | Gregorius Soedharmo |
| 5 | 8 | 8 | dependabot[bot] |
| 4 | 36 | 86 | Aaron Stannard |
| 1 | 1 | 0 | Jarl Sveinung Flø Rasmussen |
Special thanks for @SeanKilleen for contributing extensive Markdown linting and automated CI checks for that to our documentation! https://github.com/akkadotnet/akka.net/issues/5312</PackageReleaseNotes>
<PackageReleaseNotes>Placeholder for nightlies**</PackageReleaseNotes>
</PropertyGroup>
<!-- SourceLink support for all Akka.NET projects -->
<ItemGroup>
Expand Down