Forem: mnsr

Entity Framework DotNet Core with GraphQL and SQL Server (using HotChocolate)

mnsr — Fri, 06 Mar 2020 08:54:58 +0000

This article will cover two graphql options available for dotnet core:

Hotchocolate
Graphql-Dotnet (briefly)

So you're a dotnet developer and you've heard the hype surrounding graphql, and you think "oh yeah, I just HAVE to try this!". Well prepared to be deeply underwhelmed.

As a start, you'd probably google something along the lines of "dotnet graphql". You'd be presented with graphql-dotnet. You click on the github link, only to be presented with this:

Yikes! Then you decide to go into the releases page, and see the Version 2.4.0 release date: 15 Nov 2018... BIG YIKES.

Ok screw that. What's next?

Hotchocolate to the rescue? What the hell is that? This was the question that first came to mind when I saw a youtube video on graphql and dotnet. It's really the only option you have when it comes to GraphQL solutions in the dotnet world.

The latest official release, as of this post, is 10.3.6 which was released 7 days ago. OK! That's reassuring. The latest preview version was released < 24 hours ago - AWESOME. It's active, it's running, so lets start this.

Before I proceed, this will be just a basic overview to get started with Hotchocolate graphql, entityframework core and SQL Server. You will end up with a local server, and a graphql playground. I won't be going too in-depth with it, but hopefully you'll get a much better start than I did.

Overview

Things we will be doing:

Create the project
Setting up our Startup.cs file
Setup the database
Adding entities
Adding the DB Context
Adding the schema
Updating the Startup.cs file with our Query types and DB Context

Create the project

Things I'm going to use, and I'll assume you have them installed because I won't cover them:

