For lack of guidance for how this can be done (and there's none on internet), maybe it could explained why this isn't possible?
Related
Background:
I have a nodejs graphql server, and I want to learn Fastapi by reimplement the server with it.
It seems that graphene is the only option.
I learned graphql with Apollo,(and the server is built with apollo-server) and found all those "relay"-related features and conceptions confusing.
Connections, nodes, edges...
(I did some research and know the meanings of those concepts now)
From other SO questions like this, all(?) relay features can be implemented by other means.
But there is even a graphene.relay, so I doubted my conclusion.
question:
Is relay necessary to built a graphql server?
Just want to make sure it's not a dead end before spending too much time on it.
Relay specs are just a type of specification. It is not necessary to build a GraphQL server. However, if you are specifically referring to graphene-python, then I'd recommend using Relay as it already has complete support for Relay specs.
I have been trying to build a federation gateway on top of existing graphql services and am curious if there are any other implementations of the same apart from apollo federation?
I tried to find but couldn't find any. I am also looking for subscription on the federated gateway. Does anybody know any other implementations on the same?
It seems that fastify-gql now supports being a Federation Gateway, with subscription support included.
Yes:
Graphene (for python) with Graphene-Federation implements federation (there is in built support for graphql subscriptions). I have used this for a large-scale project and it works just fine (Although I personally prefer apollo)
I haven't personally used this, but tyk.io seems to have a pretty neat solution for federation: https://tyk.io/blog/an-introduction-to-graphql-federation/
Bramble - https://movio.co/blog/building-a-new-api-platform-for-movio/
Great for GoLang. I haven't used it, but I have a friend who has
Something else that is not pure "federation" per-se - but which would solve your problem easily is GraphQL Mesh. https://www.graphql-mesh.com/
Hope this helps :) !
I have recently started to learn graphql, which at the moment I find really convenient. However, when it comes to connect it with either an object-relational or object-oriented database management system, there is a bit of complexity based on the foundations of each DBMS. For that reason, I started looking for solutions that would make the process more efficient and I found prisma. I understand that prisma is doing all the heavy-lifting mapping my data to any database, however, I see that acts as an intermediate layer between my server and the database. So, my question is:
Does it really worth to use prisma in an application, and if so, how can I explain the overhead that is added by that intermediate layer(in terms of performance)?
I work at Prisma and would love to respond to this.
Prisma's biggest benefit when writing a GraphQL server is that it saves you huge amounts of CRUD boilerplate that you'd have to write in your resolvers otherwise. Paired with GraphQL Nexus, it let's you develop your GraphQL schema programmatically by building upon generated CRUD building blocks while also giving you a type-safe API to access your database.
how can I explain the overhead that is added by that intermediate layer(in terms of performance)?
When hosted alongside your application server, the Prisma server doesn't really add any performance penalties. Also note that we're currently rewriting the query engine that's running inside the Prisma server in Rust, this will make the Prisma server optional and you will be able to use Prisma as a simple library (similar to how you'd use TypeORM or Sequelize). The query engine then runs as a binary on the same host machine as your web server and connects to your database from there.
UPDATE: July 22, 2019: We've released a first version of Prisma 2. You can find all infos here.
I'd recommend you take a look at the GraphQL Nexus docs to learn more about the concrete workflows. Please let me know if you have any further questions, I'm happy to help :)
So I'm schema stitching with apollo-server-express which I believe makes use of graphql-tools and as per docs here: https://www.apollographql.com/docs/apollo-server/features/caching#adding-cache-hints-statically-in-your-schema
"Important note on compatibility: Setting cache hints is currently incompatible with the graphql-tools implementation of schema stitching, because cache hints are not appropriately communicated from one service to the other."
Similar thread: Apollo Server - Confusion about cache/datasource options
I currently have my code caching the response from the database in the same way the question proposes, but I could not fully understand the accepted answer and was unsure if said accepted answer was leaning towards client-side caching for that case.
So I'm at a loss as to how I could implement caching on Apollo. What other options are there?
We're exploring using GCE alongside out AWS deployment and I've a few questions coming from AWS.
It doesn't seem like the GCE Load Balancers support SSL (as in encrypting http traffic into https via the load balancer). I saw in the docs that its something that's coming .. does anyone know any good workarounds and possibly the timelines for actual support of this?
We use SQS on AWS a fair bit, and would like to use something simillar on GCE. There looks like there is Task Queues, but we've had a lot of trouble making them work in Ruby, for various issues, the docs seem somewhat lacking even trying to test them out in the builtin "try it out" tool. Does anyone have experience with having them work that could point us to a) a working ruby client library for it b) perhaps more complete docs (we have not even been able to issue a single authenticated request to them)
PubSub, we use SNS on AWS, and would like something simillar on GCE. Is PubSub the answer? It seems like its in invitation only beta right now? Any idea how we can get in and play with it?
Thank you.