https://www.prisma.io/ logo
Join Slack
Powered by
Hello, while moving a service from Graphcool to Pr...
# orm-help
p
Hello, while moving a service from Graphcool to Prisma, I’m considering options for image storage. What I have in mind so far is to use resumable file uploads on Google Cloud Storage to upload files from the browser (getting a pre-signed URL using Yoga) then storing all image meta data as 
Json
fields, effectively having an SDL such as:
Copy code
type User {
  photos: [Json!]!
}
I know I would not be able to filter on images in that case, but this is not something I need as I would always be retrieving all user images. Any other known limitations or pitfalls to this anyone is aware of?
n
can one image be related to more than one user?
be aware that any change to a single photo will be quite "expensive" in terms of complexity and duration. you will need to download the entire JSON, edit it client-side (or in your GraphQL Server), and push the entire JSON back
consider this alternative schema:
Copy code
type User {
  photos: [Photo!]!
}

type Photo {
  metadata: Json!
}
your queries and mutations get an additional level, but you are more flexible now
p
Thank you Nilan
No, one image can never be related to more than one user
There won’t be changes to any single photo either really, there will be additions or deletions only
But I guess that doesn’t change what you said much 😄
n
It doesn't 🙂
how many images will you typically store?
per user
p
10
Here’s the only thing that “bothers” me in the schema you have above, which is by the way what I had in Graphcool. In reality I store photos for two types of entities: Users and Places.
Using the above, I would have two relations on the Photo type, one that points to User and one that points to Place.
I don’t actually know why that bothers me, I guess it just doesn’t feel right to put a relation on a type when a single record of that type would be related either to a User or to a Place, but never to both
Would you then actually create two types, UserPhoto and PlacePhoto?
n
do you ever need to traverse TO the user or place from the photo?
p
I’m not sure what you mean by that use case…
I would always be getting the user or place object first, then getting their photos, if that’s your question
n
you'll for sure query the photos for a given user, or the photos for a given place
are you ever interested to query the user or place for a given photo?
p
Like, filtering by photo?
n
no
p
Like “who is the user/place of that photo”?
👍 1
n
Copy code
users {
  photos { metadata }
}

places { photos { metdata } }
do you also need to do
Copy code
photos {
  place { id }
}
or
Copy code
photos {
  user { id }
}
p
No, never. I will always be viewing and editing photos within the context of a user/place, so never querying them that way.
n
Copy code
type User {
  photos: [Photo!]!
}

type Place {
  photos: [Photo!]!
}

type Photo {
  metadata: Json
}
that's good, because you don't have to add the "backrelation" from 
Photo
to 
User
and 
Place
p
Oh, I don’t?!
n
no 🙂
in Prisma we have optional backrelations
p
I must have missed that in the docs 😞
n
so your concern
I guess it just doesn’t feel right to put a relation on a type when a single record of that type would be related either to a User or to a Place, but never to both
is somewhat taken care of with this
p
Will this also take care of the fact that if I delete a Photo it will be removed from the User/Place automatically?
n
yes
the relation is still "there" it is just not exposed in the API
p
Ok, and this, performance-wise, is still better than having two different types you say
n
there shouldn't be a difference performance wise
to me it feels simpler in terms of complexity
p
Ok
Sold!
n
you can also split it into two types if you feel that it increases clarity, but I prefer the other option
👍 1
experiment with the different options and see what works best with your use case 🙂 Just wanted to bring this alternative up, as it is my preferred way of designing things
🙏 1
2 Views
Open in Slack
PreviousNext
Powered by