Apollo-server: Apollo Server 3.0 Roadmap

[abernix]

👋😃

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:

• _Plug_-ability and extensibility.

  Apollo Server aims to provide sensible and opinionated defaults, while allowing customization and integrations. Some existing functionality could be abstracted out and live on as plugins, letting those who want a more vanilla approach to have it. Evolving the experimental plugin API, which surfaced in Apollo Server 2.2, should encourage those patterns and help build a vibrant plugin ecosystem that caters to specific needs — e.g. logging, metric reporting, authentication, error handling, etc. Most of this is possible with the existing plugin API, but we anticipate the implementation of some new integration hooks. 2008, 1795

• Introduce patterns for modular GraphQL service development.

  GraphQL services combine schema construction and its request processing into a single unit, decoupled from the framework and compatible with tooling. They can be moved to different environments (e.g. between development and production) and tested without a complete server. These are new concepts, so we suspect we might see these in experimental phases prior to 3.x.

• 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

• Be lean and courteous to non-Node.js environments.

  It should be possible to configure Apollo Server in a way that it can execute in "no-frills" JavaScript engines which offer different functionality than the complete Node.js runtime. Examples of such runtimes are "worker" deployments (i.e. Cloudflare Workers, Fly Edge Apps, etc.) which run on "bare" V8 or other JavaScript engines. Some progress has been made on this already, but we could do more. We should prefer native Node.js APIs when they're available, but that luxury should be abstracted away in a manner which can be polyfilled with alternative implementations or have its functionality limited gracefully when unavailable. 2162 1572

• Unify diverging request pipelines.

  Apollo Server supports WebSockets out of the box. However, its execution is disconnected from the main request pipeline. This divergence means operations over WebSockets won't benefit from the parsed/validated document cache, Apollo Platform support, plugin life-cycle hooks, etc. While HTTP makes sense for many cases, Apollo Server should be able to "speak GraphQL" easily over other transports and by unifying the two current request pipelines, we hope to make the main request pipeline more flexible.

• Federation support.
  Within one graph, which composes multiple GraphQL services together and provides a single entry-point, individual GraphQL services are served by Apollo Server instances which support their portion of the graph. For GraphQL services, the plugin API should provide the integration points which allow the appropriate changes to a schema and allow them to participate in a federated architecture. These same hooks should prove to be useful hooks for additional plugin functionality which relates to schema building and transformation.

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]

_(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]

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]

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]

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

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

Examples of config could benefit from deeper documentation

debug: <Boolean>

Enables and disables development mode helpers. Defaults to true

• What are the _development mode helpers_ and how do we use them to help us?
• Would it be a security or performance risk to enable this in production?
• Is it possible to enable this in production to investigate an issue?

validationRules: <Object>

Schema validation rules

• <Object> is not enough information here for somebody to make their own rules.
• What should we use this for?
• What happens if the rules are broken?

_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]

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]

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]

@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]

@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]

@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:

• The docs for data sources
• The in-progress docs for plugins
• parseOptions is relatively a straightforward pass-through.
• modules are somewhat experimental, mostly undocumented because we're still getting feedback, but all around could certainly be noted as such.

All great opportunities for contribution, pre 3.x!

[abernix]

@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]

@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]

@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]

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]

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]

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]

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]

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

[smolinari]

Unify diverging request pipelines.

Could HTTP/2 possibly be a direction for this?

Scott

[FerJSsilva]

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

[Divya031091]

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]

@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]

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]

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]

@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]

@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]

@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]

@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]

@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]

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]

@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]

Moved to #3472

[abernix]

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

[mschipperheyn]

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]

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]

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]

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]

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]

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]

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

[chaffeqa]

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

[borekb]

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

[chaffeqa]

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

[darkbasic]

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

[TheFuriousSnail]

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

[yaacovCR]

@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]

@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]

@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]

@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]

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]

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

[smolinari]

@kaziwaseef - For sure subscriptions were planned to be added to federation in 3.0.

@abernix - Hope you can chime in here please? Or who is the project manager for Apollo now? Is it still @peggyrayzis? Would be great if you could collab with @kaziwaseef and possibly speed things up. :)

Scott

[gad0lin]

Is there a branch at which it would be possible to see the progress or it's inhouse?

In context of subscriptions I was looking for progress of packages/apollo-server-testing but couple branches I checked with 3.0.0 didn't have any updates.

[pvtpogopuschel]

It looks like there is quite some demand on getting subscriptions supported in Apollo Federation.

I am a bit worried that - albeit different sources claim it's planned for Apollo Server 3.0 - no related tickets seem to be in the milestone nor any branch seems to exist that reflects some ongoing work.

Am I missing something here? I think many would appreciate if the Apollo team helps shed a bit of light on this question?

[smolinari]

