jasterv/jaster.xyz
1
0
Fork 0
mirror of https://codeberg.org/JasterV/jaster.xyz.git synced 2026-04-26 18:10:01 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Be more consistent with the word Door server

Browse source
This commit is contained in:
JasterV 2025-06-05 22:37:34 +02:00
parent c39914d979
commit c8f247dcce
1 changed files with 5 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
src/content/blog/DecouplingElixirGenServers.md
View file

@ -26,7 +26,7 @@ Finally, when the door gets unlocked, we want a light to become green and get no
The application consists of: The application consists of:
- A GenServer that manages the state of the Door and is responsible for locking or unlocking it. - A GenServer that manages the state of the door and is responsible for locking or unlocking it.
- A module that manages the state of the lights and is responsible for changing colors. - A module that manages the state of the lights and is responsible for changing colors.
- A module that manages notifications. - A module that manages notifications.
@ -67,7 +67,7 @@ firmware.notifications -> third_party_notifications_service: send_notification {
</div> </div>
In this post we will focus on the firmware layer, more specifically in the Door server, its implementation and tests. In this post we will focus on the firmware layer, more specifically in the DoorServer, its implementation and tests.
## Let's get into code ## Let's get into code
@ -131,7 +131,7 @@ defmodule DoorAutomation.DoorServer do
end end
``` ```
For the purpose of this article, the underlying calls that the Door Server would need to make to the Hardware are left out of the code. For the purpose of this article, the underlying calls that the DoorServer would need to make to the Hardware are left out of the code.
### Let's write some tests ### Let's write some tests
@ -194,7 +194,7 @@ In this case, if a user locks the door but the lights don't work or the notifica
Ideally, any issues that might occur related to the lights or notifications system should be handled in their own modules. Ideally, any issues that might occur related to the lights or notifications system should be handled in their own modules.
Our door server should simply worry about locking or unlocking a door. The DoorServer should simply worry about locking or unlocking a door.
Coupling these modules spreads complexity that should be isolated. Coupling these modules spreads complexity that should be isolated.
@ -210,7 +210,7 @@ Each time we add a new side effect that doesn't necessarily have to do with lock
## So, what can we do? ## So, what can we do?
We want to find a way to decouple our door server from the rest of the system and protect it from unrelated issues. We want to find a way to decouple the DoorServer from the rest of the system and protect it from unrelated issues.
I'm sure there are many ways you could do this, but in this article I want to talk about a specific one I recently deployed to production with success. I'm sure there are many ways you could do this, but in this article I want to talk about a specific one I recently deployed to production with success.
@ -226,7 +226,6 @@ This automatically makes our application more flexible, testable and maintainabl
Let's look at a diagram of the new target architecture: Let's look at a diagram of the new target architecture:
<div class="diagram" align="center"> <div class="diagram" align="center">
```d2 width="500" theme=303 title="event-driven architecture diagram" ```d2 width="500" theme=303 title="event-driven architecture diagram"