our team is looking at how we can integrate Prisma...
# orm-help
s
our team is looking at how we can integrate Prisma into our planned stack (Vue + Apollo, AWS AppSync, AWS RDS). we'd like to keep Prisma serverless if at all possible.. and if it makes sense to do so. any advice on this?
m
Howdy! I think someone more experienced that I am will need to weigh in here, but I'd like to follow along because I have been thinking about how AppSync and Prisma could fit together. Right now, my only thought is that you could hook up a lambda resolver in AppSync to forward queries to a Prisma instance. But, I'm not 100% sure that really makes sense to do, given that you're just adding additional hops. If you don't mind me asking, what is it about AppSync that makes it an attractive option for you?
s
the big selling point for me with AppSync are Cognito & IAM integration (so users can directly access S3 and other services.. no back-end needed, no credentials). and of course, AppSync's tight integration w/ Cognito and AWS data sources is nice
(and of course, being serverless)
m
I hear you. The reason I asked is because I love AWS and use the services you mention in conjunction with serverless GraphQL/Prisma. But I tend to go without AppSync because, to me, it adds a layer of complexity (VTL) that ends up costing more than the benefit it provides.
s
VTL is a bit of a hurdle to learn, but it's also extremely powerful. I can create mapping templates to pull data from DynamoDB and split or join fields together before sending the data to a GraphQL client
๐Ÿ‘ 1
m
True. I guess I just am more comfortable doing that in JS with
graphql-yoga
or
apollo-server
and VTL is scary. ๐Ÿ™‚
w
@medelman Iโ€™m inclined to agree with you.. but Iโ€™ve not spent anywhere near the time playing with the ins and outs of the aws ecosystem the was Sam has. So I suspect itโ€™s mostly FUD (Fear, Uncertainty, Doubt) so I reserve judgement for now.
๐Ÿ‘ 1
Iโ€™m generally of the opinion that the tools i use need to be easy both to learn and use.. Iโ€™m a programmer.. Iโ€™m lazy.
๐Ÿ˜„
๐Ÿ™‚ 1
m
I've tried a few times to spin up an AppSync-backed service (that goes beyond the tutorials) and have ended up needing to stop after running into some frustration or another related to my lack of familiarity with VTL. At the end of the day, I always ask myself, 'Do I really need the offline support that AppSync will provide?' And the answer is always, 'No, probably not at this juncture.'
Because, in my opinion, I can have all of the AWS goodness I want with SAM or Serverless Framework and GraphQL with Prisma/Apollo-Server.
๐Ÿคทโ€โ™‚๏ธ 1
s
for me personally, the big appeal of serverless is infinite scalability and low cost. I also have a startup on the side and I'm re-architecting it from scratch. keeping costs down is a big priority for me, because everything adds up with all the third party services I have to pay for. as soon as Amazon announced they were building a serverless GraphQL platform, I was all in ๐Ÿ˜‰
m
Oh, no doubt, I am exactly the same way. Why waste money??
s
I was just about to message @Sam Hulickabout his reasoning for AppSync. I am also doing a backend overhaul that will interface with Vue/Apollo. Couldn't one solve this particular problem with service workers though?
s
service workers allow background notifications & caching content, right? that wouldn't give you a serverless GraphQL endpoint. unless I'm misunderstanding..
m
I think he's talking about the offline support?
s
I actually misunderstood your original post, but yeah that thought was regarding offline support.
Right now I'm using EC2 but I am going to have to look into AppSync. So many options ๐Ÿ™„
s
for sure ๐Ÿ™‚ oh I forgot to mention the other benefit of serverless: security. I'm always paranoid having an EC2 up and exposed to the public. also, you don't HAVE to use AppSync to get serverless GraphQL. before AppSync, I was using Express + Lambda + GraphQL
๐Ÿ‘ 1
s
That was another concern of mine too. Glad someone else is a step ahead of me ๐Ÿ˜
s
I'm glad you mentioned that actually. @medelman if you wanna skip all the VTL stuff, just put up a GraphQL server on Lambda. https://github.com/awslabs/aws-serverless-express
m
That's what I'm saying to you! ๐Ÿ™‚
I have Prisma on Fargate using Aurora, Apollo-Express on Lambda.
๐Ÿ‘ 1
s
ha. but then you have all the user auth stuff to deal with, right? and how to grant authenticated users access to your AWS services. AppSync solves that, but does present some other headaches. it's all a series of tradeoffs I guess. ๐Ÿ˜‰
m
I use cognito the exact same way that AppSync does.
s
we tried it with limited success. the whole load balancer & VPC/subnet thing threw us off
we'll take another stab today though
m
I believe I did use that tutorial, but I can't recall.
s
ah, so you just use Cognito auth in your API Gateway..?
and then use a dedicated IAM user to allow access to (for example) writing to S3, from within Express?
m
My GraphQL Lambda function is exposed to the public because some queries/mutations are suitable for public consumption. Users authenticate with Cognito client side and include their JWT to make queries/mutations that require authentication.
I wrote some middleware that verifies the JWT, etc.,
For S3 integration, I use signed putObject getObject URLs
๐Ÿ‘ 1
w
@Sam Hulick it sounds like @medelman is doing exactly what we need to do. And since we have no use for our app working offline, if thatโ€™s the only other thing weโ€™d get with appsync maybe weโ€™re overcomplicating things with it.
s
Express/Lambda/GraphQL was my first approach way back when (before AppSync). we can still do that. just need to figure out how to fit Prisma into all that
m
I'm happy to help with that aspect ๐Ÿ™‚
๐Ÿบ 1
s
cool ๐Ÿ™‚ so, let's say we get Prisma set up on Fargate or EC2 or something. where does that sit in the stack exactly?
w
Do subscriptions work if your graphql server is a lambda function? Like, does prisma serve up subscription data directly to the client, or are subscriptions entirely off the table in this scenario (which is what I assume)?
m
Prisma essentially sits in the same position as AppSync. Subscriptions do not work (to my knowledge) due to Lambda being stateless. However, I have heard there are some 'pretty complicated' non-Prisma-related workarounds.
s
Tangental question: are any of you dealing with file uploads? Documentation on that seems to be lacking a bit.
m
I do, but let's start a separate thread for that
๐Ÿ‘ 1
w
we will be once we move to this stack. I donโ€™t necessarily see much value to handling file transfers (in either direction) with graphql though, so donโ€™t know that it needs to be involved at all. imho it would probably be better to send to/from s3 (or similar) directly
m
Agree. I see no reason to have GraphQL involved (other than to store metadata)
So, for the application that I am thinking of, users upload photos in conjunction with micro-blog posts. The postCreate flow is as follows: (1) User posts GraphQL mutation to GraphQL server running on AWS Lambda; (2) GraphQL server (a) queries AWS' Natural Language Processing API for entities and key phrases based on the post title and content; (b) for each image, queries AWS S3 for signed upload URLs; (c) assembles disparate data to be schema friendly, updates the underlying data service (Prisma/Aurora on AWS Fargate), and responds to the client; (3) client reads response and uploads each image to S3 using the signed URL; (4) S3 upload event triggers an image processing Lambda function which grabs the image and simultaneously (a) performs machine-learning-assisted cropping and resizing for common screen sizes and (b) queries AWS' image recognition service; thereafter assembling the data to be schema friendly, updating the underlying data service, and uploading the new images to S3.
๐Ÿคฏ 1
s
geez. and you think VTL is complicated?! ๐Ÿ˜œ
๐Ÿ™ƒ 1
of course, our requirements for uploads are a lot simpler. we might take a stab at AWS Amplify Auth + Cognito and use the S3 SDK client-side
m
That will totally work. I use Amplify Auth + Cognito all over the place. Amplify also has the Storage module, which will likely get you 99% of the way there.
The only thing that makes me a little queasy about all-client-side flow is that there's no single source of truth for what's in your bucket.
s
right, that makes sense
I actually don't like Amplify's storage module. though it's probably better now. it was quite restrictive in how things are stored.. I didn't like that they force conventions on you.
m
That, plus, the whole
if its on the client it should be assumed to be untrustworthy
s
AppSync's complex objects are cool too (basically automatically uploading & associating S3 data with a new record). https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app-react.html#complex-objects
m
I don't use the Storage module either.
s
but I haven't really gotten into complex objects yet. it's on my list
m
Agree that theres some neat things that AppSync and VTL can do more or less out of the box (assuming you have a handle on VTL)
s
I wonder why they chose VTL of all things. I guess they wanted to remain language agnostic & not force people to use JS or something else
m
I ask myself that every time.