@pvtpogopuschel - I found this issue: https://github.com/apollographql/apollo-server/issues/2776#issuecomment-503361983

Interesting to note is the last comment about schema stiching in GraphQL-Tools supports subscriptions.

Scott

[pvtpogopuschel]

Hey @smolinari!

Thanks for pointing out that thread! I've read about using schema stitching on top of Federation as well. We've considered doing that as a "temporary" workaround, but it would considerably increase the complexity of our app and it feels a lot like having two somewhat competing concepts running next to each other.

The original Federation announcement blog post talked about adding functionality such as subscriptions and @defer as a next step. While I would never demand a specific timeline, I would like to get some insights on whether it's going to be part of Apollo Server 3. If that's not the case, we will probably indeed go for schema stitching.

[smolinari]

I'll be honest. I've not even used either (yet). I thought schema stitching is a replacement or alternative method to Federation.

Scott

[HectorMF]

I'm in the same boat. I chose to use federation last year because of its simplicity and the stated plan for subscription support in the future. The workarounds to get subscriptions working are clunky, tedious, and temporary; Subscription support for federation will be a godsend. Like @pvtpogopuschel, @kaziwaseef, and many others, I would greatly appreciate a quick comment by the Apollo team if this is planned for 3.0.

There are also several people (me included) interested in contributing in some way, but without knowing the status of the current implementation we have no real path forward. Perhaps consider opening up this development to the community!

[andre-meyer]

Like other people in this thread, we have the same issue on our team and would extremely happy if we could somehow get subscription support for federation in Apollo Server.

It would seriously be a game changer for our project. I've been checking a lot recently in the roadmaps and news updates from the apollo team, but there were no bigger mentions of this, so I'd be interested to know what the plans are right now?

[mikedmcfarland]

The schema stitching layer in the alternative solution for federated subscriptions seems like it'd be pretty
hard to build (tantamount to building your own federated gateway in some ways).
For example, lets say you had two federated services:

comment service:

extend type Post @key(fields:"id") {
  id:ID!
}

type Comment {
  post:Post
  message:String!
}


type Subscription {
  commentAdded:Comment
}

post service:

type Post @key(fields:"id") {
  id:ID!
  content:String
  author:String
}

type Query {
  postsByAuthor(email:String):[Posts]
}

How would you stitch the Posts type onto the Comment type for the subscription?
Would your layer actually call _entities?
Ok lets say you do, does that mean its parsing the SDLS of these federated services and developing query plans similar to the gateway?
Do we respond to changes downstream (via polling) or via the graph manager on demand and build new plans?.
I'm not sure I understand how stitching is an alternative solution to federated subscriptions, am I missing something?

[khaledosman]

Are there any plans for http2 support in apollo-server? I think this would be a great addition

[tvvignesh]

