Kurs från 2020-08-31 till 2020-10-08
Start: 2020-09-14
End - video presentation (stream): 2020-10-05 23:55
End - code (github): 2020-10-06 23:55
When traveling across space you once in a while need to park you spaceship and take a break, you do that at a spaceport. Managing all these parking at the spaceport is a bit of a job, so a special software for this is needed, one product handling this is called SpacePark, and is a parking system as a service for spaceports.
You have previously build a first version of the this parking system, and it’s now time to bring it to the masses, you need to get it out in the cloud and with a web UI.
You are the developer team at SpacePort Parking Systems AB and your assignment is to develop an service (a combination of frontend, backend and data) which register parking’s and close the sparceport when it’s full (and open when there is room, and only for spaceships which fits in).
All parking’s should be registered in a database, which is created using Entity Framework Core and code first. All queries to the database should be done using Entity Frameworks fluent API.
The twist to this is that this is an exclusive spaceport and ONLY famous space travelers which have been part of a Starwars movie can use the spaceport. The travelers should identify themselves when arriving, be able to pay before they can leave the parking lot and get an invoice in the end.
The travelers only use starships which have been part of a Starwars movie (see the endpoint /starships). They should be able to select their starship on arrival in the application.
The main focus on this solution is the cloud parts, more than it’s the application. (But the application is also important). The “cloud parts” includes CI / CD, deployment, hosting, costs, backup, security, scalability, integration tests, monitoring.
You are free to use IaaS offerings like virtual machines and PaaS offerings like App Service and Azure Functions, you just need to justify your choice based on cost, flexibility, vendor lock-in, stability, maintainability, scalability etc.
The database could be an Azure service like Azure SQL Server, Azure MariaDB or Azure CosmosDB (or maybe a combination of these).
Setting up the solution should be as automatized as possible using Containers, IaC (Pulumi) and scripts (preferable Powershell).
But it should be easy to develop, debug and test locally.
The application should be monitored in a way so it’s easy to understand what is the state of the service.
You can choose to take the code from one of the previous Spacepark projects, or start from scratch.
Compared to the first version should this project also contain a web frontend. This could be any solution, some suggestions is:
The API and the web frontend should be two different projects, they can be contained within the same solution (.sln), everything should be within the provided GitHub repo.
You should use the Starwars Web API: swapi.dev, to test if a visitor is part of a Starwars movie and lists of the Starwars you are not allowed to cache the data from the API, which mean that you will need to request the API each time you need to fetch data.
And remember to create unit tests, where possible.
A recommendation (but no requirement) is to use the Nuget package RestSharp for querying the API. You will need to implement the classes to be used by the build-in ORM in RestSharp.
var client = new RestClient("https://swapi.dev/api/");
var request = new RestRequest("people/", DataFormat.Json);
var peopleResponse = client.Get<Swreponse>(request);
Console.WriteLine(peopleResponse.Data.Count);
foreach (var p in peopleResponse.Data.Results)
{
Console.WriteLine(p.Name);
}
All request to the Starwars API should (unlike the example above) be made asynchronous.
This project can of course be started in many ways. But the recommended approach is:
Three important aspects of this project is documentation, automation and the code. In that order.
Hand in is done through your git repository, the repo should roughly put contain everything (please read: What should be in version control… and what should not).
Documentation
The description of the solution consist of both planning notes, thoughts behind your solution and description the inner working of the solution. All of this should be stored within a git repo. If you use other services provide a link, and some screenshots of the content.
If you are using any kind of external sources (both code and knowledge) make sure to mention this in the documentation.
All documentation should be written using markdown (.md), you are free to choose between writing in Swedish and English (but please make it consistent though the documentation).
Automation
Automate as much as possible through containers (Docker), IaC (Pulumi) and scripts.
Store the automation in the git repository.
Code
Everything should be kept within one git repository, hosted on GitHub.
Make use to split the code into several projects. You should have one or more solution files.
Video
You should produce a video presentation which describes the project.
You grading is to high extend based on this project!
Make sure to commit (and push) often! Use your own account.
Do as many branches you wish, bur in the end is it ONLY the content of you master branch which counts!
Elements which which is marked as important, gives a higher weight in your grading. And you should focus on these in your video presentation.
Please try to give an indication of whom have been involved in which parts.
This is the repos which where developed during project 3 in the Dataåtkomst course
The goal of the team is ALWAYS to deliver something at the deadline, and if the team is hit by absence and illness, the expected delivery is affected by this. But a requirement is is to make the instructor aware of this as early as possible.
Anybody who contributed or have missed out in somehow (like the video, or large parts of the project) can and will be given an alternative possibility to prove their skills and be evaluated (in order to parse the course).