Wrap multiple 3rd party GraphQL APIs in a single GraphQL endpoint - api

Vendors like GitHub are beginning to provide their own GraphQL APIs as an alternative to the existing REST APIs. However many apps shouldn't talk to these APIs directly and instead talk to first-party servers that in turn speak to these APIs.
With REST APIs it's trivial to proxy an entire third-party API from a single endpoint. But the existing GraphQL libraries all seem to need to know the full GraphQL schema in advance and there doesn't seem to be any way to specify queries or types to be defined at run time.
The even bigger problem seems to be that the entire GraphQL query will be parsed in advance. In order to pass on a sub-query to a third-party API that GraphQL fragment would have to be preserved or reconstructed.
Here's an example that doesn't work:
new gql.GraphQLObjectType({
fields () {
return {
thirdPartyApiCall: {
type: '???', // Type is actually defined upstream
resolve () {
// GraphQL sub-query is already parsed at this point
return thirdPartyGraphQLApi(graphQLSubQueryGoesHere)
}
}
}
}
})
I think part of the answer could be to use introspection queries to generate the type in this example dynamically, once, when the schema is loaded (though of course this means it won't reflect changes upstream unless it is re-generated frequently) but I'm at a complete loss as to how to get the original GraphQL sub-query to pass on to the third party.
Is this currently solvable in GraphQL without writing a custom GraphQL parser/handler or does GraphQL currently not support this kind of delegation (i.e. wrapping 3rd party GraphQL APIs directly)?

User #jbinto from the GraphQL community Slack helpfully pointed me at this currently unsolved GitHub issue on the graphql-js implementation: https://github.com/graphql/graphql-js/issues/490
Currently the answer seems to be "it can't be done" but the maintainers are looking into it, now that GitHub created the first major public GraphQL API.
It's worth following the development of the issue on GitHub and seeing what solutions arise from the discussion. The driver may support this scenario in the future or a userland solution may come along that solves it. There are a lot of open questions as to the specifics at the moment.

Related

GraphQL vs. REST for triggering Backend Action

i am new to GraphQL, and i know that GraphQL has many advantages over REST specially when it comes to returning data from backend to client.
But my question is about the cases for triggering a backend action, when the returned response data from backend is not as important as response code for example, since GraphQL always return 200., also in such cases we are not requesting dynamic data (ex: database entity data)
For example a case of developing an endpoint to /verifyEmail, /forgetPassword for example.
For such cases for example the client does not ask backend for data, but it is actually triggering an action, for example sending verifyEmail or forgetPassword email.
my questions are:
Is it favourable to use graphQl in those cases or REST? and why?
Also is it a good practice to develop an API which have both GraphQl and REST endpoints?
It really depends on the needs of your application. If your backend needs to have a mixture of REST and GraphQL, because it's an older project or you are scaffolding something quickly, I think that's fine. There are plenty of reasons why you might keep your internal api on REST and serve your public data through GraphQL. That being said, you could definitely build your app to only consume GraphQL endpoints if you felt that was advantageous.
Since you are new to GraphQL I'd recommend checking out https://www.howtographql.com/ and doing a few tutorials before making a decision.

How to authenticate multiple api using Nuxt and nuxt-auth module

I have an application with (nuxt js using nuxt-auth) with local authentication so far (later I want to add git and google auth).
Now I need to add authentication to invoke other services / API (like google cloud rest API, payment system, youtube API, etc...)
The question is: the user is authenticated only once (during login to the application.) but each of these 3rd party APIs has its own authentication.
How to implement multiple authentications. (I read the documentation and google for the entire day but there is no clear answer).
As of today, it looks like it is not doable (people are needed on this module): https://github.com/nuxt-community/auth-module/issues/889
So, you would need to make it manually by plugging the APIs yourself.
Answer to your latest question~comment
Nuxt is indeed nice with some of it's modules (but you can totally dislike it, no problem :D).
First thing that you need to know, is that this project (nuxt-auth) is not the biggest one, #pooya is doing his best but he is on a lot of projects, so he cannot give all of his love to it. Then, you also need to understand that it's working great but it's still in a decent beta state with a lot of missing features, needed documentation and a lot of small things to make it an all rounded solid top notch solution.
That do not mean that you should not use it, I'm just saying that this module do have some limitations. Hence, the fact that it is not supporting a whole lot of OAuth solutions in a clear + simple + flexible way. And some breaking changes may be introduced in future updates.
The module is aimed towards having an OAuth solution to block the content of your website behind it (in my opinion). It means that you will usually use a single login solution and then, being able to have access to your app. I don't think that it's a viable multi-OAuth solution (yet).
Some services don't even need to use a solution like this. Stripe for example, should not be handled on the frontend but communicate with a backend for sensitive variables and just send minimal info thanks to Stripe Elements.
That said, the most common solution is JWT or OAuth2, and you could totally have a backend service or service like Okta, Auth0 or alike, do the heavy lifting by allowing simple logins to providers (Github, Google etc...).
To sum up, you do connect to this backend/service thanks to nuxt-auth, the service itself does the provider connection and you get the best of both worlds while still connected in a secure way through your initial nuxt-auth entry point login.
Or you could try to reach the community on Discord, see if somebody knows how to do it. Or even try to read the source code to see if it is currently feasable.
And that's my 2cts.

Is a restful API and a backend service (like Parse) the same thing?

Rest confuses me sometimes. I know that it involves creating an API layer over your data and then you make calls to that data through the API. The best way I think of Rest is that the actual Twitter website interfaces with the data-layer through API calls.
That made me wonder then: Is a backend-service like Parse also a Rest API to your data?
What might be the difference between Parse and say, building your own Rest API like this guy did: http://coenraets.org/blog/2012/10/nodecellar-sample-application-with-backbone-js-twitter-bootstrap-node-js-express-and-mongodb/ (he's getting some solid google rankings for his API tutorials).
A simple yes/no might answer the question, but providing details will really be appreciated.
I look forward to the answers.
Parse is built around a restful API just like most, if not all, other mBaaS out there.
A RESTful Api isn't just CRUD operations though nor is it the same thing as Parse. Parse is a company that provides a remote backend to developers using a RESTful api.
RESTful api !== BaaS
I have dealt with about 5 mBaaS and Parse isn't really one of them, but I've glanced at their API reference for JS and I think they use mongodb clusters. An mBaaS usually provides the developer the ability to have cloud storage, push notifications, server side code, easier social media integration, and mobile analytics. So it's not just any backend. Although there are some mBaaS, like Urban Airship, that only supply push notifications to developers.
A RESTful api at it's core usually has some key functions that are centered/wrapped around an httpRequest
They usually use "GET", "POST", "DELETE", and "PUT" to make all calls. Some allow the implementation of rpc for custom server logic. An mBaaS takes a lot of work to implement right and well. You can't build Parse in a Day. It takes a lot of planning and such. The differences between Parse and that guy in link are in the implementation, range of features, and purpose in general(the audience).
To better understand REST maybe look here you can also read the HTTP spec if you are feeling adventurous.

Set up mock API server for isolating frontend-backend dependencies

Our application is a API based one wherein the frontend relies on REST API calls to the back end. This sometimes creates a problem wherein the frontend team can't move forward unless the backend API's have been implemented since they invariably progress at different speeds. Is there a way to set up a server so that the front-ent can work independently regardless of the backend status ?
I know this is a bit of an old post but I created a tool just for this purpose and I thought I should share it for anyone who stumbles across it.
It's called Interfake and you can find it at https://github.com/basicallydan/interfake. I frequently use it for prototyping APIs which haven't been built yet, in fact that is my main use of it. I hope that helps.
A common solution that we work with is as follows :
FE and BE contracts/APIs are agreed upon and the back end apis are mocked.
The BE rest APIs use a filter that we configured.
For all the apis that are ready, the filter redirects to the correct api and for all the apis that are mocked the filter redirects to the mock api.
So transparent to the FE team as the BE team is building and completing more apis, they just update the map that the filter looks and and automatically the back end apis get invoked as soon as the BE team is ready to open it up.
So the flow is as follows :
FE ->BE Rest API Server
|API Filter->(for apis updated in the map as complete)-->server/port with actual api
|------------->(for apis that are still being mocked) --> server/port with mock
Hope that helps.

What should a developer know before building an API for a community based website?

What things should a developer designing and implementing an API for a community based website know before starting the heavy coding? There are a bunch of APIs out there like Twitter API, Facebook API, Flickr API, etc which are all good examples. But how would you build your own API?
What technologies would you use? I think it's a good idea to use REST-like interface so that the API is accessible from different platforms/clients/browsers/command line tools (like curl). Am I right? I know that all the principles of web development should be met like caching, availability, scalability, security, protection against potential DOS attacks, validation, etc. And when it comes to APIs some of the most important things are backward compatibility and documentation. Am I missing something?
On the other hand, thinking from user's point of view (I mean the developer who is going to use your API), what would you look for in an API? Good documentation? Lots of code samples?
This question was inspired by Joel Coehoorn's question "What should a developer know before building a public web site?".
This question is a community wiki, so I hope you will help me put in one place all the things that should be addressed when building an API for a community based website.
If you really want to define a REST api, then do the following:
forget all technology issues other than HTTP and media types.
Identify the major use cases where a client will interact with the API
Write client code that perform those "use cases" against a hypothetical HTTP server. The only information that client should start with is the response from a GET request to the root API url. The client should identify the media-type of the response from the HTTP content-type header and it should parse the response. That response should contain links to other resources that allow the client to perform all of the APIs required operations.
When creating a REST api it is easier to think of it as a "user interface" for a machine rather than exposing an object model or process model. Imagine the machine navigating the api programmatically by retrieving a response, following a link, processing the response and following the next link. The client should never construct a URL based on its knowledge of how the server organizes resources.
How those links are formatted and identified is critical. The most important decision you will make in defining a REST API is your choice of media types. You either need to find standard ways of representing that link information (think Atom, microformats, atom link-relations, Html5 link relations) or if you have specialized needs and you don't need really wide reach to many clients, then you could create your own media-types.
Document how those media types are structured and what links/link-relations they may contain. Specific information about media types is critical to the client. Having a server return Content-Type:application/xml is useless to a client if it wants to do anything more than parse the response. The client cannot know what is contained in a response of type application/xml. Some people do believe you can use XML schema to define this but there are several disadvantages to this and it violates the REST "self-descriptive message" constraint.
Remember that what the URL looks like has absolutely no bearing on how the client should operate. The only exception to this, is that a media type may specify the use of templated URIs and may define parameters of those templates. The structure of the URL will become significant when it comes to choosing a server side framework. The server controls the URL structure, the client should not care. However, do not let the server side framework dictate how the client interacts with the API and be very cautious about choosing a framework that requires you to change your API. HTTP should be the only constraint regarding the client/server interaction.