While http/2 support may not be right for this time for given that http/3 has been released and picking up as an official standard (https://blog.cloudflare.com/http3-the-past-present-and-future/) and it also landed in the Node.js core (https://github.com/nodejs/node/issues/23064#issuecomment-646339255) this would be a very important thing to be supported.

I haven't tried it yet (about to) but this would be great to give the great boost in performance for users and reduce the latency for users.

[saul-gush]

Federation needs to be more graceful with the underlying graphql services. If you deploy changes to the federation server and if one of your underlying services is down or there is a mistake, the entire federation server results in a 500 internal error.

The error should be isolated to that underlying/remote schema and keep the rest of the gateway should continue to work fine.

There should also be an easier way to refresh an underlying graphql service. Like a reload api or something to refresh one service at a time, avoiding entire restarts and single points of failure.

[maclockard]

It would still be a good idea to add http2 support since it will take a while for broad adoption of http3. I mean http2 was released in like 2015, but it still doesn't have complete coverage/support. It may take years for http3 to reach similar levels of adoption and use. Adding http2 support now would make a big difference during that (possibly) many year transition period.

[yaacovCR]

@mikedmcfarland see https://www.graphql-tools.com/docs/schema-stitching#merging-types

The basic difference between type merging with stitching and federation is where keys are specified.

Federation believes it's easier to have them be specified within the subschemas. Stitching makes no presumptions over your control over the subschemas and so keys are specified on gateway.

So yes, schema stitching sets up a gateway schema, as always. You can add type merging resolvers that use the entities field to access types.

You could replace the federation gateway entirely using declarative syntax within js config object, but you don't have to.

Schema stitching with type merging differs from original in that now declarative with no extra id fields to be filtered, whilst preserving ability to customize with more complicated imperative style merging.

Output is a regular GraphQLSchema object -- polling for changes to underlying subschemas is not currently included by default (as this belongs in a server layer) but any custom solutions created for original schema stitching should still work.

Should be possible as well to add tooling that reads federation directives and adds the required syntax on gateway automatically.

Not sure about adding interaction with Apollo Studio/Graph Manager, but depending on API may be possible as well?

[yaacovCR]

Also with schema stitching with type merging, key fields can be different for each subschema. No concept of any subschema "owning" any fields.

[ankit-joinwal]

Feature Request - CircuitBreaker pattern in Apollo Gateway

Currently, the Apollo Gateway constructor allows defining options like timeout and retry on requests sent to backend service. Is there a way to configure circuit breaker for each backend service ? Or is this feature in roadmap?

The reason i am looking for this feature is to avoid Apollo Gateway become a single point of failure because of high latency from downstream service or downstream service failure. In case of a particular downstream service becoming unresponsive, the threads of Apollo Gateway would be blocked till the configured request-timeout duration. Thus impacting the availability and latency of entire data graph.

[martdavidson]

Can't stress enough how much simpler our codebase would become with subscriptions support! Thank you for all the work that is being done, and would greatly appreciate an update to the status of supporting subscriptions.

[cupofjoakim]

@abernix With #4039 being needed for the current LTS of node, how far away do you think V3 is? A lot of us are blocked from upgrading atm, personally I'd love to see the fix backported to 2.x

[danechitoaie]

Same here was looking forward in using Fastify but got into some errors and noticed that they were fixed for v3 so for now I have to fallback to express.

[tvvignesh]

I have moved to using fastify and graphql-helix now after seeing this: https://github.com/benawad/node-graphql-benchmarks

You might want to take a look at the performance/latency in v3 and enabling the addons only when they are needed.

[KeithGillette]

In implementing Subscriptions in our apollo-server-express project, I have not found a good pattern for validating and authorizing GraphQL Subscription requests given the current Apollo Server Subscriptions API. As indicated in the Idea Discussion I opened on the topic, I think the best way would be to align the Subscription Resolvers with Query and Mutation Resolvers in allowing a Promise return type, which could be rejected if validation or authorization fail, canceling the client Subscription request.

[yaacovCR]

@mikedmcfarland https://github.com/gmac/schema-stitching-handbook

[mikedmcfarland]

@yaacovCR appreciate the resource, looks well put together, thanks.
This is not a criticism of your work, I think its great... but...
I was less asking about how we might actually stitch onto subscriptions (I have done some stitching before), and was more trying to illustrate that federation works fundamentally different. It doesn't expose queries to the public that expose by a set of ids, or an id, and supports relating things based on potentially different keys that the other services can decide to utilize. It provides a means to build a schema and gateway solution from many smaller schemas, and a whole nice suite of tools around query plans, etc...
My main point was, stitching isn't a replacement, and to achieve a similar set of results and workflows would be a significant amount of work.

[yaacovCR]

@mikedmcfarland

It doesn't expose queries to the public that expose by a set of ids, or an id,

Take a look at new type merging patterns, this is no longer required. Any _entities like helpers can be stripped from stitchedSchema as desired by calling our filterSchema method on the stitched product which is how some production users manage creating different schema "views", but can also be used to hide any _entities like helpers.

and supports relating things based on potentially different keys that the other services can decide to utilize.

That is exactly what the new stitching with type merging does, with more flexible key patterns as each subschema can declare the key it needs independently.

It provides a means to build a schema and gateway solution from many smaller schemas,

We provide a gateway schema that you can use with GraphQL Helix, Express GraphQL, and with Apollo. When used with Apollo, you can use the Apollo toolset to some extent to get those benefits.

and a whole nice suite of tools around query plans, etc...

Ahah! We don't give you a query plan yet. Down the road is a set of helper tools that allow you to see what's happening under the hood. The nice thing about @gmac handbook is that he walks you through that so you can have confidence in the algorithm.

My main point was, stitching isn't a replacement, and to achieve a similar set of results and workflows would be a significant amount of work.

Stitching is a replacement of the backend merging algorithm that works better than Federation, solving problems with type ownership, interfaces, batching, that Apollo has deferred until Constellation -- which I am excited to see!

The main disadvantage to stitching right now that is that tooling to visually inspect how the schemas/queries get merged has not yet gotten there, and that you have to roll your own checks if you are trying to ensure a certain level of the merged graph consistency, although of note is that the consistency of the merged graph does not guarantee or replace an actual query test suite, and that bugs might be just as easily picked up there.

Anyways, this is all in the spirit of healthy competition. it makes sense that an enterprise solution by Apollo would have better tooling and that an open source solution such as stitching have better underlying nuts and bolts. I'm hoping that with the new constellation thar Apollo is coming out with, it might be possible to use Apollo studio to introspect a schema merged with schema stitching, but I imagine the query planner part of it at least would be unreliable.

For an accurate comparison of the new stitching and current federation, also see https://product.voxmedia.com/2020/11/2/21494865/to-federate-or-stitch-a-graphql-gateway-revisited

[yaacovCR]

I can't underscore enough that you can host a stitched schema with Apollo server 2 and 3 when it comes out, because it is a regular GraphQL JS Schema object. You can use Apollo enterprise products with it as well, including tracing, introspection, etc.

[gmac]

@mikedmcfarland since I got pinged into this conversation... I’ll just add that you need to be mindful of timeframe with stitching history. The tool is completely different now than it was in, say, May. In the past six months it’s gone from something of a relic to an extremely comparable alternative to federation... albeit, structured more like a library that one can use to build their own version of federation. Fed also has a generous head start on docs and product wrappers.

[glen-84]

@abernix,

This issue is now nearly 22 months old – has there been any progress towards Apollo Server 3.0?

I am in the process of selecting a stack, and I wanted to use Apollo Server, but I'm concerned about the apparent lack of activity (outside of dependency and documentation updates).

There is no project, no completed items in the Release 3.x milestone, and a long list of seemingly old branches.

Dependencies like graphql-upload are outdated, and others like graphql-subscriptions haven't seen a release in over 20 months.

Is this situation likely to change any time soon, or is Apollo Server no longer a smart choice?

I realize that this is open source software, and I'm not making any demands, I'm just trying to determine the status of this project, so that I can make an informed decision. I hope you understand.

[kodeine]

@glen-84 i'm in the same boat as you and others.

[Sytten]

@glen-84 @kodeine We have been trying to get a real and clear response from Apollo many times on that without any success. This is a similar pattern than what we have seen with meteor, but this time I decided to do something about it. I am building https://www.graphmetrics.io as a replacement for apollo studio that will work for all graphql servers and I will switch the servers of the clients I support away from apollo server in the coming months.

[Sytten]

I really do not wish to hijack the thread away from the apollo server roadmap, so let's continue this in private. Please contact me at emile [@] graphmetrics.io @kodeine.

[sgentile]

We are using subscriptions and also looking at federation, this is a hot topic for us - hope this can be added soon

[gmac]

@sgentile - have a look at the new schema stitching, which was overhauled last year. It’s now pretty comparable to Federation, and does subscriptions today. Also already does most of what they’re building in the nextgen Fed update, albeit with some static javascript config versus the federation goal of making everything declarative via SDL.

[jacob-israel-turner]

@abernix the community needs an update here. It's important to communicate timeline, even if the timeline is still extended out in the future a ways.

[skk2142]

I love the work that apollo has done on graphql but the silence from the team towards the github issues and this roadmap is very concerning. I have already moved from apollo client to relay and now I'm questioning if I should still use apollo federation or use schema stitching suggested by @gmac. Please provide an update on the roadmap timeline.

[glen-84]

@abernix, @trevor-scheer, @peggyrayzis,

With over 40 up-votes to my comment above, it's very clear that I'm not the only one concerned about the future of Apollo Server.

I really don't understand what is happening here. Is it a lack of resources, finance, or expertise? Is all your time being spent on supporting paying customers? Are there any plans to expand the development team?

Why does it take 3 weeks or more to merge a single word spelling correction?

graphql-subscriptions – No response to an offer to maintain the package.
subscriptions-transport-ws – Another offer to take over maintenance.

I would like to make the following suggestions:

• Split the integration packages (apollo-server-express/fastify/hapi/koa/lambda/micro/etc.) into separate repositories, and let them be maintained by the community. Concentrate on the core, and providing stable interfaces.
  
  
  
  • I understand that this is in the v3 roadmap, but developers can't wait 5 years for this, they need something to work with now.
  
  
• If funding is an issue, consider allowing users to sponsor the project. That income could be used to hire a full-time developer.
• Spend half a day each week doing things like merging trivial PRs (spelling corrections, type definition fixes, etc.), and cleaning up stale branches. This is a basic level of maintenance, and will make it easier to identify more important work.
• Provide a simple monthly iteration plan (similar to VS Code and TypeScript), to outline planned work and communicate current areas of focus.

I really hope that the situation improves.

[kodeine]

@glen-84 i think its time to figure out the alternatives. If its going to take years to get a feature or a fix then this package is not the right choice.

[Sytten]

@glen-84 Apollo server is clearly not a priority anymore, their focus seems to be on federation since this is a product they can sell support contracts. IMO we are in the classic case of a company that tried to do too much and lost focus.
At this point the community should stop asking for news and either fork the server or invest in alternatives. There are a few interesting ones that maybe don't have the marketing power of apollo but have potential.
On top of my head:

• https://github.com/contrawork/graphql-helix
• https://github.com/graphql/express-graphql
• https://github.com/mercurius-js/mercurius

[kodeine]

@Sytten thank you for providing other packages. In leaning towards mercurius since it supports federation meta data less changes need to be made in the app.

[vladshcherbin]

Folks, just move to using other packages and don't start new projects with Apollo Server, simple as that. You won't get any response no matter how you ask.

Same thing happened before with Meteor project from the same team. Deep silence until news with headings "Meteor is dead" and similar started to show up everywhere. Same story happens again, which is not surprising if you've used Meteor or read articles about it a few years ago 🙈

The good news is that there are other great packages to use. Apollo Server was a pioneer and an awesome first step in graphql world for many of us.

It's time to move on. ✌️

[vladshcherbin]

Here is a nice benchmark with different graphql node servers with examples - node-graphql-benchmarks. Select a maintained package and use it instead.

[sgentile]

Let me understand this better, Apollo server federation works, the sticky point is subscriptions ?

[gmac]

@sgentile the present version of Federation does not support subscriptions. It's on their roadmap in the constellation project, per https://www.youtube.com/watch?v=MvHzOwdLb_o. An alternative is to use a stitched gateway with federation services, or just stitch... the two systems now have similar SDL annotations so it's fairly easy to switch around between them.

[skk2142]

@gmac thanks for writing the handbook. Does stitching gateway with annotation provide compile time validation like apollo federation?

[sgentile]

Is another alternative to just use something like socketio to handle subscription - and not try to do both ? Weighing pros and cons, having a separate socketio/redis setup might be better for multiple reasons - where you get the benefits for federation and not trying to combine with subscriptions

[gmac]

@skk2142 – basic stuff right now, but the large validation suite is landing in https://github.com/ardatan/graphql-tools/pull/2486 (very close to release). You'll be able to set your error tolerance by validation and scope... it can be deliberately permissive of allowing safe divergences like nullability differences (ie: a nullable gateway field can safely proxy a non-null read-only subservice field, and the reverse with input fields). Another notable allowance is for partial interfaces, so an interface of fields may be spread across services (see https://www.youtube.com/watch?v=wPB5oI_Tjik).

[smolinari]

I'm at the juncture where I need to feel confident in the GraphQL server I'm implementing and I'm not at all feeling confident with Apollo Server. I'm starting to look around too. It's so sad and disappointing. Like someone said above, Apollo did some great pioneer work, but that has been lost to what seems to be neglect

I'm not certain what the thinking is with the Apollo team, but certain decisions in some areas and non-action in others like here with the server show missing overall leadership. I miss the days with @stubailo, where he obviously had the trajectory and development of Apollo well under control and garnered the initial fun and excitement that used to be Apollo. All that is missing now... unfortunately. I'd love to see it back.

As someone else also noted above, all this seems to be a string of mismanagement. Unfortunately, it is human nature to fill in gaps of information, when there isn't any. All this might be due to the fight for funding with OSS and to support it properly with paid dev resources. It's definitely an issue of dedication. And needing funding is just an excuse. Delegation of the integration packages as a solution, as was also noted above, is also a choice to "lighten the load" and have the server still be flown under the Apollo flag.

I don't know for sure, but the overall inactivity and neglect looks like indifference or inability to act (again, trying to fill in the gaps of missing information). It all raises zero confidence in me, and I'm sure others, that there is anything good happening in the near to mid-term future with Apollo Server.

If this isn't true, someone from the Apollo team please show the courtesy to reply here and instill some hope in me (all of us) again. Thanks!

Scott

[abernix]

👋 I hear you.

I recognize this is a long reply, but long periods of silence probably deserve some verbosity. I hope to offer some clarity as to where we have been and where we are now, but I want to begin by acknowledging the frustration that the silence could cause. While the adoption of Apollo Server continues to be strong, I understand how not seeing more active communication on this Roadmap and active collaboration and development on the repository would call some to question the level of our commitment and give additional pause when considering adoption today. I want to rectify that. I appreciate all those who have voiced their concerns and framed their thoughts eloquently.

Apollo Server is important to us, and we know it’s important to many of you. We run our own Apollo Studio and registry infrastructure through the same version that’s published here and it’s the foundation of Apollo Gateway which we also run. And while Apollo — the company — is merely where I work, I work here because I enjoy building software for developers (read: singular, teams, and organizations) and I believe in the problems we’re trying to solve and the tools that we’re building to facilitate data graph development; I’m personally proud of the contributions I’ve made to Apollo Server and the successes it’s had. I’m saddened that some of you have become disheartened, but we are committed to getting it on track and this is something I’m working with a growing organization (we’re not huge, we are hiring) to improve. It will take additional time to get it right!

Feel free to skip this and the next two paragraphs if you’re not interested in any explanation but — as some transparency, I thought I could offer perspective: In 2019, with help from a very small team, we took steps to move the Apollo Server project in a direction where we could plan where we wanted it to be, provide clarity to the community (_Hello, Roadmap_), understand how to further our sustainability, bring new functionality and fix bugs. And, ambitiously — as you’ll note in the original plan above — provide “Federation support”. We intended on delivering on the totality of our Roadmap, but the single “Federation support” bullet-point alone was a heavy lift.

When we first announced Federation in May 2019, it was a shared concern of those who had previously thought about Apollo Server. I don’t believe those resources were at any point in 2019 or 2020 more than four people, but I’m proud of what my peers and I accomplished during that time. However, the act of launching, validating, debugging and learning from what proved to be successful uptick in the adoption of the Federated model took up limited resources. I was essentially the sole resource on the core of Apollo Server and, while it did and does (still!) work great for a majority of use cases, we acknowledged that we weren’t giving it the necessary attention. Internally, we also had shared frustrations that we couldn’t put more resources on Apollo Server. The scrupulous probably observed the idleness earlier, but our resources aren’t unlimited, time was scarce to update this Roadmap, and we’re trying to remain sustainable amongst ourselves.

As we rounded out 2019 and headed into 2020, we were optimistic in our planning processes that we’d be able to scale in various ways and “pay it down”: we knew what we needed to improve on and we had job openings on our Careers board to fulfill those needs. I myself transitioned from an individual contributor to the role of Engineering Manager in May of last year in preparation for more ambitious growth of our efforts and the adoption of new team members. Intended to be temporary, this left Apollo Server with no contributors other than my own occasional attention to fix a handful of critical fixes. Needless to say, 2020 had plenty of obstacles (waves hands dramatically at all the things), we slowed down, and we made less ambitious progress on scaling our efforts on Apollo Server than we hoped for.

We are committed to Apollo Server. Since the growing efforts of Federation took time away from Apollo Server initially, an important requisite has been to bring in resources for Federation. Additionally, since Federation helps larger teams collaborate on disparate but still _relatable_ components while exposing a single data-graph to their consumers, this is a requirement for many would-be adopters and helps increase GraphQL adoption more broadly. If you’re concerned about picking a GraphQL server and knowing that it is backed by commitment, I would agree with you and also say that I think Apollo can offer you that but — unless we all feel quite confident that GraphQL just _isn’t_ going away anytime soon — it’s important for it to continue to gain adoption by even more teams of all sizes.

As of the end of 2020, Apollo Federation moved in its own repository to facilitate it growing as it’s own product and in just the last months, we’ve formed a larger, more focused team around it. We’ll grow that team further as soon as conceivable. Additionally, Federation is now no longer just a concern of “the team that formerly worked on Server”, but we’re now seeing federation support appear in other parts of our growing platform, including work like the ability to view query plans in Apollo Studio Explorer. While _Server_ today remains largely under the same limited resources that have persisted for most of last year, we are committed to changing that and, as I noted above, I’m working with others to improve this.

While not substantial, we were able to make _some_ progress. For the 2.0 line, we still shipped a fair number of releases (including important updates) and we increased our commitment to the new plugins API by bringing them missing functionality (like willResolveField) and converting our use of the (now-legacy!) extensions API to use the new plugins interface, allowing us to provide a well-documented interface into the future. Many users now utilize this API to provide implementation-specific functionality to their graphs and we’re happy to see that adoption.

For Apollo Server 3.0, I have been slowly iterating on a release-3.0 branch in my spare time and some headway has been made. In fact, while it’s an early alpha (and now several months out of date), some emoji applause seems to have been had by users of a 3.0 prerelease version published some months back to facilitate a particularly necessary Fastify integration update. I recognize that most of what has happened here (and you can see in the above link) has been dependency updates and deprecations, but I think that’s still valuable progress. I will be working with team to move this forward.

For those concerned about committing but also making comparisons to Meteor and drawing conclusions about similar fearful fate, I can see how you might try to relate these, but I would also point out that: If you’re truly considering the commitment to a tool’s success — the team behind the original Meteor (myself being one of the participants) took great care to make sure that our change of focus wasn’t the end for Meteor. I think we found excellent new hosts for it where it continues to live on today.

We are trying to offer sustainable open-source software stewardship that can go on to be trusted, relied upon and maintained well into the future. I recognize we can do better, and I hope we can be more transparent while we do it. While we haven’t had as much in the way of resources to to dedicate to every aspect of our open-source offerings in the last year, I see the opportunity for improvement on the horizon, and I hope you find some faith in this update. I’ll work to deliver tangible progress (or hopefully, you’ll find others surfacing to deliver tangible progress) but I hope you’ll bear with us while that gets figured out.

[glasser]

Hi! I'm David, and I've been working at Apollo (and before that, Meteor) for a long time. There was a day when the majority of my job was keeping up with and encouraging community contributions to Meteor. For the past few years I've mostly focused on building out the backend of Studio, and I've really missed out on being deeply involved in the open source side of our platform on a daily basis. I'm excited to say that I'm on @abernix's team now, and while our team is working on a number of parts of our platform, the majority of my personal contributions are going to go towards maintaining and improving Apollo Server. There are parts of this project (eg, the plugin system) that I already know deeply, and other parts I'm looking forward to finally learning about. I'm already starting to spend more of my time on helping out with new issues and PRs, and intend to take on getting AS 3 out the door sooner rather than later.

As Jesse suggests, just getting one person more focused on this project isn't enough, and I'm hoping to find a solid full-time partner for this work (he mentioned we're hiring!). It's worth noting that many of the goals of AS3 specifically are around making the project more maintainable and well-scoped — for example, reducing some of the complexity that comes from built-in integrations with other GraphQL libraries that could be replaced by more generic hooks and better documentation, and allowing us to make a few small backwards-incompatible changes and target newer versions of Node.

This doesn't mean that I'm going to manage to go through every open PR and issue immediately. And be warned — I am going to post "please provide a full reproduction starting with git clone and I'll reopen the issue" a lot :) But I hope those of you who are watching the repo have already noticed a bit of a change this week, and I'm excited for what we can do together to keep Apollo Server strong in 2021.

[smolinari]

Thanks for the replies @abernix Jesse and @glasser David. I'll be so bold to reply myself, since I (also being presumptuous) think my post got the emotions going to motivate your replies.

I can't speak for everyone, and I never try to, so I'd like to say, I'm a bit less worried now. Thank you. But, only a bit. I'm sure this is a shared feeling though too.

My plans will be to continue to lurk the repo to watch the work being done and progress made, announcements said and if any are made.... promises kept (or at least clear effort to keep them). At the same time, I'll be doing the same over the next couple/ few months with one or two projects that look competitively promising.

The only other suggestion I'd like to make is to get back to a public plan of action (the road map). There doesn't need to be exact release dates, but there should be some semblance of timing and commitment on milestones, like in quarters, maybe? I think this was missing originally too to this post/ the project. I realize with a small team/ few resources, it's hard to make commitments, but I say, at least try, please. I know from other projects, it's not always making commitments perfectly that count, but showing the effort is made to try and make them happen. This is, after all, OSS. 👍

I'd also like to point out, and I think the discussion could get back to those topics, what I feel are important and needed developments of Apollo Server.

These features are (and not in any order of importance):

1. Federation. But, also with working subscriptions. I'll be honest, this feature is not seriously important to me currently, but in the future it will be. Put it this way, as you noted Jesse, it's the tool for large collaborative code bases. It's a development scaling mechanism. And, everyone's dream is to get to great scale, right? And not having full GraphQL functionality sort of seriously dampens dreams of using Apollo Server at scale (and especially for those who have reached it. These are people definitely leaving Apollo.....). Also, from another point of view....people that get to Apollo and see its initial potential, start using it, but also learn later, its scaling mechanism is missing features, that is a really big disappointment. That should be avoided at all costs.

2. Performance. This also goes in hand with the scaling dream too. When I look at the benchmarks linked above and also read about other experiences with higher loads than we are having currently, I'm hoping this won't be our concern. But, it's hard to not think it will be.

3. Websocket support. This seems to be all over the place currently and one of the main concerns that got me looking at alternatives. I'd like to see this feature as one of the first "attack points" in the roadmap. This should be just a matter of config for the server user/ consuming dev/ team.

4. An Exo-wish above and beyond any feature set. Get the excitement going again for the server and client combo. The client development seems to have taken most resources and gotten further faster (except I feel the concentration on React is overkill... just sayin 😄 ) I'd like to see that same kind of attention or maybe even split attentions (aka resources) on both packages more evenly, with someone (aka the leader) doing more community work too for both, together.... i.e. talking to what has happened, is going to happen and will happen to make sure the community is being taken along the journey for "Apollo". 😁

As you can see, my wish list isn't all too long. I'd love to see others' wishes too.

Apollo is a decent solution and could easily become the clear leader quickly again (from my perspective). I'm still at a "cross-my-fingers" point and would like to be in a "this-is-going-awesome" point of view for Apollo Server. I hope your work and effort along with the community's, will get us there. I'll try my best to help too, where I can.

Thanks again for the explanations. As I said, I am feeling a bit better. 😃 👍

Scott

[skk2142]

The only other suggestion I'd like to make is to get back to a public plan of action (the road map). There doesn't need to be exact release dates, but there should be some semblance of timing and commitment on milestones, like in quarters, maybe? I think this was missing originally too to this post/ the project. I realize with a small team/ few resources, it's hard to make commitments, but I say, at least try, please. I know from other projects, it's not always making commitments perfectly that count, but showing the effort is made to try and make them happen. This is, after all, OSS.

We need this!

[wabrit]

Another vote for subscription support in Apollo Federation; getting close to the point where we need to support a federated model and, regardless of the appeal of the Apollo Federation approach, not supporting subscriptions is a deal breaker and @graphql-tools/stitch would be the way to go.

[TechTeam12]

Will V3 apollo-server-lambda be designed to support both V1 and V2 of the HTTP API payload format?
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html

[glen-84]

Will V3 apollo-server-lambda be designed to support both V1 and V2 of the HTTP API payload format?
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html

There won't be any integration packages in v3:

Removal of all of the apollo-server-<integration> packages in favor of the default HTTP transport, along with copy-paste snippets in the documentation for other common patterns to deliver production-ready, out-of-the-box experiences.

(ref)

[glasser]

As a follow-up to my last comment: my top priority right now is coming up to speed on the current state of the Apollo Server project. This includes making a few important changes (see https://github.com/apollographql/apollo-server/milestone/55 for the next release milestone) as well as generally being on top of incoming issues and pull requests. (I didn't do myself any favors by going on vacation for a week right after starting, but I should catch up soon!) Once I feel a bit better informed, I plan to get back to this issue and Jesse's already existing Apollo Server 3 branch.

My guess is that the high level description of what AS3 will end up being will be less enabling the software to do new things, and more about removing things that make maintaining and improving AS challenging. Most of the changes will be focused on removing tight dependencies from AS on third-party software with their own release cycles (graphql-upload, graphql-subscriptions, graphql-playground, etc) so that we can focus on AS doing what it does best and those other projects doing what they do best. The goal of Apollo Server 3.0 will be much more about making it easy to do exciting things in AS 3.1, 3.2, 3.3, etc, rather than necessarily adding huge new paradigms itself. That said, more to come once all the low-hanging AS2 fruit is dealt with!

[Sytten]

I think at the bare minimum it needs to get rid of https://github.com/apollographql/subscriptions-transport-ws.
The rest works good enough, but subscriptions are a real pain right now (both client and server side).

[smolinari]

The goal of Apollo Server 3.0 will be much more about making it easy to do exciting things in AS 3.1, 3.2, 3.3, etc,

Awesome plan!!! Exciting is always good. Just please get a fair roadmap going for what you feel could come with the minor versions, let the community weigh in....... and off we go! 🚀 😁

Scott

[wmertens]

@Sytten subscriptions should be implemented with SSE, it's perfect for that and doesn't need any extra ports or servers. GraphQL only really uses one direction of the ws.

[nrobates]

Is there any real timeline or target date on when Federation will support subscriptions? This seems to be a fairly important need from people.

[glasser]

Status update on AS 3.0:

Since starting to actively maintain Apollo Server, my main goals have been to iterate quickly on new issues and pull requests with contributors, and to solve a serious startup error handling problem (https://github.com/apollographql/apollo-server/pull/4981 destined for v2.22 very soon I hope).

Once v2.22 is out, my main Apollo Server focus will be getting Apollo Server 3 out the door. I have put off the serious deep dive research until this point; for example, I have not thoroughly studied the release-3.x branch that Jesse has been maintaining yet, nor have I even fully read the conversation on this issue.

The overall focus of Apollo Server 3.0 will be to decouple the apollo-server codebase from dependencies that make improving Apollo Server challenging. Packages like graphql-upload, subscriptions, playground, etc should have easy hooks to be integrated from the outside rather than having Apollo Server depend on a fixed version of the package from the inside. This might mean that upgrading to Apollo Server 3 itself might not be the most fulfilling experience, but hopefully it will enable 3.1, 3.2, 3.3 etc to be full of the features people have been waiting for.

As far as subscriptions itself goes, Apollo Server 2 has a superficial integration with subscriptions-transport-ws that doesn't tie in to the plugin system, federation, Studio reporting, etc. And subscriptions-transport-ws isn't even the best maintained package that solves this problem. So 3.0 will remove that integration. I do hope that we do the work to add subscription support to the Apollo server-side platform as a whole sometime soon, but I can't promise a timeline for that — that's a larger decision than just Apollo Server planning.

[JacoBass-work]

For those searching for a solution for subscriptions integration with Apollo Federation, it might be useful have a look at the following: https://www.youtube.com/watch?v=C5pSwLpjZM0&t=2s

[eliw00d]

I recently looked into server-side caching and was surprised to find out that invalidation was not included. However, in the Apollo Server 3.x documentation, there is this note:

Invalidation of whole-query cache through cache tags with CDN integration.

Does this mean that Apollo Server 3.x, out of the box, will be able to invalidate cache based on mutations similar to Apollo Client?