This is an early stage project template for using Prisma with the Serverless Framework. It’s written in TypeScript and compiled with Babel 7 & Webpack 4.
@meep There are two entrypoints
webpack.config.js). These were split, not too long ago, into separate files. This was done to ensure that Webpack is properly “tree shaking” the compiled handlers and only packaging the necessary npm packages. This also ensures the built artifacts are as small as they can be so whenever your lambda function executes from a “cold start”, it does so a little bit faster.
Awesome. So in terms of design you have
src/graphql.ts handling the in-bound queries and passing them to the resolvers which run inside the same function. When using AWS Lambda, how do you think about running your graphql server inside one function versus calling a separate AWS function for each resolver?
I’m using Apex Up to deploy my graphql-yoga server to AWS Lambda. I think it has a reverse proxy but it’s basically the same thing as yours whereby my server is inside one function (plus playground). I’d love to figure out how to speed up cold starts. I’m transpling from Typescript. See this repo I put together up-graphql-yoga-server-example
I’ve had the thought to breakdown resolvers into their own functions but never tried it out. We decided against it for two reasons. The first being calls to Lambda; we didn’t want to exponentially increase our Lambda usage. And second because we use the AWS SDK Step-Functions in many of our GraphQL resolvers (For Dashboard Apps mostly). In the Step-Function handlers we make https calls to the main GraphQL handler.