Compare commits
2 Commits
953cb5dd33
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
| d93fa4e0dd | |||
| 9dc168f5e6 |
@@ -27,6 +27,8 @@ One difference in the Go version is that the `Store` shared a mutex between the
|
|||||||
|
|
||||||
I chose to keep the strong `DeviceId` in Go, even though it may be more idiomatic to keep it as a string, but I chose to lean more toward correctness, as a strong type allows better formatting, validation, etc. For this project, is it necessary? Not really, but it does make things a bit clearer, I think.
|
I chose to keep the strong `DeviceId` in Go, even though it may be more idiomatic to keep it as a string, but I chose to lean more toward correctness, as a strong type allows better formatting, validation, etc. For this project, is it necessary? Not really, but it does make things a bit clearer, I think.
|
||||||
|
|
||||||
|
One other note is that in C#, when I add a device uptime history, I return an Enum of Added | OutOfSequence. In Go, I return an `errors.New("heartbeat out of sequence")` and check on that since there aren't a lot of error types. This isn't an enum, discriminated union, or something with exhaustive checking, however.
|
||||||
|
|
||||||
### Things to consider
|
### Things to consider
|
||||||
**Security** - never heard of it! Nothing is authenticated, but I'd expect a device to have a signature that is set up before hand.
|
**Security** - never heard of it! Nothing is authenticated, but I'd expect a device to have a signature that is set up before hand.
|
||||||
|
|
||||||
@@ -52,6 +54,6 @@ re-implementing Prometheus/Grafana or something more custom. There are options l
|
|||||||
**Performance / Runtime Complexity** - in order to satisfy the metrics used for the return endpoint, a lot of the history is dropped and auto-aggregated. Maps are used to get the history of a device and the data is then appended. `sent_at` on `POST /stats` is ignored. This could allow duplicates, such as if a device implements a retry that didn't actually fail. There's also no concept of a Request ID to ensure idempotency. However, the complexity is O(1) for lookups and since unexpected out of sequence data is dropped, there's no attempt to rectify that something came in the past, as it's assumed to be invalid. This allows for much smaller complexity and simpler logic.
|
**Performance / Runtime Complexity** - in order to satisfy the metrics used for the return endpoint, a lot of the history is dropped and auto-aggregated. Maps are used to get the history of a device and the data is then appended. `sent_at` on `POST /stats` is ignored. This could allow duplicates, such as if a device implements a retry that didn't actually fail. There's also no concept of a Request ID to ensure idempotency. However, the complexity is O(1) for lookups and since unexpected out of sequence data is dropped, there's no attempt to rectify that something came in the past, as it's assumed to be invalid. This allows for much smaller complexity and simpler logic.
|
||||||
|
|
||||||
## Running the Simulator
|
## Running the Simulator
|
||||||
To run this project, clone it and be sure to copy the linux simulator into your directory [Linux ARM](https://sy-fleet-interview-assets.s3.us-east-2.amazonaws.com/device-simulator-linux-arm64) [Linux AMD](https://sy-fleet-interview-assets.s3.us-east-2.amazonaws.com/device-simulator-linux-amd64). It's not that I don't trust you guys, but I decided to run the simulator in docker instead of my native system.
|
To run this project, clone it and be sure to copy the linux simulator into your directory [Linux ARM](https://sy-fleet-interview-assets.s3.us-east-2.amazonaws.com/device-simulator-linux-arm64), [Linux AMD](https://sy-fleet-interview-assets.s3.us-east-2.amazonaws.com/device-simulator-linux-amd64). I used the arm image, so you'll have to change the docker to reference the filename that you're using if you use AMD64. It's not that I don't trust you guys, but I decided to run the simulator in docker instead of my native system.
|
||||||
|
|
||||||
To run the Go version, run `docker compose up --build`, for the dotnet version, run `docker compose -f docker-compose.dotnet.yml up --build`. The output will be written to the `output` folder at the root.
|
To run the Go version, run `docker compose up --build`, for the dotnet version, run `docker compose -f docker-compose.dotnet.yml up --build`. The output will be written to the `output` folder at the root.
|
||||||
Reference in New Issue
Block a user