The big problem for me using a serverless architecture was constantly having to bend over backwards with the security model of firebase to accomplish things that are very simple when you have a layer of business logic under your own control on the server between the client and the database. Once the client can write whatever they want to the database, every single operation becomes an order of magnitude more difficult to develop as you imagine what ways the client could mess with you, and develop security rules to prevent that. The result-- and this was the dealbreaker for me-- is designing the backend data structure around security, instead of designing the backend data structure around the vitally important goal of supporting your business use cases.
In the end I decided it's better to just pony up and make a server. Service Fabric, and particularly the distributed actor model, gives me the realtime functions and reliability I want for my use cases without making me administer servers.
[1] https://docs.microsoft.com/en-us/azure/cosmos-db/introductio...
[2] https://azure.microsoft.com/en-us/services/service-fabric/
Another problem GraphQL hasn't tackled (afaik) is polymorphism. You can say "hey give me this person" or "give me this company", but what if you want a customer that can be either a person or a company?
http://graphql.org/learn/schema/#interfaces
searchPersonOrCompany(name: "abc") {
... on User {
first_name
last_name
}
... on Company {
business_name
}
}
As for the undetermined depths problem -- I agree to an extent.GraphQL can't return depths without you querying for it unless one of the field is a JSON blob.. but at the same time, I like that it does that.
In your example of menu w/ submenus, I think I would prefer to load the first 2 level, then preload level 3 when level 2 is activated, and preload level 5 when level 4 is activated, and so on.
Apollo makes this quite easy.
This is similar to what I would have to do server side if I were using SQL to get the data and then processing it to return a tree in JSON.
If I know how deep the tree will be (and it is only two or three levels) I query it directly with graphql
Providing a lot of flexibility to the client when querying the server eliminates a lot of server side work that would normally be required in order to implement new user stories.
It does require a bit of a mindset change so I am often having to force myself to try doing things in a different way to my first assumption.