sreynen
commented
7 years ago I looked through the graph.cool docs a bit, and I'm not convinced GraphQL makes scaling any easier. Having schema defined in a text file makes it easy to describe schema changes, but actually implementing those schema changes in a live database is still complicated and abstracting that complication behind GraphQL sounds more complicated to me, not less.
https://www.graph.cool/docs/reference/migrations/overview-paesahku9t/ shows how to make relatively minor schema changes with graph.cool figuring out the details, but it doesn't cover anything that involves moving data between schemas, which seems like the hard part. A REST API backed by DynamoDB doesn't make data+schema migration easy either, so I don't see an advantage either way here.
I do see an advantage in DynamoDB/Lambda in price, which is my primary interest in scaling. I think the most likely failure scenario for this project is no one uses it, and scaling doesn't matter there at all. But the second most likely failure scenario is just enough people use it that it starts costing more than I want to pay for it. So many people using it that the tech falls over seems incredibly unlikely to me, not a scenario worth planning around before even a single user.
So cost-wise, graph.cool is free up to 100k requests per month, while DynamoDB is free up to 200M requests, or 2000x as many. graph.cool is only $9/month at 1M requests, which seems like something I'd be willing to pay for something being used that much. But that also has a cap of 500MB for storage, which I could imagine not being enough at that much traffic. So at that point I'd already be worrying about the $49/month price, which would definitely get into the kind of worrying about budget that I'd much rather avoid as long as possible. Whereas DynamoDB offers 25GB storage for free.
That's all priority #1 in https://github.com/lalalaio/plan/wiki/Technical-Architecture. I also like DynamoDB better for priority #2, keeping the tech simple to focus on the product. I'd like the tech here to be boring. Even DynamoDB involves a little more thinking about the database layer than I'd like to be doing, specifically around indexes. In theory, GraphQL completely hides the database layer with something like graph.cool, so I don't have to think about it all, and that would be better. But in practice, something always breaks, and then additional layers of abstraction get in the way. I don't trust that database layer issues won't happen with GraphQL, and when they do happen, I'd like to be able to address them at the database layer directly.
So I want to stick with using DynamoDB directly for now, but I also think it's way too early to be making any solid decisions on this. What data we'll want to store is still incredibly speculative. For example, it still seems totally plausible that music will turn out to be the wrong way to connect without words and we find instead something more visual is a lot better, which would probably change this discussion a lot.
Let's leave this open and come back to it when we have a clearer picture of needs.
killtheliterate
http://graphql.org/
what I recommend is browsing the graph.cool docs for some inspiration as to the power and flexibility of defining your data layer as strict types in a graph.
scaling is hard and I think that's usually because of how you modeled or didn't model your data. Keeping it in a standard version controlled flat text format gives your data layer the same maintenance flexibility as your logic and UI (because:
git)that is my proposal