michaelghayes

FWIW, the Guild (the group behind a lot of the more popular GraphQL libraries) has recently take stewardship of this package, and it looks like there are already a few recent PRs merged into the repo.

Lack of updates also isn't necessarily an indicator of disuse. It currently has close to 5 million weekly downlaods, roughly 1/5th of express which is probably the most popular library for building APIs in node.

down in Oregon as well

One of the most common questions about get about Pothos is how does it compare to nexus. Pothos takes a very different approach to how it achieves type-safety. nexus relies on code-gen that generates types that roughly match the shape of your graphql API. Pothos instead infers (or can be explicitly provided) type information from your data. While this doesn't seem like a huge difference, Pothos has a fundamental separation between the shape of your data and the shape of your API. allowing you to more naturally map real world data into your desired graphql schema.

apart from the type system, the biggest advantage of Pothos is the plugin system, and the wide range of plugins. I've put a lot of effort into designing a way for plugins to compose in a way that allows them to work well together, and take full advantage of the type-safety Pothos provides. many libraries in graphql ecosystem today don't let you take advantage of the schema and types described by your graphql API, Pothos tries to allow features like auth, data loading, and validation to be defined along side your schema definition, giving you better type safety than you get from other alternatives. it's hard to explain how well this works until you actually start building an API with it.

All the (great) recommendations in this comment section are a great example of how the js ecosystem works. there are so many great new technologies available for building apps, but standardization and discoverability are far from solved.

There are new esm based cdns (similar things have been around since the browserify days), awesome new build tools like esbuild, skypack, and swc that are faster and/or simpler than webpack. new language features have been standardized that reduce the need for various types of libraries, etc.

For anyone who doesn't spend an unreasonable time following these developments discovery of all this cool new things seems very tough.

On the opposite side of things, as a developer of a library I think is really useful, figuring out how to help people find it, I have no idea where to start.

one popular option is to have a query whitelist, with arbitrary queries allowed either through special permissions, or just in development. setting up CI steps to auto-publish any queries used by your apps is usually pretty straight forward. this obviously only works for non-public APIs.

Another common patter is to have a way to calculate query complexity, where each field had some cost, and some multiplier for list fields so you can calculate an approximate complexity before executing a query

Hey, author here. This is a project I've been working on for a while. This was inspired by frustrations I trying to build out a GraphQL service in node at airbnb. We used an early version of this with a lot of success to build out some of the support tools at airbnb. If you have any questions or feedback, let me know!

there is somehting similar that I have been using on windows for a while. I really love being able to use media keys http://vhanla.deviantart.com/art/Google-Music-Desktop-Player...

seems to be down

I beleive it is 1/16/2013