feat: Setup structure for simple three-tier architecture #42
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| const householdData = await calculationService.getHouseholdData(input); | ||
| return NextResponse.json(householdData); |
There was a problem hiding this comment.
This POST() function is now much simpler, we only care about handing HTTP input and output etc.
| @@ -0,0 +1,28 @@ | |||
| import prisma from "./db"; | |||
|
|
|||
| const getItl3ByPostcodeDistrict = async ( | |||
There was a problem hiding this comment.
In this "layer" we're only concerned about fetching data from the DB, and handing the correct value to consumers.
|
|
||
| const prisma = new PrismaClient(); | ||
|
|
||
| export const getHouseholdData = async ( |
There was a problem hiding this comment.
Obviously - a lot still to be done here, but this is where "business logic" can live. We get parsed and validated input handed across, and we can interact with other services to get the data we need.
| @@ -0,0 +1,9 @@ | |||
| import { gdhiRepo } from "../data/gdhiRepo"; | |||
There was a problem hiding this comment.
For these very simple functions, I appreciate that setting up a whole "layer" may seem redundant, but as complexity and requirements grow it's nice to have a single place to fetch all data from.
We'll see this more clearly once we start splitting up the postcode fallthrough logic 👍
There was a problem hiding this comment.
I might have missed something obvious here, but why do we want separate "layers" for gdhiRepo and itlRepo and not for other tables in the database?
There was a problem hiding this comment.
Scratch that, I now understand after having seen the relevant Project card.
|
This looks great to me @DafyddLlyr . Also thank you very much for explaining the logic step by step, super appreciated. I think @zz-hh-aa will also find a lot of value in reading this PR, so maybe they can approve it after reading it if that's ok with you |
| @@ -0,0 +1,15 @@ | |||
| import { PrismaClient } from "@prisma/client"; | |||
|
|
|||
| const prismaClientSingleton = () => { | |||
There was a problem hiding this comment.
I was reading about the Singleton pattern 'cause I hadn't encountered it before--to ensure that the client is truly only created once, would we need some sort of if-then check here to only instantiate if there is no PrismaClient currently in existence?
There was a problem hiding this comment.
Yep that's exactly correct 🙌
This is happening below on line 11 - when we import prisma we check if one exists, or instantiate a new one.
There was a problem hiding this comment.
Ah, I missed that--still getting used to the reviews GUI 😅 thanks!
| @@ -0,0 +1,9 @@ | |||
| import { gdhiRepo } from "../data/gdhiRepo"; | |||
There was a problem hiding this comment.
I might have missed something obvious here, but why do we want separate "layers" for gdhiRepo and itlRepo and not for other tables in the database?
DafyddLlyr
force-pushed
the
dp/remove-prisma-queryRaw
branch
from
427405c to
398812b
Compare
DafyddLlyr
force-pushed
the
dp/three-tier
branch
from
a632e9d to
0436b0c
Compare
| @@ -0,0 +1,15 @@ | |||
| import { PrismaClient } from "@prisma/client"; | |||
|
|
|||
| const prismaClientSingleton = () => { | |||
There was a problem hiding this comment.
Ah, I missed that--still getting used to the reviews GUI 😅 thanks!
What does this PR do?
primsa.$queryRaw()with calls to prisma models #19 for contextLets try to talk this through early in the week, and I'll hand over to you guys to complete the process 👍