I've been exploring Graphql for a project and I'm fairly new to it. I came across Relay JS by Facebook. It has a specification on how schema should be defined. My concern with this specification is it's somewhat tied to a JS framework.
Are there other specifications for defining Graphql schema?
There are no standards for creating GraphQL schemas!
Relay is the only GraphQL client right now that is opinionated about what your GraphQL Schema should look like, but I still wouldn't call it a standard. With all other clients (like Apollo or Lokka) the schema can be designed in any way you like!
For inspiration, you might want to take a look at how we design the GraphQL API at Graphcool. We're providing two different APIs:
Relay API: Follows the requirements of Relay
Simple API: Basic CRUD capabilities for each type in your data model
You can additionally include capabilities like ordering or filtering in the API.
it all depends on the server. If you dont need relay (like in my case) i have a custom scheme mapping to mysql db.
You are free to define your own scheme as long as each field is a graphql field
Related
I like the query types in Graphql, but I still need to control the local state. I am most comfortable doing this in Redux toolkit, in the future I will need subscriptions query.
From the information I have found here https://redux-toolkit.js.org/rtk-query/usage/customizing-queries but will it work with subscriptions request.
Is it possible to implement all this in next.js?
I am testing a graphql api and I want to integrate with my system in laravel. Is there any documentation to do this? If possible to consume and send the values in graphql?
Note: I wanted to do it right
The question is too generic.
First of all, I recommend to check the official site: https://graphql.org/learn/
If you are going to consume an already existing graphql, you need a graphql client library.
Check a good list of client libraries: https://graphql.org/code/#graphql-clients
Client libraries have good documentation on how to install and use them.
If you are going to create/provide your own graphql api endpoint (that is a different story), you need a graphql server library.
Server libraries: https://graphql.org/code/#php
Laravel package (a wrapper for https://github.com/webonyx/graphql-php): https://github.com/rebing/graphql-laravel
try this library https://github.com/rebing/graphql-laravel, it's simple with good documentation
I have a Golang program working with Twirp and I want to create GraphQl server, but as far as I know, twirp build on top of the Rest API
It is definitely possible.
You Just have to make a wrapper over the Twirp based RPC API.
This is a similar case to wrapping a GraphQL API over a Rest API.
You should also read this article, where the wrapping of a graphql api over a rest one is shown.
My idea is to create a microservice approch with graphql and serverless.
I'am thinking about creating a service for every table in the dynamodb and then create a apigateway service, and in the apigateway service use graphql-tool to stitch the schemas together.
This work pretty good and I'am satisfied.
But now I want to add authorization to my graphql queries and mutations.
I have added a custom autherizer in the apigateway that resolves the JWT token from the client and sends it to the graphql context with the userId
But now I want to add authorization to my resolvers.
What is the best approach for this?
I want it to be as moduler as possible and and best (i think) is to add the authorization in the apigatway service so my other service stay clean. But I don't know how?
Any ideas?
You may want to look into AppSync from AWS. It will handle a lot of this for you; authorizers, querying DyanmoDB, etc.
I've built Lambda APIs using Apollo GraphQL and exposed them through API Gateway. I then used Apollo's schema stitching to connect them together. There's one really important caveat here: It's slooow. There's already a speed penalty with API Gateway and while it's acceptable, imagine jumping through multiple gateways before returning a response to a user. You can cache the schema which helps a bit. Your tolerance will depend on your app and UX of course. Maybe it's just fine - only you (or your users) can answer that.
That note aside, the way I handled auth was to accept an Authorization header and make a check manually. I did not use any custom authorizers from API Gateway. I was not using Cognito for this so it talked to another service. This all happened before the resolvers. Why are you looking to do the authorization in resolvers? Are there only some that you wish to protect? Access control?
It may not be best to add the custom authorizers to API Gateway in this case...Because you're talking about performing this action at the resolver level in the code.
GraphQL has one POST endpoint for everything. So this is not going to help with configuring API Gateway auth per resource. That means you're now beyond API Gateway and into the invocation of your Lambda anyway. You didn't prevent the invocation so you're being billed and running code now.
So you might as well write your custom logic to authenticate. If you're using Cognito then there is an SDK to help you out. Or take a look at AppSync.
Is it a good practice to have a viewer for GraphQL mutations? Theoretically this makes sense to me as some mutation end points shouldn't be possible if you are not logged in, etc.
But when I see examples on the web, I only see implementation of GraphQL viewers for queries. For mutations, I do not see any implementation of viewers. For example, the GitHub API doesn't have a viewer on top of all their mutations.
The viewer field isn't a good practice, either for mutations or queries. It's a remnant of Facebook's legacy GraphQL platform from before it was open-sourced, which didn't allow arguments on root query fields. This meant that all of the fields needed to be moved one level down, below viewer.
The current way to do auth in GraphQL, at least in the JavaScript implementation, is by getting the user data based on something like an HTTP header and putting it on context, as mentioned here: http://graphql.org/learn/authorization/
Therefore, there is no reason to do viewer for mutations, or for queries. Most GraphQL clients don't mind, but one situation where it could make sense to have it in queries specifically is if you are using Relay 0.x, which has inherited some of Facebook's legacy GraphQL limitations. Hopefully a future version of Relay will remove this requirement.
For an additional source, read this comment from Lee Byron, one of the original creators of GraphQL.