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.76k 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.

smolinari commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

tvvignesh commented 4 years ago

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-data commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

mikedmcfarland commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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

Sytten commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

gmac commented 3 years ago

@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 commented 3 years ago

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

quant-daddy commented 3 years ago

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 commented 3 years ago

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

I really hope that the situation improves.

kodeine commented 3 years ago

@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 commented 3 years ago

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

kodeine commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

sgentile commented 3 years ago

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

gmac commented 3 years ago

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

quant-daddy commented 3 years ago

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

sgentile commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

👋 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 commented 3 years ago

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 commented 3 years ago

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

quant-daddy commented 3 years ago

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!