search

apollographql / apollo-server

🌍  Spec-compliant and production ready JavaScript GraphQL server that lets you develop in a schema-first way. Built for Express, Connect, Hapi, Koa, and more.
https://www.apollographql.com/docs/apollo-server/
MIT License
13.8k stars 2.03k forks source link

Apollo Server 3.0 Roadmap #2360

Closed abernix closed 3 years ago

abernix commented 5 years ago

πŸ‘‹πŸ˜ƒ

This issue is to raise awareness into new developments and ideas for Apollo Server 3.x including any related, incremental steps which are worth addressing along the way. Some of this is likely to change, but we're very excited to start thinking about the next steps for Apollo Server, and I hope to share some of that excitement with you.

Since it was released last July, the number of Apollo Server 2.x installations have more than doubled so there are a lot of new learnings worth taking away from that growth. In Apollo Server 3.x, we want to continue to build on the feedback we've received from the community, and improve the project's extensibility through schema composition, federation and other pluggable plumbing.

While I realize there are likely many avenues worth exploring, I hope this issue can rally some constructive conversation which will help guide more specific designs. In time, several major bullet-points below will surface as new, dedicated issues (or develop within existing issues, where appropriate), but in terms of the high-level goals, here's what we're thinking:

On behalf of the Apollo team, I hope this provides some exciting and useful insight into what we're thinking as we move toward a 3.x. It's entirely possible that we're missing important items here, but we felt it was best to get the discussion planted. Feel free to comment with anything else you feel would be important for this release.

dylang commented 5 years ago