VSCODE (Omnisharp + C# extensions installed)
SQL Server, or access to one
dotnet core 3.1 installed

First, we load up our trusty terminal (CMD, Bash, ZSH, whatever) create a project folder and navigate to it and create the project:

> md dotnet-gql-test
> cd dotnet-gql-test
> dotnet new web

This wil create a new empty web application. Once that's done, we install the dependencies:

> dotnet add package Microsoft.EntityFrameworkCore
> dotnet add package Microsoft.EntityFrameworkCore.SqlServer
> dotnet add package HotChocolate.AspNetCore
> dotnet add package HotChocolate.AspNetCore.Playground
> code .

This will install the above packages, and open up vscode. When you open up vscode, you may see some popups, just click install for C# extensions, wait for Omnisharp to install if it already isn't installed, and let it install any missing required assets.

So far, our csproj file should look like this:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <RootNamespace>dotnet_gql_test</RootNamespace>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="HotChocolate.AspNetCore" Version="10.3.6" />
    <PackageReference Include="HotChocolate.AspNetCore.Playground" Version="10.3.6" />
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="3.1.2" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="3.1.2" />
  </ItemGroup>

</Project>

Startup.cs

Open up the Startup.cs file, and change it to the following:

using HotChocolate;
using HotChocolate.AspNetCore;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

namespace dotnet_gql_test
{
  public class Startup
  {

    public void ConfigureServices(IServiceCollection services)
    {
      services.AddGraphQL(
        SchemaBuilder.New()
        // AddQueryType<T>() here 
        .Create());
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
      if (env.IsDevelopment())
          app.UseDeveloperExceptionPage();

      app
        .UseRouting()
        .UseWebSockets()
        .UseGraphQL()
        .UsePlayground();
    }    
  }
}

This boilerplate, will allow us to eventually use a GraphiQL style playground to test our queries.

The database

In our test database for this example, lets say we have a table

CREATE TABLE [Locations]
  [ID] [int] IDENTITY(1,1) NOT NULL,
  [Name] [nvarchar](50) NOT NULL,
  [Code] [nvarchar](5) NOT NULL,
  [Active] [bit] NOT NULL

Lets insert some test data:

INSERT INTO [Locations]
  ([Name], [Code], [Active])
VALUES
  ("Sydney", "SYD", 1)
GO
INSERT INTO [Locations]
  ([Name], [Code], [Active])
VALUES
  ("Los Angeles", "LAX", 1)
GO

Entity

This is pretty much the same as your standard .NET EntityFramework entity you'd use. It's basically a class with the matching column names and types as the CREATE TABLE query above.

using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace dotnet_gql_test
{
  [Table("Locations")]
  public class Locations
  {
    [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public int ID { get; set; }

    [Required, MaxLength(50)]
    public string Name { get; set; }

    [Required, MaxLength(5)]
    public string Code { get; set; }

    [Required]
    public bool Active { get; set; }
  }
}

Important: This is outside the scope of this article, but you can create a LocationType to complement this. You can find more information about it here: https://hotchocolate.io/docs/schema-descriptions

The DB Context

Again, it's pretty much identical to any standard DB Context in .NET Entity Framework. But here, for simplicity's sake, I'm going to add the database connection string.

using Microsoft.EntityFrameworkCore;

namespace dotnet_gql_test
{
  public class MyDbContext: DbContext
  {
    public static string DbConnectionString = "Data Source=database.url;Initial Catalog=mydatabasename;Persist Security Info=True;Connect Timeout=30;User ID=user;Password=pass";

    public MyDbContext(DbContextOptions<MyDbContext> options) : base(options)
    {}

    public DbSet<Locations> Location { get; set; }

  }
}

The Schema

Hear comes the meaty part. This is what we will have access to in our graphql playground. As a basic query, we'll return a list of Locations from our Location table, and another query that accepts an argument for a specific location code. The schema is pretty straightforward, you'll have one class that has queries, and another class that extends ObjectType and configures the fields for the query. The latter will be added to our Startup.cs file as a QueryType in the Schema definition.

First, we'll create the query class. This contains all the queries for this example.

using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using HotChocolate;
using HotChocolate.Types;
using Microsoft.EntityFrameworkCore;

namespace dotnet_gql_test
{
  public class LocationQueries
  {
    // GetLocations: Return a list of all locations
    // Notice the [Service]. It's an auto hook up from HotChocolate
    public async Task<List<Locations>> GetLocations([Service] MyDbContext dbContext) =>
      await dbContext
        .Location
        .AsNoTracking()
        .OrderBy(o => o.Name)
        .ToListAsync();

    // GetLocation: Return a list of locations by location code
    public async Task<List<Locations>> GetLocation([Service] MyDbContext dbContext, string code) =>
      await dbContext
        .Location
        .AsNoTracking()
        .Where(w => w.Code == code)
        .OrderBy(o => o.Name)
        .ToListAsync();
    }
  }

Next, we create the query type.

using HotChocolate.Types;

namespace dotnet_gql_test
{
  public class LocationQueryType : ObjectType<LocationQueries>
  {
    protected override void Configure(IObjectTypeDescriptor<LocationQueries> descriptor)
    {
      base.Configure(descriptor);

      descriptor
        .Field(f => f.GetLocations(default))

      descriptor
        .Field(f => f.GetLocation(default, default))
        .Argument("code", a => a.Type<StringType>());
    }
  }
}

This lets our schema know that we have 2 queries available. GetLocations will get all locations. GetLocation will get a location by code.

Back to the Startup.cs file

Now that we have everything set up, we can update our Startup.cs file with the data context, and schema builder.

To do this, the update the ConfigureServices function with the following:

    public void ConfigureServices(IServiceCollection services)
    {
      // Add DbContext
      services
        .AddDbContext<MyDbContext>(options =>
          options.UseSqlServer(MyDbContext.DbConnectionString));

      // Add GraphQL Services
      services
        .AddDataLoaderRegistry()
        .AddGraphQL(SchemaBuilder
            .New()
            // Here, we add the LocationQueryType as a QueryType
            .AddQueryType<LocationQueryType>()
            .Create());
    }

Build and run

To build and run, type the following in your terminal:

> dotnet run
# an alternative is "dotnet watch run" - this adds a watcher when coding

Open your browser to http://localhost:5000/playground. This will display a graphiql playground. In this you should be able to successfully run the queries:

{
  locations {
    name
    code
  }
}

The above will return all locations.

{
  location(code: "lax") {
    name
  }
}

The above will return "Los angeles".

This covers the basic fundamentals of EFCore and GraphQL. It's not difficult, but documentation covering everything is quite sparse or non-existant.

If you have any questions, or you think I missed something (or worse, made typos), feel free to hit me up in the comments.

Hope this helps someone.

Axios Mocking in React using Typescript and testing-library

mnsr — Sat, 29 Feb 2020 11:06:51 +0000

I got stuck on an issue yesterday, so I thought I'd create a post on my findings and solution.

In the end, it was quite simple really (the longer I get stuck on something, the easier the solution turns out to be... 🤷‍♂️). My googlefu had failed me completely as every solution I found, was either out dated, or incomplete, or more importantly: did not account for Typescript.

Important packages used here (github link at the end):

Hmm. Where to start? Lets go with a basic useFetch hook, as that's where we use axios to fetch our data.

useFetch axios hook

export interface IUseFetch {
  response: any;
  loading: boolean;
  error: boolean;
}

export const useFetch = (run: boolean, url: string) => {
  const [response, setResponse] = useState({});
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(false);

  useEffect(() => {
    let mounted = true;
    const abortController = new AbortController();
    const signal = abortController.signal;
    if (run && mounted) {
      const fetchData = async () => {
        try {
          setLoading(true);
          const response = await axios.get(url);
          if (response.status === 200 && !signal.aborted) {
            setResponse(response.data);
          }
        } catch (err) {
          if (!signal.aborted) {
            setResponse(err);
            setError(true);
          }
        } finally {
          if (!signal.aborted) {
            setLoading(false);
          }
        }
      };
      fetchData();
    }

    return () => {
      mounted = false;
      abortController.abort();
    };
  }, [run, url]);

  return { response, loading, error };

}

Pretty standard useFetch hook. The run variable is the trigger for fetch to run.

App

Next up, our basic React component. This component is just an input, that does a search and shows a div with some search results that come from our useFetch hook above.


export interface ILocation {
  location: string;
  country: string;
}

export default function App() {
  const [searchString, setSearchString] = useState(""); 
  const [isPanelOpen, setIsPanelOpen] = useState(false); // show/hide results
  const [doSearch, setDoSearch] = useState(false); // controls fetch run

  // useFetch hook above.
  const { response, loading } = useFetch(doSearch, "test.json");

  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setSearchString(e.target.value);
  };

  // If the searchString length > 0, then do the following
  useEffect(() => {
    setDoSearch(searchString.length > 0);
    setIsPanelOpen(searchString.length > 0);
  }, [searchString.length]);

  const renderSearchResults = () =>
    !loading &&
    !error &&
    response &&
    response.length > 0 && (
      <ul aria-label="search-results">
        {response.map((loc: ILocation, i: number) => (
          <li key={i}>
            {loc.location}, {loc.country}
          </li>
        ))}
      </ul>
    );

  return (
    <div className="App">
      <label htmlFor="search">Search:</label>
      <input
        type="text"
        aria-label="search-input" // label used by our tests
        id="search"
        name="search"
        autoComplete="off"
        value={searchString}
        onChange={handleChange}
      />

      {isPanelOpen && (
        <div aria-label="search-panel">{renderSearchResults()}</div>
      )}
    </div>
  );
}

Easy enough? Cool.

Now to the testing.

Testing

Before we start, looking at the code above, we have three aria-labels that we will use to assert.

search-input: our input box
search-panel: our search result container div. This may show empty depending on response (we won't cover that here)
search-results: holds the actual json response from our useFetch hook

First, lets prepare our test file.

Create a file called App.test.tsx and set it up:

import '@testing-library/jest-dom';
import '@testing-library/jest-dom/extend-expect';
import React from 'react';
import {
  cleanup,
  render,
  fireEvent,
  wait,
} from '@testing-library/react';

import axios from 'axios';
import App from './App';

jest.mock('axios');

Things to note:

@testing-library/jest-dom/extend-expect: allows us some useful extensions to jest-dom like .toBeInTheDocument().
We import axios normally No need for funny names.
we do a standard jest.mock('axios') This lets our tests know that whenever they see an axios import, to replace it with a mock function.

What you came here for: The Mock

Before we write our test, we mock. We're going to be mocking axios, and this was the part I was stuck on. But it's quite straightforward.

import { AxiosResponse } from 'axios';

// load our test.json file. This can be copied to the local 
// folder. Can be a short version of your actual data set.
const testJson = require('../../test.json');

// Our mocked response
const axiosResponse: AxiosResponse = {
  data: testJson,
  status: 200,
  statusText: 'OK',
  config: {},
  headers: {},
};

// axios mocked
export default {
  // Typescript requires a 'default'
  default: {
    get: jest.fn().mockImplementation(() => Promise.resolve(axiosResponse)),
  },
  get: jest.fn(() => Promise.resolve(axiosResponse)),
};

What's happening here is that we create a mocked AxiosResponse, which contains all the essentials like the response.status which we use in our useFetch hook, and then the most important part: the response.data.

Then we have the actual axios mock. Whenever our app sees the axios import, it'll use whatever is inside this. We're using get for this example, so I've included a get mock. The important thing to note here is that we have a default and this is used by Typescript. More info here

The Test

Next, we write our test. In this test, we'll follow the recommendations Kent C. Dodds has written about in his blogs. So we'll do just one end to end (E2E) test here. This will cover the user typing something into the input box, and seeing our search results.


test("type text into input, and  display search results", async () => {
  // our test searchString
  const searchString = "syd";

  // Render App
  const { getByLabelText, queryByLabelText, debug } = render(<App />);

  // find the input
  const input = getByLabelText("search-input");

  // search panel should not be rendered at this point
  expect(queryByLabelText("search-panel")).not.toBeInTheDocument();

  // this fire the onChange event and set the value to 'syd'
  fireEvent.change(input, { target: { value: searchString } });

  // useFetch should be called to get data
  expect(axios.get).toHaveBeenCalled();

  // assert our input value to be searchString
  expect(input.value).toBe(searchString);

  // search panel is loaded in the document
  expect(queryByLabelText("search-panel")).toBeInTheDocument();

  // wait for search results to be rendered
  await wait(() => {
    expect(queryByLabelText("search-results")).toBeInTheDocument();
  });
});

We use async because need to await the search results to render.

And that's it. The key to mocking axios in typescript is just the mock file that returns an AxiosResponse. Then in our test we can assert expect(axios.get).toHaveBeenCalled().

Here's a link to a github repo as Codesandbox doesn't support jest.mock.

If you play around with it, you can see how it works by commenting the entire axios.ts file and jest.mock('axios') in the App.test.tsx file.

Hope this helps someone.