Hi @ajoslin103 even outside using a debugger (which I confess I don’t know how to/don’t use in VSCode) there are a few things you can do to make writing services (and effectively Prisma db queries easier):
- Seed you data
- Use a db tool like TablePlus and write your SQL and test it
- Create your services and GraphQL api (ie, services and sdl) and then test your queries and/or mutations in GraphQL Playground or Insomnia (what I use)
- For the moment, in your services use console.trace, debug, info etc to log to the api side in your dev server output
- Logging is coming in next release (PR is soon to be merged in canary for v28) and then you can switch out to use the logger and then replace console with logger
- You can also add Prisma logging to see what it is doing (this will enabled in logging too).
- You’ll be able specify only log warns an errors etc
If you are testing custom functions, then the same applies about:
- Logging
- Making the api function request to via Insomnia to test
Also, did you know Redwood has a console? That can help you having seeded data and then test out basic Prisma queries, updates:
yarn rw console
> db.user.findMany({take: 3})
[
{
id: 1,
email: 'Leola47@yahoo.com',
name: 'Anthony Dicki',
avatar: 'https://s3.amazonaws.com/uifaces/faces/twitter/herbigt/128.jpg'
},
{
id: 2,
email: 'Dagmar1@yahoo.com',
name: 'Diane Hahn V',
avatar: 'https://s3.amazonaws.com/uifaces/faces/twitter/desastrozo/128.jpg'
},
{
id: 3,
email: 'Adell46@hotmail.com',
name: 'Rosie Gaylord DVM',
avatar: 'https://s3.amazonaws.com/uifaces/faces/twitter/algunsanabria/128.jpg'
}
]
(note this is faker data)
Yes, I think there is a way to use the debugger, but these old ways still can be helpful.