3 ms·
A lot of these can be addressed using a combination of Apollo GraphQL and dataloaders. This is especially true if you move most of the hard work to the backend
by robjan 5y ago
A lot of these can be addressed using a combination of Apollo GraphQL and dataloaders. This is especially true if you move most of the hard work to the backend and use optimistic updating on the front-end to improve the user experience.
- adeptima 5y ago- GraphQL leads to a vendor lock commitment ... which is great if you can sell it to your clients and dominate with your expertise https://www.apollographql.com/docs/apollo-server/data/data-sources/ https://www.apollographql.com/docs/apollo-server/data/data-s...
- robjan 5y agoGraphQL is an open standard. If you don't like Apollo which, by the way, is open source; you can choose other libraries. To an extent all technology choices produce some level of lock-in, including REST, otherwise you end up rolling your own operating system and transport layer.
- hn_throwaway_99 5y agoThis is plain absurd, especially given the page you linked to is about completely free and open source tools.
- adeptima 5y agoDont think it's absurd... This is just an objection in sales terms. First impression is very hard to change. This is why I asked I wish someone address it more.
- hn_throwaway_99 5y agoI just am baffled how someone can think there is a lot of "vendor lock in" with GraphQL. I am a huge fan of GraphQL, I have used it on large, production systems for years, and I have never even paid any money to any GraphQL tool vendors. Basically all of the good tools are completely free and open source.
- dtech 5y agoThe spec is open and not that hard to implement should it become necessary. I'd say that the vendor lock-in is lot lower than with your typical open-source large dependency like React or Spring, and people are generally happy to accept that.