Is it possible to use OpenFaaS with Slash GraphQL?

Slash GraphQL is great, we’ll be able to mutate and query most of our data directly from it. However, some requests require data processing before being inserted, for example, uploading a CSV file that needs to be deserialised into objects/schema types. One way to solve for this is to set up a middleware API that handles these types of requests, so for example we’d use our Elixir+Phoenix API to handle the uploadCSV(file: String!) request, and then insert the data into Dgraph with liveforeverx/dlex.

However, it seems like we could avoid the boilerplate involved in managing this API (writing graphql resolvers mostly) by sending the request to Slash GraphQL and having Slash use a lambda to process the CSV before inserting the data. It kinda seems like Slash expects you to store all of these lambdas in a single JS file, but I can see that quickly turning into a nightmare to manage—I don’t want all our business logic in one file.

What seems like a better solution is to use a FaaS framework like OpenFaaS hosted on Okteto but I’m not sure how I Slash GraphQL and OpenFaaS would communicate with each other (would I embed API calls in one-liner Slash GraphQL lambdas and an OpenFaaS function would insert the data and return a success/error message to Slash that in turn returns it to the client?) and whether it actually makes sense as a solution.

It doesn’t have to be in one single file. You can use webpack and target webworker to compile your code into one single file that you upload to Slash

Not keen on this solution, as it seems it’d make us more vulnerable to broken builds. I think Dgraph Lambdas make sense for small things like dynamic values on fields like @mrjn is doing here:

@amaster507 directed me to Custom Directives, this is fantastic feature (makes it possible to forward Dgraph requests to an external http endpoint). Given we are building a backend that makes use of Event Driven Architecture and we want to separate our backend into isolated composable modules (which will make it easier for us to experiment with ML models), it makes more sense to keep all this logic in an external API.

EDIT: For anyone else trying to get their head around how Dgraph makes different architecture patterns possible, @bkennedy’s talk here is really elucidating