Let's say I've got the following:
A giant GraphQL schema for some service (in .graphql or introspection json format)
A set of operations that my code wants to perform against that query.
I'd really like to generate a "subset schema": just the pieces (types/enums/etc) of that big schema that my service actually uses. Is there a tool or a piece of code that can do this today easily?
The reason I want this is that we want to mock graphql services to write isolated tests of particular microservices, and we want to mock out just the bits we actually use, and keep track of any changes in our schema usage over time.
I never found a solution to this, so eventually I wrote one!
https://github.com/xometry/graphql-code-generator-subset-plugin - this tool is a plugin to the graphql-code-generator tool which will product a schema subset.
Related
I am working with GraphQL (in Java) and I would like to find a way to do the following:
I need the possibility to constantly adapt the GraphQL schema at runtime without restart. In particular I need to be able to add new fields to GraphQL types. Moreover I need the possibility to be able to write resolvers which can handle this dynamic schema.
I do not have example code yet, so just think of the simplest example (one GraphQL type with several fields that can all be of different type).
My problem is that I am quite new in GraphQL and I do not have a lot of experience with it. Of course I looked for a solution on the internet, but I did not find one yet (or just did not notice that I found it due to my lacking experience with GraphQL).
The only interesting discovery I made is this: exposing dynamic schemas with graphql . But I do not understand how this solution works because 1) I do not know how to reload the schema at runtime and 2) I do not know how to write the resolvers so that they can handle that dynamic schema.
So can anybody help me with my problem and/or can answer my questions regarding the link I found?
I am very thankful for every help, no matter how extensive it is. Like I told before, I am quite new in GraphQL. Therefore I would be also very thankful for links to examples (if possible), so that I can understand better.
Thank you very much in advance.
#userongithub0 you may take a look at GraphQL Schema Directives
And specifically on the rest directive
First of all, don't ever try to do that or use only if there're some very strict situations. Here's why:
A schema is like a contract between the front-end & backend & on change, it can lead to instability between both of them very quickly.
If you try to change the schema of GraphQL, it might fail to connect properly with your resolvers & consecutively with your database as well.
Whenever there's is a change in the schema the GraphQL server (the server handler, in general) needs to be restarted (recompile) & it will take time, hence results in high response time.
No matter what language you are using, you should always see it as a red flag. In my opinion, it will be a really bad practice.
I'm not quite sure the wording I should be searching for on this.
I have a GraphQL schema which wraps a group of services using graphql-link-schema to perform the data resolution on the client side. The schema is intended to be built against a separate reference schema. How can I programmatically validate that my implementation matches the reference?
For bonus points- is it possible to determine whether a schema is a superset of another?
Thanks in advance (:
It's an interesting use case, but it's a bit unclear how validation like that would work. What causes validation to fail? Any differences between the two schemas? Extra types? Extra fields on existing types? Differences in return types? Differences in arguments or argument types?
Depending on your answer to the above questions, though, you may be able to cobble together your own validation function using the utility functions available here. Outside the main findBreakingChanges function, some of the utility functions available in that module:
findRemovedTypes
findTypesThatChangedKind
findFieldsThatChangedTypeOnObjectOrInterfaceTypes
findFieldsThatChangedTypeOnInputObjectTypes
findTypesRemovedFromUnions
findValuesRemovedFromEnums
findArgChanges
findInterfacesRemovedFromObjectTypes
If you have a reference or base schema available, though, rather than validating against it, you might also consider extending it when building the second schema. In doing so, you would effectively guarantee that the second schema matches the first except in whatever ways you intentionally deviate from it (by extending existing types, etc.). You could use extendSchema for relatively simply changes, or something like graphql-tool's mergeSchemas for more complicated changes.
I'm building a Graphene-Django based GraphQL API. One of my colleagues, who is building an Angular client that will use the API, has asked if there's a way to store frequently used queries somehow on the server-side so that he can just call them by name?
I have not yet encountered such functionality so am not sure if it's even possible.
FYI he is using the Apollo Client so maybe such "named" queries is strictly client-side? Here's a page he referred me to: http://dev.apollodata.com/angular2/cache-updates.html
Robert
Excellent question! I think the thing you are looking for is called "persisted queries." The GraphQL spec only outlines
A Type System for a schema
A formal language for queries
How to validate/execute a query against a schema
Beyond that, it is up to the implementation to make specific optimizations. There are a few ways to do persisted queries, and different ones may be more or less helpful for your project.
Storing Queries as a String
Queries can easily be stored as Strings, and the convention is to use *.gql files to do that. Many editors/IDEs will even have syntax highlighting for this. To consume them later, just URL Encode them, and you're all set! Since these strings are "known" you can whitelist the requests on the server if you choose.
const myQuery = `
{
user {
firstName
lastName
}
}
`
const query = `www.myserver.com/query=${urlEncode(myQuery)}`
Persisted Queries
For a more sophisticated approach, you can take queries that are extracted from your project (either from strings or using a build tool), pre-run them and put the result in a DB. This is what Facebook does. There are plenty of tools out there to help you with this, and the Awesome-GraphQL repo is a good place to start looking.
Resources
Check out this blog for more info on Persisted Queries
In connection/arrayconnection.js, It seems all the function is tend to work with array.
For example: offsetToCursor is the only way to generate Cursor. Does this mean its a design pattern i must follow, or imply that i should generate Cursor by myself when using something other than array.If im planning to use Mongodb,should i make the database interface like an static array ?
BTW:
As a newbie to web develop, im a bit confused how to implement a qualified relay server.
Are there some guide for design a graphql-relay server, should i follow all the way in graphql-relay-js, which Database Facebook used with relay-server ? mysql or ?
Im not sure ask this here is appropriate or not,but the topic for graphql-relay-js is rarely on the web.
Thanks a lot, forgive my impolite.
var PREFIX = 'arrayconnection:';
/**
* Creates the cursor string from an offset.
*/
export function offsetToCursor(offset: number): ConnectionCursor {
return base64(PREFIX + offset);
}
Additional question:
Maybe i get some idea from developers.facebook.com/docs/graph-api.
Seems should do an array style cache for pagination lookup( not sure about this).
But graph-api looks a bit different from graphql-relay-js (is graph-api still some part of old restful style?),
What is the relationship between graph-api and graphql-relay-js ? Is graphql-relay-js a common design guide for design a graphql server in facebook?
Thanks a lot! please give me some hints
Connection is a design pattern that your schema may implement if you want Relay to perform efficient pagination. How it gets implemented on the backend is an implementation detail. It may be backed by something array-like, or it may not (think about something like the infinite scrolling news feed on Facebook, which is ranked by a terribly sophisticated backend service: this is clearly not backed by an array). We provide the arrayconnection.js module as a way of demonstrating how this can be done if your data source has that array-like nature. If it does not, or cannot be efficiently converted to it, you are better off implementing something from scratch.
Cursors are opaque identifiers. You could use an array index or some kind of primary key if you are using an array source or a typical database backend (like MySQL), but again the details are implementation-specific and should be chosen to suit your back end. The only requirement is that the cursor should encode whatever information you need on the server to be able to return the next page of results after (or before) that point.
graphql-relay-js is just a collection of modules that provide some helpers for building Relay-compatible GraphQL schemas in JavaScript. The schema provides a uniform interface to your data, but the actual underlying storage can be anything you want to plug into it (a MySQL database, an object in memory, some REST service). For simple examples, look in the examples directory in the Relay repo. As an illustration of how you can put a schema in front of something that is not a traditional database, this is an example of a schema that reads its data out of a Git repo, with the help of indices in Redis and cached data in memcached.
Stay away from developers.facebook.com/docs/graph-api; despite the "graph" in the name this is an entirely different thing and has nothing to do with the GraphQL hierarchical query language that Relay uses.
I consider myself still pretty new to the TDD scene. But find that no matter which method I use (mock framework or stubbing my own objects) I find that I have to write a lot of code to create mock data. I like the idea of loading up objects to create an in-memory database. But what I don't like is cluttering up my tests with a ton of code for the sole purpose of creating mock data. This is especially the case when the data needs to account for all the different cases.
I'd love some suggestions for a better way of doing this.
It would seem to me that I should be able to load the data once into a known state from some data store and then I could use a snapshot of that state which is loaded in the test setup/initialize before each test method is executed. This would satisfy proper testing practices while providing convenience and let me focus on writing tests instead of writing code to create test data "by hand".
May be you could try the NBuilder library. It provides a very fluent interface and is easy to use. You can use it for generating single instances of a class with defualt values or generate lists with default or overriden values. You can have a look at this one.
If your are using .Net Try NDBUnit
You populate your store and then it reverts your DB to a known state at test time, for each test. The Autumn of Agile screen cast series shows this in pretty good detail.
Or you can do this manually...build a stored procedure or whatever to truncate your tables and copy in the data in your teardown method.
You can have Builder class(es) that helps you building the instances you need / in this case ones you would use related to the repository.
Have the Builder use appropiate defaults, and on your tests you can overwride what you need. This helps you avoid needing to put have every single case of "data" mixed up for all the different tests (which introduces problems, because usually there are cases that aren't compatible for different tests).
**Update 1:**Take a look at www.markhneedham.com/blog/2009/01/21/c-builder-pattern-still-useful-for-test-data
I know exactly what you mean. I think a good approach to solving this problem is to actually have a separate MockFramework project that houses all your mock data, outside the test project. This way you can generate mock data separately, store it in memory if you want to, or not, and then reference the mock framework from the test project. If you use a third party framework to do this, all the better, but you can still wrap that third party framework in your own mock framework so you can get all that "glue" that creates the mock data the way you need it out of your tests so the tests can really be only what they need to be.
Thanks for all the suggestions, I think the solution requires a little bit of everything. I don't want these tests to end up being regression tests, but w/o some kind of existing data store everything still boils down to creating the data by "manually" building the objects.
What would really be nice would be a framework that allowed me to use my existing DAL to either script the data to code for me or get the data in memory and access it like an in memory database.
Untils.org covers this way better than I ever could.
Their whole guide is actually very good.
But basically, if your units require "a lot of data" they may not be unit tests anymore. I'd recommend attempting testing the smaller pieces individually.