search

vapor-community / PackageCatalogAPI

A replacement for the IBM Swift Package Catalog.
6 stars 0 forks source link

GraphQL usage #2

Open ScottRobbins opened 6 years ago

ScottRobbins commented 6 years ago

I'm curious about the choice of GraphQL and using Github's API. What kind of benefit are you trying to get out of using GraphQL? (and "I thought it'd be an interesting technology to use" I totally understand)

I also notice that your queries are built as multiline strings with hand-corrected indenting, etc. It looks like there are a couple GraphQL Swift libraries that could be used here, or forked if they need updating. Do any of those look useful?

kiliankoe commented 6 years ago

What kind of benefit are you trying to get out of using GraphQL?

I used github's graphql api in apodidae (same query for repos as here) since it allows the client to aggregate all necessary data in a single request, especially the existence of a manifest file, which would otherwise require sending of multiple requests against the "old" github api.

ScottRobbins commented 6 years ago

Your apodidae library needs to fetch data every time someone searches, and making extra network requests means real latency that a user has to wait for to get a result. Optimizing for less requests makes perfect sense to me.

Perhaps some of my curiosity comes from the other issue I have open, which is as question as to what this project is trying to become.

I would imagine if you are making the SPM version of rubygems.org, you won't be making requests to search for packages on GitHub every time someone searches for something, you will be cacheing all of that information. You may not even update it until a package owner manually asks your service to reindex their package. The benefits of optimizing for less requests seems minimal.

I don't mean to say that GraphQL isn't the right solution anyway; less requests is always better, and GraphQL can make fetching the information you care about easier (in theory, I have very limited experience with it). I just don't see GraphQL a lot in the wild so I find it interesting when projects opt to use it.