GraphQL and dataLoader on separate applications/servers

Viewed 686

I plan to implement a GraphQL API in .NET on IIS and dataLoader API as a Node.js app server. GraphQL will interface to dataLoader to SQL Server.
All applications will be on a single physical server for now, but may possibly be separated in the future if scalability requires.

My reasons for this:

  • Existing code depends on IIS/COM/DCOM/ActiveX/.NET/ASP/ASPX
  • Simpler to implement and reason
  • Access control (web server doesn't need to see dataLoader code and ACLs can be implemented in dataLoader)
  • Makes it easier if I get the chance to interface with a different db (redis, mongodb, etc)
  • I can gradually slice and port parts of the code to allow easier code sharing (with separate Linux servers)
  • (I like) Node.js open to exploration, but cannot opt-in yet

First off, does this make sense or am I asking for trouble?

Would it make sense to use a binary serialization format between GraphQL and dataLoader? Or perhaps just a simple web service would be simpler?
Am I risking performance problems from more round-tripping? (Question too open-ended? Intuitively it seems like this would scale better eventually)
Is there a need for explicit authentication between GraphQL and dataLoader? Or can I just send session data (with username) through as-is and just let dataLoader trust the username given as context? Maybe pass a token? Are JWT tokens useful here?

1 Answers

GraphQL-dotnet has matured a bit since then and is looking pretty good.
I've since looked into solutions like AWS's API Gateway GraphQL support, and some Azure Functions solutions that support GraphQL.

Some of the techniques and design choices involved in these things were helpful here and there. But due to practical reasons, this never really came to fruition and most of these concerns never became relevant.

Related