search

Pocket / curation-tools-frontend

DEPRECATED
Mozilla Public License 2.0
10 stars 52 forks source link

add an abstraction layer to the API #99

Closed jpetto closed 3 years ago

jpetto commented 3 years ago

after we have a few pages making API calls - read on the prospects page, write on the add story page, update on the edit and approve page - we should refactor our usage of the API to remove the direct dependency on our specific dev API.

the general idea is to create a layer in-between the application code and the code actually calling the API. this would allow us to swap out API details/code without changing any application code.

if a planning phase would be helpful with this phase, please feel free to add ideas here for review before going to the code.

nina-py commented 3 years ago

I am eyeing this package with interest: https://github.com/marmelab/json-graphql-server:

Get a full fake GraphQL API with zero coding in less than 30 seconds.

If we can get it working as the default API, a layer of abstraction won't be needed at all - rather, just an environment variable to specify which client to use with Apollo - the default one or the AWS one.

nina-py commented 3 years ago

I have tried the json-graphql-server package and it's a bit too opinionated for our goals - I can't mirror the API's schema with this package and maintaining two sets of GraphQL queries (that would have to be abstracted into an additional layer of logic) does not sound very appealing. I'd rather have that extra abstraction layer but use something drastically different as the backend API so that there is less chance of buggy code and people getting confused which GraphQL query to update further down the track. Will look for something else...

nina-py commented 3 years ago

Okay, so the current plan is to use the json-graphql-server after all but abstract away any differences between the queries to this default API and the actual API the curation tools frontend is going to use in production.

My plan is to keep the old code that uses the AWS AppSync API, abstract the API calls away and make sure I can switch seamlessly between the local and the AppSync APIs, and then retire the AppSync-related code as it won't be needed in the future.

I will start with abstracting calls in App.tsx to get the current feed, then move on to the Prospects page, and then to the two mutations we have set up already (createProspectByUrl and approveProspect). So that I don't end up with a large PR that takes days and days to whip into shape, I think the next PR I will do will be just the "get current feed" one. That means that on the AppSync API everything should work as normal, but on the local API the feed should be fetched, displayed on the page and used in URLs, but the listProspects query should respond with an error and mutations won't work - the latter will be fixed in subsequent PRs that will abstract away more API calls. What do you think, @jpetto?