Define Query & Mutation Usage (useQuery, cache invalidation, etc.) about blitz HOT 13 CLOSED

as blitz does not support graphql it would become out of hand to define and maintaining queries and their types in large project.
would be nice if blitz could auto generate queries using prisma somehow, something like https://gqless.dev

from blitz.

In server-side code, a query function can be called directly without useQuery

Does that mean there will be no option to cache queries on the server-side? We need data caching and SSR Suspense for our web app.

React Suspense with react-cache is also an option in the future - https://hackernoon.com/magic-of-react-suspense-with-concurrent-react-and-react-lazy-api-e32dc5f30ed1

from blitz.

@cr101 good question.

What type of caching do you need on the server? And do you need this for serverful or serverless deployment?

Blitz will definitely support SSR suspense — as soon as Next.js does, which I expect to be at or soon after the production release.

from blitz.

Does that mean there will be no option to cache queries on the server-side?

I would imagine that might be a good candidate for an optional middleware?

from blitz.

On the surface react-async-ssr looks really nice! I am not sure without working through the details as to how much easier that would be to hook up with Next.js as opposed to doing a standard SSR query preload as whilst I would have to look at it to be sure, I am not sure we can easily override the actual renderToString routine to replace it with the async version. So far what I have managed to do was run queries and manually hydrate a custom global cache.

from blitz.

As far as this API is concerned this client-side cache invalidation stuff is getting complex. Could we possibly be straying away from the core premise of blitz that you should never need to worry about data fetching? I am wondering if we could merge queries into a resource if we would then get more automatic mileage in terms of cache invalidation after mutations as you could configure this is a resource and it's queries, mutations and cache could be linked? Thoughts? Perhaps the above API could be for advanced usage?

const productResource = createResource({
  get: getProduct,
  update: updateProduct,
  create: createProduct,
  delete: deleteProduct
});


export default function(props: {query: {id: number}}) {
  const [product] = useResource(productResource.get({where: {id: props.query.id}}))
  return (
    <Formik
      initialValues={product}
      onSubmit={async values => {
        try {
          const product = await productResource.update(values)
        } catch (error) {
          alert('Error saving product')
        }
      }}>
      {/* ... */}
    </Formik>
  )
}

I know this has echoes of the serverside rails controllers we had before.

from blitz.

Invalidating cache on route transitions is quite simple, yeah? And instead of requiring an opt-in, we could automatically invalidate cache on route transitions and then have an option to opt out.

refetch and mutate are for advanced cases.

Unless we enforce 100% SSR, then there's no way to get around client side cache. So the best we can do is make the common case extremely simple. I think a route transition will be the most common case.

from blitz.

SSR doesn't help with client side cache unless you mean full server rendered pages on every interaction which is not an option.

This could be a leaky abstraction if application developers don't change page routes after mutations. Think edit in place fields. Spreadsheets. Drag and drop interfaces. Not every app has a save button. The common case is crud interactions not route transitions. I think we need to link interactions to inform the way the cache works by default. Could be configuration doesn't matter how. Could even be convention inferred by cache key? ie. the path of the query method or the name of the interaction.

from blitz.

I'll think more about the cache stuff and report back later.

I realized something I overlooked: applying middleware in getServerSideProps. Middleware can't be used in getStaticProps because that is at build time without a request, but gSSP has req & res.

Here's what I'm thinking. Thoughts?

import {ssrQuery} from 'blitz'
import getProduct from '/app/products/queries/getProduct'

export const getServerSideProps = async ({params, req, res}) => {
  const product = await ssrQuery(getProduct, {where: {id: params.id}}, {req, res}))
  return {props: {product}}
}

export default function({product}) {
  return <div>{product.name}</div>
}

Alternately, we could use a babel transform to add the req and res objects to the ssrQuery call so the user doesn't have to. But I don't really think that's a good idea.

from blitz.

The blitz generate cli command will generate queries and mutations for you. From then on you only need to customize if needed. If this still doesn't provide good enough DX, then we can explore more things.

from blitz.

Will it be possible to query the database using raw queries via prisma.raw()?

from blitz.

@cr101, yes you bet! You have full access to prisma. The only thing we are planning to do for now is wrap the prisma CLI like blitz db migrate. But in your code, you import prisma directly.

from blitz.

Closing as complete! I've added the documentation form here to the new docs website that will go live within a day or so.

I also opened #586 to discuss automatic cache invalidation.

from blitz.