Roll your own versus existing GraphQL implementation for PWA
Published: 2020-05-22 23:37:55

[Uclusion](https://www.uclusion.com/?utm_source=devto&utm_medium=blog&utm_campaign=devsansgraphql) has a PWA client that needs to

1. Keep a local data store in sync in a React app

1. Have back end extensive business logic

1. Store to a back end database

How much of the heavy lifting do we have to do? For instance what if we use [AWS AppSync](https://aws.amazon.com/appsync/)? Well according to [this post](https://stackoverflow.com/questions/52141588/aws-appsync-dynamodb-with-business-logic) from 2018 that would require writing our business logic in [Resolver Mapping Templates](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-overview.html). I don’t see anything in the documentation to suggest that has changed and those templates are written in [Apache Velocity Template Language](https://velocity.apache.org/engine/1.7/user-guide.html) (VTL). So that’s a no on AWS AppSync unless you are willing to have your business logic in the front end or use VTL.

What about [Firebase](https://firebase.google.com/)? Looks like the same basic problem according to [the documentation](https://firebase.google.com/docs/firestore/security/overview):
> For **mobile and web client libraries**, use Firebase Authentication and Cloud Firestore Security Rules to handle serverless authentication, authorization, and data validation. Learn how to secure your data for the Android, iOS, and Web client libraries with [Cloud Firestore Security Rules](https://firebase.google.com/docs/firestore/security/get-started).
> For **server client libraries**, use Cloud Identity and Access Management (IAM) to manage access to your database. Learn how to secure your data for the Java, Python, Node.js, and Go client libraries with [IAM](https://cloud.google.com/firestore/docs/security/iam).

Cloud Firestore Security Rules look to be a VTL equivalent and so are out. IAM seems to control, at a granular level, what operations a client can perform but that’s not the same as being able to run business logic on each operation.

Further Googling shows that GraphQL platforms in general might have this opinion. For instance [Apollo GraphQL](https://www.apollographql.com/) says:
> REST APIs are not a good fit for modern apps because they require large amounts of hard-to-manage data fetching code.

Its all about read and no mention of write. Extensive business logic may not fit easily into an [architecture](https://www.apollographql.com/blog/how-to-build-graphql-servers-87587591ded5) designed for fetching data.

I welcome comments from users that have found a platform where they didn’t have to write the sync layer but still were able to program business logic freely. Its certainly not wine and roses on the roll your own side either as Uclusion had to go to a LOT of trouble building a layer to keep data in sync. We will be exploring how we did that in later posts.

What we can say for certain is that [AWS API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) is fairly mature technology available for Rest APIs. Yes you could use an API Gateway to shoe horn in your own GraphQL as [this blog does](https://www.serverless.com/blog/running-scalable-reliable-graphql-endpoint-with-serverless/) but GraphQL without an out of the box data sync implementation is like autumn leaves — pretty but missing essential functionality.