[MUSIC]
>> That's interesting, but very limited right now.
What I want to do is remove some limitations.
I'm going to move onto my next step.
In this step, we're introducing Entity Framework Core.
Now I'm using this for two reasons.
One is it's probably one of the fastest,
easiest ways I can get from this application
to a actual working database.
Two is because it works very nicely with GraphQL.
I've got a seeder application.
This will actually go out and grab the RSS feeds from
the blogs and populate them and load it to the database.
But how does the database work?
I just want to show that I didn't change my blog class.
I did not change my post-class.
Those are remaining the same.
But I've got this blogs context.
A context is the way that you tell
Entity Framework Core that you're interested in
doing something with a domain class.
Here I'm calling it out of all the classes,
I've got a program class,
a query class, a seeder class.
I'm just interested in persisting blogs and posts to the database.
I'm exposing those.
I'm calling it how they relate.
Every blog has multiple posts but posts only have one blog.
It's just describing the relationship.
That is pretty much all I need to establish an API to a database.
>> All of that is pretty,
no pun intended, EF Core Code.
If you were going to be doing anything with EF Core,
that's pretty much like EF Core 101 syntax.
Here's my DbSet for posts,
here's my DbSet for blogs,
and then here's the relationship between them.
>> You've got it.
>> Okay. Do you remember some Entity Framework?
>> You do. I'm still adding the same query type.
Here I'm adding the context to
dependency injection so it's available elsewhere.
I'm telling it to use SQLite.
That's one of the features of
Entity Framework Core is that we have
different database providers that will work with
SQL Server within memory with Azure Cosmos DB.
You can use that same context with different databases.
We actually have some customers
who might use the same DbContext and
fan out to a SQL database and a Cosmos DB database.
Here I'm telling it to use SQLite.
I'm also using our simple logging,
the log database commands,
so we can see what happens with the database as we use this.
>> That's doing a bit of dependency injection.
It's basically telling your ASP.NET Core application,
Hey, this is where my database is.
If you were going to go to production with this,
you'd be telling it to use SQL Server or
MySQL or whatever database it is that you might be using.
>> You've got it.
>> Okay.
>> The other thing that does for us is we can now update this.
Instead of hard-coding the results,
I'm basically injecting the contexts that I just configured.
That context exposes then it is as queryables.
This is the only code it takes to now
glue GraphQL to Entity Framework Core.
>> Okay. I'm going to write my GraphQL command.
I'm going to send that up to the server,
which is running ASP.NET Core.
That's then going to intercept that.
It's going to send that into the GraphQL service,
Hot Chocolate in this case,
which is then going to be able to use EF course and it's going
to translate that into a LINQ Query for EF Core.
EF Core is then going to translate that link
into the SQLite command and go get the data.
Then it's basically just
undoing that stack to send it back out the door.
>> That is the theory.
>> Perfect.
>> Let's see how the theory holds up.
We're going to go back to banana cake blog.
I'm just going to use the same query,
and I'm just going to rerun it.
What you'll see is these posts came back as null.
I'm going to address that in a second,
but let me back up on blogs and let me put
name and URL up here near the top.
Actually don't need the commas.
I'm going to run that.
You can see we indeed are getting blogs.
I got developer for life and someone named
Geek Trainer has this geektrainer.dev blog.
>> Don't know who that is.
>> It's getting that, but the posts are
coming back as null. Why is that?
Well, let's pop back over and look at
our SQL that's being generated.
Don't you hate that when you're tabbing and you overshoot?
>> Yes.
>> What it's doing is it's selecting ID name
URL from blogs b. I didn't even ask for the ID.
It's clearly just grabbing
every field and it's not even joining to post.
This is because out of the box,
Hot Chocolate just knows to ask EF Core a question.
It doesn't know how to take all of
my parameters and turn them into
an expression tree and pass them
off the EF Core to then translate into SQL.
To do that requires one more step,
and this is one that I hope
you appreciate the work involved with this.
>> I want to highlight here
the part that he mentioned there is what's
happening is it's still grabbing every column so it's
not doing that full translation.
If you were to leave it like this,
let's say I just wanted the name or something,
what would happen is the data would come out of
the database into the server, like all of it,
and now the server would then wind up trimming it
before it sent it back to the client, which okay,
fine, that gets you part of the way of limiting the data,
but now you're still getting data out of
the database that you didn't need.
We really want to make sure that we're doing it
fully from front to back there where we're
just getting the data back that we want.
>> Right. What I did is I added two things.
I added this UseProjection attribute onto my method.
In the startup, I added Projections.
>> Okay.
>> What I'm opting into,
what projections does is projections tells Hot Chocolate to
take the structure of
your GraphQL query and turn that into an expression tree.
Now it's doing all the work of the Queryable.
This is not specific to Entity Framework Core.
If you're using something else that also recognizes LINQ queries,
it will work equally as well with that,
but with that little tweak,
so that we're telling it, yes,
we've got something that can deal with expression trees,
I'm going to refresh this and boom, we get data.
If we look at our SQL,
you can see we've got SQL that's
selecting just the data that we're interested in.
>> That's cool. I want to go back
and try and unpack this
just to highlight the coolness of all of this.
What we're looking to have happened is
my GraphQL gets translated into LINQ,
then that LINQ is going to get translated into the SQL.
Originally what was happening was
the GraphQL wasn't doing that full translation into LINQ.
As a result, when it went back to my database,
it was just go get everything which is not really what we want.
We only want specific items here.
By adding in that AddProjections, now,
my GraphQL is being properly translated into LINQ,
and then my LINQ is being properly translated into SQL.
>> Correct.