(Thanks for all of you hard work on this! If my items are not relevant I'm happy to remove/move to tickets for the appropriate repos.)

The Apollo Server option called context runs once per request, not once per graphql query. This means, with batching, all of the graphql calls in that batch share the same context object created by this function.

It would be helpful if the context option was run once per graphql query and not request.

dylang commented 5 years ago

Tracing today goes as deep as the resolvers. It would be helpful if Apollo Server provided user-level methods to provide tracing details even deeper, such as tracking the database and REST calls made in the resolvers.

Ideally, the OpenTracing patterns would be followed.

dylang commented 5 years ago

tracing is a boolean read when Apollo Server starts and it adds tracing data to every graphql response. I don't know of a built-in way to toggle this, or prevent the tracing data from being sent to the client without a custom graphql extension to strip it out.

It might helpful for performance to enable tracing for things like Apollo Engine, but not including the tracing data in the HTTP response.

It might be helpful if there's an override, like a http header, for those times developers require tracing information sent to the client, such as investigating performance issues using the GraphQL playground feature.

dylang commented 5 years ago

Apollo Server config options are found at https://www.apollographql.com/docs/apollo-server/v2/api/apollo-server.html.

Not all options are documented, and some that are documented could benefit from a deeper dive or links to other places where developers can learn more about the config options.

It would be beneficial for developers if we could have a goal for v3 to have all configuration documented or linked to other places where useful information can be found.

A stretch goal from this may be documenting best practices for things like performance, memory usage, and security.

Config options not currently documented on that page

Examples of config could benefit from deeper documentation

debug: <Boolean>

Enables and disables development mode helpers. Defaults to true

validationRules: <Object>

Schema validation rules

Note: The source code and TypeScript types are helpful to understand these, as well as the many open source projects, blog posts, and other parts of the documentation.

FluorescentHallucinogen commented 5 years ago

IMO, it would be a great idea to implement the previous roadmap before creating the new. 😜

I'm personally very interested in support of @live, @defer and @stream.

schickling commented 5 years ago

This looks great. Really looking forward to see this coming along!

It would be great to see how code-first frameworks such as nexus could work together with the idea of "modular GraphQL service development".

abernix commented 5 years ago

@dylang https://github.com/apollographql/apollo-server/issues/2360#issuecomment-467081178

The Apollo Server option called context runs once per request, not once per graphql query. This means, with batching, all of the graphql calls in that batch share the same context object created by this function. It would be helpful if the context option was run once per graphql query and not request.

In terms of breaking changes, this definitely seems like something worth considering for a major release. It's worth mentioning that this approach was initially by design on the premise that a performance win could be achieved through re-using dataloaders across multiple operations.

However, in practice we haven't seen it being recurrently problematic as batching is relatively underutilized, particularly one of the barriers to its adoption is that an entire batch is only as fast as its slowest operation. That said, I can't seem to recall this being opened in an issue so I'd highly encourage opening one to discuss what the implementation details might look like and how necessary important this might be.

There's some existing details on the matter in https://github.com/apollographql/apollo-server/pull/1468#issuecomment-409912878 where @martijnwalraven discussed some of the current patterns which need to be improved. Some have been improved in the new request pipeline (#1795), but others, including this context-per-request matter are still outstanding.

Anyhow, maybe get an issue opened for this? (Or help locate an existing one?)

jbaxleyiii commented 5 years ago

@FluorescentHallucinogen we definitely want to support those directives as part of this work. In fact, the 3.0 roadmap is inspired by our first spike on defer last year which helped us to find the gaps in execution and transport configuration that the 3.0 looks to solve 😸

abernix commented 5 years ago

@dylang https://github.com/apollographql/apollo-server/issues/2360#issuecomment-467138527

Config options not currently documented on that page

  • modules?: GraphQLSchemaModule[];
  • parseOptions?: GraphQLParseOptions;
  • plugins?: PluginDefinition[];
  • fieldResolver?: GraphQLFieldResolver<any, TContext>;
  • dataSources?: () => DataSources<TContext>;

These are great points, but I don't think we need to confine these to our roadmap. Some of the content for these options already exists and some of it is work in progress. It would be incredibly helpful if someone could open PRs to further define these (as noted, guided by the source code). Of particular note are also:

All great opportunities for contribution, pre 3.x!

abernix commented 5 years ago

@dylang https://github.com/apollographql/apollo-server/issues/2360#issuecomment-467129664

tracing is a boolean read when Apollo Server starts and it adds tracing data to every graphql response. I don't know of a built-in way to toggle this, or prevent the tracing data from being sent to the client without a custom graphql extension to strip it out.

It might helpful for performance to enable tracing for things like Apollo Engine, but not including the tracing data in the HTTP response.

By default, the tracing should only be included in the response if you've set tracing to true, not just when engine is true/enabled. Setting tracing to true is necessary for users who might still be using the Apollo Engine Proxy (which intercepts the tracing information from the extensions, transmits the metrics to Apollo Engine and strips these from the response). We now recommend using the built-in reporting in Apollo Server 2.x rather than this approach, which doesn't incur whatever penalty may exist from adding these to the response.

It might be helpful if there's an override, like a http header, for those times developers require tracing information sent to the client, such as investigating performance issues using the GraphQL playground feature.

Possibly! If you're suggesting programmatic enabling of tracing, I think that's worth considering but I don't think that needs be part of the v3 roadmap. I suspect this could be done via a plugin, and I think that once we move apollo-engine-reporting and apollo-tracing to use the new Plugin API (rather than graphql-extensions) it would be possible to even selectively enable that via an option or some sort of predicate function.

abernix commented 5 years ago

@FluorescentHallucinogen https://github.com/apollographql/apollo-server/issues/2360#issuecomment-467150030

Those features are still really important to us! The previous roadmap has them listed in the future section and they're still something we want to offer soon.

That said, we found bumps in the figurative "roads" that our last map guided us on, particularly when we went to start finalizing the work from #1287. That discovery made it clear that we needed to work on some of the issues we've identified above, particularly the work identified as Unify diverging request pipelines and Improve integration with existing frameworks.

abernix commented 5 years ago

@schickling https://github.com/apollographql/apollo-server/issues/2360#issuecomment-467168903

It would be great to see how code-first frameworks such as nexus could work together with the idea of "modular GraphQL service development".

Agree! My suspicion is that so long as nexus can generate SDL (it can), it should be able to participate as a GraphQL service within a federated graph. We'll have to explore this more as the details become more concrete.

arnabkd commented 5 years ago

I'm curious as to where Apollo is going in regards to schema first vs code first? See this blogpost by prisma: https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3

Ked57 commented 5 years ago

Hello guys, first I'd like to say you did an awesome work on the apollo-federation functionality. Still I ran into some problems and I believe many will, it's type and queries colision. We're trying to automaticaly stitch schemas from the generated SDL provided by prisma and some automaticaly generated types are begining to be a problem.

My point is, it would be awesome if the gateway referenced types with the name of the service first (ex service.type or service.query ) so we could ensure there's never going to be any type colision.

jlarmstrongiv commented 5 years ago

Improve integration with existing frameworks.

A GraphQL service can run in many environments and Apollo Server integrates with express, koa, AWS Lambda, Azure, and more. Several popular issues have shown us that we're taking an over-opinionated/under-configurable approach. We need to reconsider the applyMiddleware approach and use patterns that are more natural for particular environments. 2244, 1308, 1646, 1117

I had that exact problem, which led me to fork apollo-server-lambda to create my own apollo-server-agnostic.

While there’s more boilerplate code, having a version of ApolloServer that is not tied to any framework would give an escape hatch for code that is too tightly coupled or unsupported configurations. Just another possible solution to the problem Β―_(ツ)_/Β―

martijnwalraven commented 5 years ago

Hello guys, first I'd like to say you did an awesome work on the apollo-federation functionality. Still I ran into some problems and I believe many will, it's type and queries colision. We're trying to automaticaly stitch schemas from the generated SDL provided by prisma and some automaticaly generated types are begining to be a problem.

My point is, it would be awesome if the gateway referenced types with the name of the service first (ex service.type or service.query ) so we could ensure there's never going to be any type colision.

@Ked57 While namespacing types is definitely something we're interested in investigating, I don't think using service names for that is the right solution. One of the fundamental design principles of federation is that service boundaries shouldn't be visible to clients of a federated schema. The idea is that the federated schema acts as an interface layer that allows the distribution of types and fields over individual services to change without affecting clients.

dkolba commented 5 years ago

@abernix will 3.0 support Engine while running on CloudFlare Workers?

smolinari commented 5 years ago

Unify diverging request pipelines.

Could HTTP/2 possibly be a direction for this?

Scott

FerJSsilva commented 5 years ago

Do we have any estimates of when it will be released? Great features by the way!

Divya031091 commented 5 years ago

Hi,

I'm working on a project where in the idea is to use integrate Springboot(since a microservice architecture is followed) with GraphQL(since avoiding over fetching of data is key to the project)together. Using Apollo server / or and engine can provide more features such as performance tracing and caching for the Graphql server handling requests from graphql clients. My question here is that for a combination like Springboot+graphql can Apollo server be used which is mostly written for JS based HTTP servers such as express.

smolinari commented 5 years ago

@Divya031091 - I'd say, you are better off using GraphQL-java. It has batching (caching) and logging (from what I can read). It may not have performance tracing, but I'm fairly certain some rudimentary tracing built on your own through logging could get you a good bit ahead. Also, if you build out the performance tracing bit, you might be filling a hole in the Java/ GraphQL market. πŸ˜‰

Put another way, trying to wire-up an Apollo Server with Spring Boot would be harder than building your own performance tracing.

Scott

fernandobandeira commented 5 years ago

Unify diverging request pipelines.

Will that apply to federation (communication between gateway, services) too?

I think that we're missing some built-in fault tolerance features in federation, or at least an easy way to implement them, from my tests it does play well with service mesh but we could have something even more powerful here. The managed federation is a nice step towards that but still it's missing (Circuit Breaker, Bulkhead, Retry, Timeout, Fallback functionalities). I imagine that if we implement a service broker and communicate using message bus we could achieve something similar to https://moleculer.services we could also use the @defer / chunks features to send partial data back to the client if one of the services is down and send the rest of the data when that service is live again.

Currently the only way to achieve something like that is to use a service mesh with a sidecar proxy but the request will either have to wait till the service comes back up or it'll error and return an error response back to the client, it'll contain some data but it's up to the frontend developer to work around that and retry the request later to fetch the rest of the data, this process would be greatly simplified with some built in functionality like described above.

ForbesLindesay commented 5 years ago

It would be good to see subscription support in federation/gateway servers explicitly added to this roadmap. #2776 links to this issue and says it's on the roadmap, but I can't see it in the description of this issue.

shaneu commented 5 years ago

@fernandobandeira mentioned it but I'd like to echo here that we need some sort of retry/fault tolerance for Federation, it's critical for a production application.

tvvignesh commented 5 years ago

@abernix Very eagerly waiting for this. Noticed that apollo-client v3 RC is planned for end of this month (https://github.com/apollographql/apollo-client/blob/master/ROADMAP.md) - Will apollo-server v3 RC be also released in the same time frame? Currently using v2.x - Hoping that I can transition smoothly to 3.x

Love you all for the great work you guys have been doing with GraphQL and Apollo. Btw, very kicked about the Roadmap you have here: https://github.com/apollographql/apollo-server/blob/master/ROADMAP.md

abernix commented 5 years ago

@fernandobandeira (and cc @shaneu)

I think that we're missing some built-in fault tolerance features in federation, or at least an easy way to implement them, from my tests it does play well with service mesh but we could have something even more powerful here.

We also think it plays well with a service mesh right now, though you're correct that if downstream services are down, only partial results will be returned. Depending on how you look at it, this is a good thing. GraphQL does present a prime opportunity for these sorts of client-facing issues (partial failure) to be handled in a granular manner which only retries the failed part, but it does take additional consideration on the part of the client. I'm sure this experience will improve over time.

For now, having downstream services behind a load balancer with liveliness probes, and pointing the services at those service load balancers seems like a solution which provides even more resiliency for downstream services which might fail occasionally.

We also have a variety of life-cycle events to tie into within the Apollo Gateway, its data sources, and Apollo Server itself for setting up additional monitoring and alerting.

We're certainly looking to build upon this, but if you have something more concrete to explore, please open it as a separate issue. While it might not land in the initial 3.0, we are working on many parts at once and federation and gateway are currently iterating on their own.

abernix commented 5 years ago

@smolinari

Unify diverging request pipelines.

Could HTTP/2 possibly be a direction for this?

This bullet was merely meant to note the two separate request pipelines and the problems that creates for the project: One request pipeline is for subscriptions and one is for non-subscriptions.

The subscriptions pipeline doesn't "speak" federation, work with plugins or benefit from caching, while the main request pipeline does. We intend on rolling the two request pipelines into one. The proposal I opened for transports (https://github.com/apollographql/apollo-server/issues/3184) talks more about the possibilities here, though the idea is that the main request pipeline should be the sole pipeline, no matter the transport β€” e.g., for WebSockets, HTTP/1, HTTP/2, and even HTTP/3 β€” and the transport would be responsible for bridging the two.

Once that is all in place, I think better subscriptions support will fall into place more naturally. While it's unlikely that a new Subscriptions over WebSockets implementation will land in early versions of Apollo Server 3.0, but we haven't forgot about them (and I don't think they necessarily need to operate over WebSockets!).

Cc: @ForbesLindesay

abernix commented 5 years ago

@tvvignesh Apollo Server 3.x will not be released in the same timeframe as Apollo Client 3.x. While their version numbers are going to eventually be (again), the same, that is purely a coincidence; any transition between Apollo Server 2.x and 3.x will not be contingent on updating Apollo Client (or vice versa).

Regradless, I'm glad you're excited about the Apollo Server 3.x Roadmap. If you have any further thoughts about it, this is still the issue to discuss them!

Ked57 commented 5 years ago

I really feel like it is hard to debug federation, I've had trouble knowing why some of my requests are not succeeding to resolve. For example I've linked an user and a post service and while requesting posts I couldn't understand why it couldn't resolve the associated user.

I think developer experience is a big problem right now, the documentation is also very blurry and I can't seem to understand exactly the examples.

Another nice thing would be to have namespaces for each services, and to be able to delegate a service to a schema, right now annotations prevent us from doing that.

abernix commented 5 years ago

@Ked57 I certainly hope we can help improve any sub-par developer experiences you're experiencing. However, this thread should be kept to talking about specific things which are on the roadmap and not hand-waving about (multiple, different) bits which you find unsatisfactory. Rather than commenting on this roadmap, please open new issues with semi-concrete bug reports and/or feature requests, or at least start a conversation thread about it in spectrum.chat/apollo first. I hope you understand!

eyn commented 5 years ago

Moved to #3472

abernix commented 5 years ago

@eyn Interesting! Can you create a new feature issue for that for discussion purposes? 😺

mschipperheyn commented 5 years ago

We are still very dependent on schema stitching. Given that this is deprecated and we work with a variety of graphql servers that don't support Federation yet, will this remain supported in 3.0?

bionicles commented 5 years ago

I really don't like "addMiddleware" because all it does is add a layer of wrapping. Just make apollo-server-express a normal middleware for express. I don't need a function to add it, express has one

Also, the "SchemaDirectiveVisitor" class is annoying because it's so verbose ... why can't we just write little functions, I don't want to worry about this -- React went functional and so should Apollo Server ... directives are critical but so overcomplicated right now

I wish the schema was JSON or YAML so we could loop over it with code and generate resolvers / database automatically. The string formatting with backticks is silly because it doesn't give us more power, it's literally just there so noobs can have a normal SDL schema, but then power users can't programmatically access the schema? ugh

bionicles commented 5 years ago

Apollo Server would be much more useful if it had better docs, i think document -> test -> code (document driven development) would help a ton, because if it's not documented, it doesnt' exist

bionicles commented 5 years ago

finally, i wish there were a repo i could clone with a working apollo-server-express dockerfile so I could just extend that instead of having to open 50 damn chrome tabs and read random people's blogs for little pieces of the puzzle, we don't need prose / blogs, we need 1 great working containerized example

Santinell commented 5 years ago

I really don't like "addMiddleware" because all it does is add a layer of wrapping. Just make apollo-server-express a normal middleware for express. I don't need a function to add it, express has one

Also, the "SchemaDirectiveVisitor" class is annoying because it's so verbose ... why can't we just write little functions, I don't want to worry about this -- React went functional and so should Apollo Server ... directives are critical but so overcomplicated right now

I wish the schema was JSON or YAML so we could loop over it with code and generate resolvers / database automatically. The string formatting with backticks is silly because it doesn't give us more power, it's literally just there so noobs can have a normal SDL schema, but then power users can't programmatically access the schema? ugh

I agree about SchemaDirectiveVisitor and addMiddleware, but I think that schemas should stay in GraphQL format. To make schemas and resolvers management easier I think Apollo team should add method for loading *.gql and resolver files. Something like this:

apolloServer.loadSchemas('**/*.gql');
apolloServer.loadResolvers('**/*.resolver.js');
damianesteban commented 4 years ago

It would be good to see subscription support in federation/gateway servers explicitly added to this roadmap. #2776 links to this issue and says it's on the roadmap, but I can't see it in the description of this issue.

Yes, it would be. We really need Federation and Subscriptions to work well together.

gengjiawen commented 4 years ago

Any thought on dropping Node.js 6 and 8 support since they are EOL.

chaffeqa commented 4 years ago

FYI looks like graphql-tools just dropped 6.0 https://the-guild.dev/blog/graphql-tools-v6

borekb commented 4 years ago

@chaffeqa interesting! I didn't know about this "split", what does this mean for Apollo Server?

chaffeqa commented 4 years ago

Mainly the leveraging of new features... Since it looks like Apollo server is still on 4.0

darkbasic commented 4 years ago

I personally use yarn resolutions to force it on 5.0 (which is much more polished than 4.0)

EmilCataranciuc commented 4 years ago

Since Deno is out of beta, are there any plans to support it?

yaacovCR commented 4 years ago

@darkbasic and interested others, you should be able to upgrade to graphql-tools v6 without using the new @graphql-tools individual packages as everything is re-exported under graphql-tools.

Of course, to decrease bundle size, you may wish to use the @graphql-tools/schema, @graphql-tools/stitch, @graphql-tools/wrap packages.

Either way, see the migration guide as names of a few exported functions have changed with the tools/toolkit merger.

We should all be hopeful that compatibility between graphql-tools v6 and Apollo Server 2.x can be maintained, so please report any issues encounters with use of graphql-tools v6 and Apollo Server 2.x as they come up at https://github.com/ardatan/graphql-tools/issues.

For those unaware, you can take advantage of graphql-tools v6 with Apollo Server 2.x by building your schema directly with graphql-tools v6 using makeExecutableSchema and passing the built schema within the schema property to ApolloServer instead of passing in typeDefs and resolvers.

yaacovCR commented 4 years ago

@damianesteban note that although federation does not yet support subscriptions, schema stitching does now have initial support for type merging. I do think some healthy competition between the two methods is good for everybody. See https://www.graphql-tools.com/docs/schema-stitching#merging-types.

Important work ahead is to publish some recipes for using the custom executors/subscribers for batching/caching, which Federation has built in.

darkbasic commented 4 years ago

@yaacovCR unfortunately v6 is not 100% compatible with v4 like v5 used to be, so simply enforcing it to apollo-server with yarn resolutions isn't going to work anymore. I simply ended up using makeExecutableSchema/addResolversToSchema like I used to do with graphql-tools-fork and it works fine.

yaacovCR commented 4 years ago

@darkbasic I think that is the level of compatibility to which I was referring. If you have any issues passing the product of makeExecutableSchema/addResolversToSchema to Apollo Server, including type conflicts or what have you, please do open an issue at https://github.com/ardatan/graphql-tools/issues

Thanks!

smolinari commented 4 years ago

Is there any update on version 3.0's progress? I couldn't find anything. Or rather, will 2.0 and the supporting packages (i.e. express version) be upgraded to graphql v15? I haven't ran into any issues forcing v15, but I also haven't gotten to the depths of my needs for Apollo features (like subscriptions) yet either. Thing is, I am using another package that calls for GraphQL v15 and I'm getting (ugly) peer dependency warnings from apollo-express (and others from Apollo).

I'd just like to know where things are heading. :)

Thanks.

Scott

kaziwaseef commented 4 years ago

Is anyone working on Subscription Support in Federation for use in Apollo Gateway? I am working on writing some boilerplate code for Graphql based microservice using Apollo Gateway and Federation. Subscription support is very necessary for this. I would also like to avoid over engineering a workaround and I also believe this should be a part of the core system of Apollo Server.

I have read the issues and a few comments here but I couldn't find any clear information. I would like to work on this feature as well if it is something I can contribute towards, but I guess I need more information about the current work/thoughts about this.

Cheers :)

PS. I have also written the same thing in the spectrum community: https://spectrum.chat/apollo/apollo-federation/subscription-support-for-federation~51080d2c-2669-46a7-a8fe-060d9243a511