![]()
Our findings were that static analysis allows to determine (relatively strict) upper bounds on query complexity, which we assessed for two production GraphQL APIs (GitHub and Yelp). We did research on solving the DOS issue using static analysis at IBM (cf. It’s tried and true methods that will work for many many use cases. I won’t judge you for wanting to stick with REST. It is, and that’s purely a business decision to make money pivoting devs to a new library/environment. It’s all do-able with either tech and you are correct in feeling like it’s re-inventing the wheel. I also find that out of the box, the type safety guarantees of GraphQL are a lot cleaner/batteries include than the REST work I did the many years prior. Again, you can do this in REST too with layered API’s, but GraphQL arguably makes it somewhat easier to do this with just config files. You can define the mappings from the child schemas to the god schema in another spec that has no code, just a federation schema. This is useful when you are a big company, merging two architectures with different API’s together under one umbrella. At scale, this is huge for our bandwidth cost savings.Ī second big win is federation of many GraphQL schemas under one giant god schema. Graphql as a universal database abstraction plus#That plus the allowed query rules stuff comes free in Apollo GraphQL now. I have access to an API directly and can save bandwidth by only querying and returning what I explicitly want in the data. I’m not going to argue whether one is better than the other implementation wise. One of the objectives of GraphQL is to replace REST, so yes, you’re right, it’s re-inventing REST. Keep public communication channels as dumb as possible. It's somewhat akin to exposing a SQL interface it opens up too many avenues of trouble. I'm not a fan of graphql for anything that the public could see. Note that even if you use graphql for a private api to your web client, folks will reverse engineer it and use it for their own purposes. The schema is a huge ugly mess with extra layers that never show up in the pretty examples of GraphQL on the internet. They have rate limits based on quantity of data returned. If you want to see the kind of work you actually need to put in to make a graphql API, look at Shopify. The more fine-grained nature of boring REST calls makes it more easy to control client impact on the system. It's easy to construct a query which puts unreasonable load on your system. Graphql as a universal database abstraction download#The biggest problem with graphql is that you have to do a lot of non-obvious work to harden your system against DOS attacks or people that want to fly by and download your whole database. Please any senior dev's drop your wise words so that any new dev's can avoid tarpits Invest your time in a simpler solution then running to GraphQL first No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03ĭon't use Graphql unless you're managing a solution/problem set that facebook intended graphql for Some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a somewhere It doesn't support map/tables/dictionaries. Graphql as a universal database abstraction code#Two or more type systems if there are no code first generates in your language It is actually a pain to use, depending on the backend you are using you'll have to manage It can make subscription easier for you to use It makes documentation for data consumers easy It makes working with describing the data you want easy This is probably more of a rant or a frustrated dev outburst.īut beginner to mid level developers are lead down the path of USE GRAPHQL especially on youtube. Graphql is great, but is totally over hyped. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |