Hello, looking at building enterprise healthcare applications using Appgyver’s Composer Pro on the front end and connecting it to FaunaDB or a MBaaS like Back4App or Backendless. I’m very technical, for a healthcare executive
My thinking was that might be best not to expend a bunch of resources on mapping the front end to a complex REST API with tons of URLs like Backendless or Back4app and that perhaps FaunaDB is the best fit since I will have concurrent users and many real time data use cases where I worry about not having strict serialization and with a graphql api, wouldn’t I simply need to create each type of transaction in Appgyver’s Data mgmt/variable area once (create, delete, update, etc)? Wouldn’t I need to create one set of such transactions for each table for a rest api if each table has a different URL so if I connected Appgyver to Backendless that uses REST? so if I have 350 tables that I need to do transactions on, I’d have to build out a create X, create Y, create Z (one for each table/resource/url)?
Sorry for my noobness and I’ll appreciate any help.
Hey Dan, I just saw that nobody responded to your question however I have to be honest that I struggle to respond since I have little experience with how Appgyver works and therefore might not understand your question.
I would indeed not do that, pure rest would mean many calls to get your data and if you start glueing reads together from different rest APIs instead of reading them in one query it will not give you the same database guarantees.
That seems like a perfect fit indeed.
And this is the part that I don’t understand. Probably because you seem to be talking about a custom GraphQL API. If you would use Fauna’s GraphQL API it will work quite different and you would be able to write a GraphQL query out-of-the-box that does transactions over multiple collections/tables.
Not in Fauna at least, you would create your schema and Fauna generates a set of resolvers for you for most CRUD operations. Maybe your question has to do with Appgyver that would be in front but I can’t answer to that. For this amount of data/tables I would consider using FQL directly though since I expect that you would want the flexbility to optimize your queries and might need more expressiveness than GraphQL.
(or you could you can also opt to write resolvers in FQL for those custom things but that would be slightly more complex)
