![\"VedaVersum](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild1-3.png\")
VedaVersum card entity<\/p><\/div>\r\n
For the moment this mutation and 3 queries are not implemented and don\u2019t do any relevant actions with our entity. Now it is time to choose which database to use for keeping our cards list. We have a lot of options here. We can use relational database like Oracle or MS SQL Server. But these are industrial giants purposed at working under high load and operate hundreds transactions per second. The lightweight SQLite<\/a> is more suitable for small applications. Main advantages of SQLite are as follows:<\/p>\r\n But from the other hand as every relational database, SQLite requires to define strongly-typed database scheme. For example, in our VedaVersum<\/em> entity we can define some other properties like \u201cArchived\u201d flag in the future. In case of relational database this is a breaking change which requires some efforts to provide scheme migrations with already existing database. They are justified if we have rich good-structured denormalized data model which is not changing too often. But in our case VedaVersum<\/em> entities it\u2019s just a list of documents. NoSQL database is perfect database to store the lists of documents. That\u2019s why we will use MongoDB<\/a>. This is the main player in the world of NoSQL databases. It is free and open-source. It stores data as list of JSON documents and does not require strongly-typed database scheme. And it provides high performance, scaling and backup tools such as all serious databases.<\/p>\r\n If you never used Mongo in your development machine, first you should install database engine. Here are some instructions how you can do this<\/a>. I use Docker desktop<\/a> on my machine and have MongoDB started as docker container.<\/p>\r\n As soon as we have MongoDB engine up and running, we can use it in our project. There is a MongoDB driver for dotNet<\/a> which we will use in our project, so first we should add a Nuget package<\/a> to our project.<\/p>\r\n Secondly, we should add a new parameter to our appsettings.json<\/em> with the connection string<\/a>.<\/p>\r\n And thirdly, we should define a new interface IVedaVersumDataAccess<\/em><\/strong> and VedaVersumDataAccess <\/em><\/strong>service which implements this interface.<\/p>\r\n We have defined the data access interface with CRUD operations. We will use this interface in our mutation and queries. And here I am briefly describing the implementation of data access itself.<\/p>\r\n VedaVersumDataAccess.cs<\/a><\/p>\r\n\r\n\r\n startup.cs<\/p>\r\n\r\n\r\n You can find full code in GitHub<\/a> repository. As you can see, it\u2019s pretty simple to use MongoDB in ASP.Net core application. And here are our API methos working:<\/p>\r\n\r\n\r\n\r\n Create Card:<\/p>\r\n\r\n\r\n\r\n Read All Cards:<\/p>\r\n\r\n\r\n\r\n Update card:<\/p>\r\n\r\n\r\n\r\n We have implemented data persistence in our application! Yay!<\/p>\r\n\r\n\r\n\r\n Now it\u2019s time to talk a little bit about data objects cross references and performance. As you have already noticed, every knowledge card has a list of related card Ids. The cards are stored in the database with this structure:<\/p>\r\n\r\n\r\n\r\n So, \u201ccard two\u201d references the \u201ccard one\u201d, \u201ccard three\u201d references \u201ccards two and one\u201d and so on. If we are fetching all cards, maybe it\u2019s not a big problem. But what if client app wants to request only \u201ccard three\u201d and all its dependencies, our query will look like this:<\/p>\r\n\r\n\r\n\r\n For related cards we have only Ids and to get their content the client should call the same query two more times. And if there are more than two related cards, number of requests from client to server dramatically increases. This situation is usual for REST API and called \u201cn+1 problem\u201d.<\/p>\r\n\r\n\r\n\r\n Fortunately, one of the GraphQL tasks is the ability to eliminate this n+1 problem. We can define some query hook called Resolver<\/em><\/strong>. This resolver allows client to fetch all related objects at one request. Let\u2019s add this resolver<\/a> to our GraphQL API for related cards:<\/p>\r\n\r\n\r\n This object type extends our VedaVersumCard<\/em><\/strong> object adding a new field to it. And implements the logic of filling this field. Now we must add this new object type definition to our GraphQL server setup at startup.cs<\/strong>.<\/p>\r\n\r\n\r\n\r\n <\/p>\r\n\r\n\r\n\r\n And we can run our query again:<\/p>\r\n\r\n\r\n\r\n As you could notice, there is an additional field in the query called \u201crelatedCards\u201d, and we can get all related cards information just using single request to GraphQL server. So, we have just got rid of our n+1 problem. Bingo!<\/p>\r\n\r\n\r\n\r\n There is one more point. GraphQL allows both to query related data by single request and to construct the query the way that the same API method can be called multiple times with different parameters but using only one request. For instance, the client application has the IDs of three cards. The client can construct the query to get the details of all 3 cards using this query:<\/p>\r\n\r\n\r\n\r\n It works perfectly. I can get any data I want without the above-mentioned n+1 problem. But if I were curious and attached a logger to the MongoDB client, I could see that GraphQL server made 3 subsequent requests to the database with that single request.<\/p>\r\n\r\n\r\n\r\n Let\u2019s take a look again to our query method:<\/p>\r\n\r\n\r\n In spite of the single query to GraphQL, the resolver is executed each time for each ID. And each time it uses the data access to fetch one card from DB. So, n+1 problem still exists, but inside of our backend server.<\/p>\r\n\r\n\r\n\r\n Fortunately, GraphQL can handle this problem too. There is another concept called DataLoader<\/strong>. And here we can implement<\/a> it:<\/p>\r\n\r\n\r\n So, under the hood the GraphQL query parser can get all CardIds during single GraphQL query and use this DataLoader<\/strong> to execute batch database query. Let\u2019s apply this data Loader to our query resolver:<\/p>\r\n\r\n\r\n Now we can execute this GraphQL query once again:<\/p>\r\n\r\n\r\n\r\n And look into the logs:<\/p>\r\n\r\n\r\n\r\n There is only one batch query. Cool, we have eliminated the n+1 problem at all levels and client can use our GraphQL API with different query combinations with optimal performance.<\/p>\r\n\r\n\r\n\r\n At this point backend service has already been put to work. That\u2019s great! And while we were developing everything, we used to start the application and check if authorization works, if persistence works, if queries, mutations, and subscription work. And of course, we had to ensure all services and their dependencies to be properly set up. We were doing all these activities using \u201cStrawberry Shake\u201d IDE for GraphQL queries. When we develop UI, we will check some UI activities, user scenarios and how everything works together with backend running. At the development phase we do it manually and \u201coccasionally\u201d. We don\u2019t cover every scenario and use case. This is called \u201csmoke testing\u201d \u2013 just to check if application starts at least and can pass main scenario without creepy run-time errors. But this testing does not guarantee our application to work properly and to be ready for production use.<\/p>\r\n\r\n\r\n\r\n For large applications it is usually recommended to construct Integration test scenarios covering the whole application functionality. These integration tests are supposed to be created by another person, not the one who developed the application. There is usually a role in the team called Quality Assurance Engineer, who is responsible for test scenarios. Integration tests can be automated or can be run manually for each development phase. Integration testing and Quality Assurance is a big and important part of the development process. But this is another long story.<\/p>\r\n\r\n\r\n\r\n But there is another important part of Development process called Unit testing. This part is the developers\u2019 responsibility and should be closely related to the main application functionality development. There is common practice to follow Test Driven Development<\/a> process. For example, we have defined IVedaVersumDataAccess<\/em><\/strong> interface in our application with some methods to manipulate the database. We have implemented this interface with class VedaVersumDataAccess<\/em><\/strong>. Also we have injected this interface to Query and Mutation resolvers. And when client calls query or mutation, the appropriate resolver will be involved. And then, this resolver should call appropriate data access method, which should return with some predictable result. We have already described the scenario for unit test. We can write the test methods which create an instance of Mutation class and inject IVedaVersumDataAccess<\/em><\/strong> in this class. But in unit test we don\u2019t have to call real database. We can substitute the data access real implementation class with mock implementation. And we can manipulate this mock implementation in the test method and check if some method has been called with some expected parameters and so on.<\/p>\r\n\r\n\r\n\r\n Therefore, I can \u201cdetach\u201d one part of the program and write test scenario checking this particular intermediate part of our application. And I can write as many scenarios as I need to cover all classes (or units) logic without constructing the whole complicated dependencies between different application modules. For example, we have the VedaVersumMutation<\/em><\/strong> class. And data mutating method has this algorithm:<\/p>\r\n\r\n\r\n\r\n And to be sure in this algorithm\u2019s proper work we should write a test scenario for each block in this algorithm. As you can see, method uses Database and Subscription sender service. These two dependencies are injected into the class through the constructor:<\/p>\r\n\r\n\r\n To test CardAction<\/em><\/strong> mutation method, we should create a VedaVersumMutation<\/em><\/strong> class object and call this method. But we can inject mock<\/u><\/strong> DataAccess<\/em> and EventSeder<\/em> objects instead of real objects in the tests which are used when program runs in a \u201cproduction mode\u201d. With these mock objects we can check if appropriate methods were called with appropriate parameters. Therefore, we can test only this particular algorithm and don\u2019t care about database and other dependencies.<\/p>\r\n\r\n\r\n\r\n To do that I have created a test project which uses NUnit<\/a> testing framework and Moq<\/a> library for setting up mock objects. And this can show you how to test this method:<\/p>\r\n\r\n\r\n\r\n
2.1. Setup MongoDB<\/h3>\r\n
![\"IVedaVersumDataAccess](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild2-3.png\")
<\/p>\r\n2.2. Data access implementation<\/h3>\r\n
\r\n "ConnectionStrings": {\r\n "mongo": "mongodb:\/\/localhost:27017"\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n\r\n public class VedaVersumDataAccess : IVedaVersumDataAccess\r\n {\r\n private const string DatabaseName = "VedaVersum";\r\n private const string VedaVersumCardsCollectionName = "Cards";\r\n private readonly IMongoDatabase _database;\r\n public VedaVersumDataAccess(string mongoDbConnectionString, ILogger<VedaVersumDataAccess> logger)\r\n {\r\n var mongoConnectionUrl = new MongoUrl(mongoDbConnectionString);\r\n var mongoClientSettings = MongoClientSettings.FromUrl(mongoConnectionUrl);\r\n mongoClientSettings.ClusterConfigurator = cb => {\r\n cb.Subscribe<CommandStartedEvent>(e => {\r\n logger.LogDebug($"{e.CommandName} - {e.Command.ToJson()}");\r\n });\r\n };\r\n var client = new MongoClient(mongoClientSettings);\r\n _database = client.GetDatabase(DatabaseName);\r\n }\r\n\r\n \/\/\/ <inheritdoc \/>\r\n public async Task DeleteCard(string cardId)\r\n {\r\n var cardsCollection = _database.GetCollection<VedaVersumCard>(VedaVersumCardsCollectionName);\r\n await cardsCollection.DeleteOneAsync(Builders<VedaVersumCard>.Filter.Where(c => c.Id == cardId));\r\n }\r\n\r\n \/\/\/ <inheritdoc \/>\r\n public async Task<IEnumerable<VedaVersumCard>> GetAll()\r\n {\r\n var cardsCollection = _database.GetCollection<VedaVersumCard>(VedaVersumCardsCollectionName);\r\n var allCards = await cardsCollection.FindAsync(Builders<VedaVersumCard>.Filter.Empty);\r\n return allCards.ToList();\r\n }\r\n \/\/ Code omitted for brevity\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n\r\n \/\/ DataAccess\r\n var connectionString = Configuration.GetConnectionString("mongo");\r\n services.AddTransient<IVedaVersumDataAccess, VedaVersumDataAccess>((p) => new VedaVersumDataAccess(\r\n connectionString, \r\n p.GetService<ILogger<VedaVersumDataAccess>>()!));\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n![\"Create](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild3-3.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"Read](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild4-3.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"Update](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild5-2.png\")
<\/figure>\r\n\r\n\r\n\r\n3. GraphQL resolvers and data loaders<\/h2>\r\n\r\n\r\n\r\n
![\"Stored](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild6-2.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"card](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild7-2.png\")
<\/figure>\r\n\r\n\r\n\r\n\r\n public class VedaVersumCardObjectType: ObjectType<VedaVersumCard>\r\n {\r\n protected override void Configure(IObjectTypeDescriptor<VedaVersumCard> descriptor)\r\n {\r\n descriptor\r\n .Field("relatedCards") \/\/ Name of the additional field\r\n .Type<ListType<VedaVersumCardObjectType>>()\r\n .Resolve(async context =>\r\n {\r\n var parent = context.Parent<VedaVersumCard>();\r\n\r\n if(parent.RelatedCardIds == null || parent.RelatedCardIds.Count == 0)\r\n {\r\n return new List<VedaVersumCard>();\r\n }\r\n\r\n var dataAccess = context.Service<IVedaVersumDataAccess>();\r\n return await dataAccess.GetCardsById(parent.RelatedCardIds);\r\n });\r\n }\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n![\"extend](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild8-2.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"Run](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild9-2.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"construct](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild10-1.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"database](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild11-1.png\")
<\/figure>\r\n\r\n\r\n\r\n\r\n \/\/\/ <summary>\r\n \/\/\/ Returns card by ID\r\n \/\/\/ <\/summary>\r\n public async Task<VedaVersumCard?> GetCardById(string cardId)\r\n {\r\n return _dataAccess.GetCardById(cardId);\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n\r\n public class VedaVersumCardDataLoader : BatchDataLoader<string, VedaVersumCard>\r\n {\r\n private readonly IVedaVersumDataAccess _vedaVersumDataAccess;\r\n\r\n public VedaVersumCardDataLoader(\r\n IVedaVersumDataAccess vedaVersumDataAccess,\r\n IBatchScheduler batchScheduler,\r\n DataLoaderOptions<string>? options = null) : base(batchScheduler, options)\r\n {\r\n _vedaVersumDataAccess = vedaVersumDataAccess;\r\n }\r\n\r\n \/\/ This method collects all CardIds during the single GraphQL query and executes database query once far all CardIds\r\n protected override async Task<IReadOnlyDictionary<string, VedaVersumCard>> LoadBatchAsync(\r\n IReadOnlyList<string> keys, CancellationToken cancellationToken)\r\n {\r\n var allCardsByIds = await _vedaVersumDataAccess.GetCardsById(keys);\r\n return allCardsByIds.ToDictionary(c => c.Id);\r\n }\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n\r\n \/\/\/ <summary>\r\n \/\/\/ Returns card by ID\r\n \/\/\/ <\/summary>\r\n public async Task<VedaVersumCard?> GetCard(string cardId, VedaVersumCardDataLoader dataLoader)\r\n {\r\n return await dataLoader.LoadAsync(cardId, CancellationToken.None);\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n![\"Execute](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild12-1.png\")
<\/figure>\r\n\r\n\r\n\r\n![\"Execute](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild13-1.png\")
<\/figure>\r\n\r\n\r\n\r\n4. Unit testing<\/h2>\r\n\r\n\r\n\r\n
![\"the](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild14-1.png\")
<\/figure>\r\n\r\n\r\n\r\n\r\n public class VedaVersumMutation\r\n {\r\n private readonly ITopicEventSender _eventSender;\r\n private readonly IVedaVersumDataAccess _dataAccess;\r\n\r\n\r\n public VedaVersumMutation(ITopicEventSender eventSender, IVedaVersumDataAccess dataAccess)\r\n {\r\n _eventSender = eventSender;\r\n _dataAccess = dataAccess;\r\n }\r\n \/\/ Code omitted for brevity\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n\r\n public class VedaVersumMutationTests\r\n {\r\n \/\/\/ <summary>\r\n \/\/\/ Event sender mock object\r\n \/\/\/ <\/summary>\r\n private Mock<ITopicEventSender> _eventsSenderMock = new Mock<ITopicEventSender>();\r\n \/\/\/ <summary>\r\n \/\/\/ DataAccess mock object\r\n \/\/\/ <\/summary>\r\n private Mock<IVedaVersumDataAccess> _dataAccessMock = new Mock<IVedaVersumDataAccess>();\r\n private VedaVersumMutation MutationClassToTest;\r\n\r\n [SetUp]\r\n public void Setup()\r\n {\r\n MutationClassToTest = new VedaVersumMutation(_eventsSenderMock.Object, _dataAccessMock.Object);\r\n }\r\n\r\n [Test]\r\n public async Task ShouldCallInsertNewCardDataAccessMethodOnCardCreate()\r\n {\r\n \/\/ Arrange. Mocking dataAccess behavior\r\n _dataAccessMock.Setup(d=> d.InsertNewCard(It.IsAny<string>(), It.IsAny<string>(), null, It.IsAny<User>()))\r\n .ReturnsAsync(ExpectedCardData);\r\n\r\n \/\/ Action\r\n var resultCard = await MutationClassToTest.CardAction(\r\n VedaVersumCardAction.Create, \r\n ExpectedCardData.Title,\r\n ExpectedCardData.Content,\r\n relatedCards: null,\r\n cardId: null,\r\n TestUser);\r\n\r\n \/\/ Assert\r\n Assert.NotNull(resultCard);\r\n Assert.IsNotEmpty(resultCard.Id);\r\n Assert.AreEqual(ExpectedCardData.Title, resultCard.Title);\r\n \/\/ Check if data accessor's InsertNewCard method has been called only once and with appropriate parameters\r\n _dataAccessMock.Verify(d => d.InsertNewCard(\r\n ExpectedCardData.Title, \r\n ExpectedCardData.Content,\r\n null,\r\n It.IsAny<User>()\r\n ), Times.Once);\r\n \/\/ Check if EventSender's method SendAsync has been called only once\r\n _eventsSenderMock.Verify(s => s.SendAsync<string, CardActionMessage>(\r\n nameof(VedaVersumSubscription.CardChanged), \r\n It.Is<CardActionMessage>(m => m.Action == VedaVersumCardAction.Create),\r\n It.IsAny<CancellationToken>()),\r\n Times.Once);\r\n }\r\n\r\n [TestCase(VedaVersumCardAction.Update)]\r\n [TestCase(VedaVersumCardAction.Delete)]\r\n public void ShouldThrowExceptionIfActionIsNotCreateAndCardIdIsNull(VedaVersumCardAction action)\r\n {\r\n Assert.ThrowsAsync<ArgumentNullException>(() => MutationClassToTest.CardAction(\r\n action, \r\n ExpectedCardData.Title,\r\n ExpectedCardData.Content,\r\n relatedCards: null,\r\n cardId: null,\r\n TestUser));\r\n }\r\n\r\n \/\/ Other test scenarios are omitted\r\n }\r\n\r\n<\/pre><\/div>\r\n\r\n\r\n