Definitely compelled by GraphQL for queries and, as things are starting to mature, warming up to how GraphQL models writes (or 'mutations'). https://www.opencrud.org Still super early days! Straight up DynamoDB.DocumentClient is good enough for most purposes.
Truth. Writes are usually where the complex business logic lives. It is common to expose a simple write call that does complex things under the hood. All of these BaaS offerings have always struggled with that. GraphQL doesn't fix the problem.
-
-
Ya my vibe precisely. Still dig for the reads tho! Right up until custom resolver logic is required (wherein I begin to question the proposed value again).
-
I've seen the value prob there. Tying into legacy DBs and APIs was extremely helpful in Bustle's move to serverless and eventually off those legacy systems.
End of conversation
New conversation -
-
-
Not sure I'm following. For writes/validation, couldn't you do the reads, etc on the client to validate and enforce access control, etc. I think with firebase you can then apply rules that are enforced at the server level for access control as well.
-
I genuinely want to learn, so please inform me

-
I'm saying most BaaS platforms struggle with doing business logic on write. Eg: "Create Payment" API call may result in a bunch of different DB objects being created. Possibly stuff that can't/shouldn't happen on the client.
-
This was my concern with BaaS as well. In my research, which isn't extensive, it seems like Firebase has a half-way decent solution to this. That said, I agree this is the scary part of this sort of system and my primary concern about going all in on it. I'm still researching.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.