Create a Web API that will provide persistence to your JavaScript application (from task 5) using the latest .NET Framework (not .NET Core).
- Web API will (eventually) provide CRUD operations for items in your JS front-end
- Database provider might change at any time – has to be isolated in a single assembly
- Controllers have only and single responsibility – they react to user calls
- Dependency injection is a must (since you favor TDD, right)
- It is a simple application, so some simplifications are allowed (some are not):
- (OK) having a single assembly for all contracts and (single) DTO is perfectly OK
- (OK) dependency injection framework is referenced in all assemblies
- (BAD) having a public implementation of a contract is NOT OK → their implementation must be internal
- (BAD) having single assembly is NOT OK → (Web) API, (intra-assembly) contracts and database assemblies should emerge by now
- be as async as possible in controllers and services and repositories
- use Mongo DB as NoSQL storage provider. mLab is at your service (and for free) –
single assembly reference expected
- use Unity as Dependency Injection container –
all contract-implementing assemblies and API assembly reference expected
- use NUnit as test automation framework and NSubstitute as mocking framework –
only test assemblies reference expected
- do not use AutoMapper as this is not necessary for API of this size, however, get to know it at least theoretically
- Use newest (RC is permissible) version of Visual Studio – check out the link to ensure you are set-up correctly and leverage your R# license.
- Use Postman to tune (and debug) API calls
- Preferably work in pairs (strong preference)
- kentico-onboarding-cs sounds like a good name for the repository of yours (it is a terrible name for a solution, though ;-))
- Use this file as README of your repository
- Give write access to your peer and possible reviewers
- Commit correct .gitignore
- Use GitFlow workflow
- Commit to a feature branch ( features/task-0 in this case)
- There will be no upstream repository in this case
- Set-up continuous integration in the same way as in your JS repository (look at the CI part of JS task 0)
- Be careful about difference between Name and Solution name (the name should have .Api suffix)
- Use your default Git repository folder as Location
- Do not forget to Create directory for solution
- Check Add folders and core references for Web API
- Add unit tests, but do NOT check Host in the cloud
- Remove any empty classes, clean up the solution to contain only as much *.cs files as necessary
- Push your solution to your origin repository
- Create a pull-request to your develop branch
Learn what is REST
Learn what is NUnit
- motivation on constraint asserts (already familiart jest tests)
Learn why async
- All following actions can be "implemented" in the controller (for now)
- All controller actions are covered by tests (preferably use TDD)
- Provide list of (random static) items
- Add a new item
- Display item with given ID (whatever ID one provides, a predefined static item will be served)
- Delete item with given ID (whether it exists or not, it will act like it did)
- Change item with given ID (whether it exists or not, it will act like it did)
- Read a bit about versioning, its motivation, and differences of individual approaches
- Apply at least URL versioning in your dummy controller
(!) Important
- When you finish this task and your peer is not available, work on task Connect JS to CS from now on.
- Everybody needs to develop the functionality of Connect JS to CS on their own (and to their own JS onboarding repository) {panel}
Learn what is repository pattern
Learn what dependency injection or inversion of control or Holywood principle principles refer to and what Unity is
Learn what is NSubstitute
Extend your API with a dummy repository (database layer) that will be injected into controller (along with any other current dependencies)
- One might encounter problems with obtaining an instance of HttpRequestMessage outside API controller
- Repository itself and routing does not have to be covered by tests
- you will provide yourself with a database URL and username and password later in this task, let's looks on web application secrets topic and prepare our ground for them properly.
- Understand why a connection string must not be in code directly and should not be a part of database layer
- Make sure your connection string (or any other sensitive/instance-specific/secret information) is not checked-in in your public GitHub repository
- Store your secrets in web.config file of your presentation layer
- Sanitize your web.config based on this article
- Do not forget your connection string is a dependency
- Use mLab to create a sandbox NoSQL database
- Select the Azure cloud provider with the location in North Europe
- While replacing dummy repository's logic completely, implement only unconditional obtainment_ and _addition in API controller
- Make sure your controller's actions have a single responsibility and act on a single (highest) level of abstraction.
- Extend your model with two properties each representing date and time of model's creation_ and its _last update/change (these values will be sent through API to clients, however, it will not be consumed by your JS front-end in any way)
- Make sure (API) user input is sanitized (at least somewhat) properly
- If you have no service layer so far, there is something wrong – do not forget you write a simplified version of (somewhat large) multitier application with separated presentation
Finish remaining CRUD operations (update) and eventually (extra optional) patch
- ask <petrs2> to share Academy subscription with you
- prefix all your resources with your login (including resource group)
- be careful not create a resource that consumes money - let's start low and watch our expenses before first customers pay
- add Application Insights Telemetry
- do not use Visual Studio to create any resources, always use Azure portal
- be extra careful not create a resource that consumes money
- configure resource group and create/use (free) service plan in North Europe
- extend CI set-up of your CS repository so each push to the master branch triggers release
- alternatively set-up deployment options of the service plan for your CS repository on the Azure portal so each push to the master branch triggers release