Final touches

DECISIONS.md

@@ -6,10 +6,10 @@ Fill this in before you send your submission back — a few minutes is plenty. I
 
 ![showcase](https://uwu.stedos.dev/f/QV79RO)
 
-* A new `POST` endpoint was added to allow for the creation of mission launches. An example curl request for the new enpoint is:
-```console
+* A new `POST` endpoint was added to allow for the creation of mission launches. An example curl request for the new endpoint is:
+```sh
 curl --request POST \
-  --url http://localhost:5173/api/missions/551ba7ad-ce93-4539-9083-3b0ef337f011/launch \
+  --url http://localhost:5173/api/missions/551ba7ad-ce93-4539-9083-3b0ef337f011/launches \
   --header 'Content-Type: application/json' \
   --data '{
 	"scheduledFor": "2019-07-26T00:00:00",
@@ -18,7 +18,7 @@ curl --request POST \
 ```
 
 * The Mission -> Launch relationship is defined as one-to-many. Originally chose to have a one-one relationship, but changed after deciding that there could be more than one launch per mission (and makes the frontend look a little more interesting).
-* For the UI, I chose to have a table *within a table*, with an accordian element. It seems to work well, however could get a little cluttered if there are more entities related to Missions in the future.
+* For the UI, I chose to have a table *within a table*, with an accordion element. It seems to work well, however could get a little cluttered if there are more entities related to Missions in the future.
 * I chose to have the form as a pop-over on the table as the form was small enough, and it allows the user to have the context of the Mission they are adding the Launch to, which something like a modal doesn't do as well.
 
 ## Where AI helped, and what I accepted or rejected
@@ -65,7 +65,7 @@ There are definitely many things I would change for next time, or if I was to im
 
 #### Use more robust integration testing for the .NET tests.
 
- Whilst calling the endpoints directly is ok, it doesn't give you the full picture of how the endpoint is called in a real system. Things like the URL is omited (which is quite big for the `/missions/{MissionId}/launch` URL I have created), validation is not done on the endpoint directly and other HTTP pipelines are not triggered, such as middleware. The current tests are useful, but I would still maintain a large amount of full integration tests (including using [TestContainers](https://testcontainers.com/)) to ensure everything is working as expected as clients would be expecting. Also, as mentioned in the `ListMissionsTests` class, using SQLite as a stub/test database is not really representitive of a full DBMS as it does not support all the features that MSSQL does (making it not a great testbed!) - another reason I would use something like `TestContainers` for a full run-through.
+ Whilst calling the endpoints directly is ok, it doesn't give you the full picture of how the endpoint is called in a real system. Things like the URL is omitted (which is quite big for the `/missions/{MissionId}/launch` URL I have created), validation is not done on the endpoint directly and other HTTP pipelines are not triggered, such as middleware. The current tests are useful, but I would still maintain a large amount of full integration tests (including using something like [TestContainers](https://testcontainers.com/)) to ensure everything is working as expected as clients would be expecting. Also, as mentioned in the `ListMissionsTests` class, using SQLite as a stub/test database is not really representative of a full DBMS as it does not support all the features that MSSQL does (making it not a great testbed!) - another reason I would use something like `TestContainers` for a full run-through.
 
 #### Pagination/caching
 
@@ -73,7 +73,7 @@ When working on these small example datasets it's fine to have all the data bein
 
 #### Authentication
 
-Whilst this excersise does say that auth is omitted, it's always nessessary in web services.
+Whilst this exercise does say that auth is omitted, it's always necessary in web services.
 
 #### More restrictive validation
 
@@ -81,7 +81,7 @@ I have implemented very basic validation (I am a big fan of the `Validator<T>` p
 
 #### Moving database calls to a service layer
 
-Not every database call nessessarily needs to go in a service, but most will be used in multiple places (for example, checking if a `Mission` exists), which makes it a good candidate to extract out for better reuse. This also opens the door for mocking the service layer for testing, too - depending on how deep I'd want to go with unit testing.
+Not every database call necessarily needs to go in a service, but most will be used in multiple places (for example, checking if a `Mission` exists), which makes it a good candidate to extract out for better reuse. This also opens the door for mocking the service layer for testing, too - depending on how deep I'd want to go with unit testing.
 
 #### Have a look at the infra
 
@@ -95,7 +95,7 @@ I am a big fan of CI/CD pipelines. They are a great way to automate checking (ie
 
 #### Split out the Frontend components a little more
 
-Currently, the frontend componenets are a little too tightly coupled, and deal with a lot of external behaviour (such as data fetching). Allowing the top-level page/component to fetch the data and pass it down (or using a context) allows for data mocking much easier in tests, allows better re-usability, and makes components more focused.
+Currently, the frontend components are a little too tightly coupled, and deal with a lot of external behavior (such as data fetching). Allowing the top-level page/component to fetch the data and pass it down (or using a context) allows for data mocking much easier in tests, allows better re-usability, and makes components more focused.
 
 #### Add more tests