pothos VS redux-toolkit

A project I maintain Pothos uses a global namespace with a bunch of interfaces to allow plugins to extend interfaces defined in core or other plugins. This allows plugins to add new options and methods to objects and classes without the other packages needing to know anything about them.

I noticed this being shared around on Twitter the other day - pretty handy, as I'm currently trying to architect a similar experience for my job using Pathos and graphql-codegen.

- tRPC

But I'd likely throw out Clerk a cheaper option:

- Supertokens, and also since Supertokens is easy (lots of enthusiastic reports about it), has a managed solution (which is cheaper than the alternatives), is secure and scalable (rotating refresh tokens with JWTs), open source, has magic links, and the architecture of Supertokens would allow me to simply and quickly eject to self-hosting it if/when I'd eventually need to (if the app ever reaches mass-market scale).

And I might throw out tRPC for the equivalent GraphQL experience (esp. if business strategy dictates I need a 3rd party API):

- GQty.dev on the client, for inferred queries/mutations. For rapid dev speed. Simple code example: https://gqty.dev/docs/intro Then move to URQL or Relay at scale, or just skip GQty and go with URQL from the start (if scalability trumps dev speed).

- Pothos http://pothos-graphql.dev on the server, for auto building the schema from your TS code (aka. code-first). Better than Nexus (e.g. Max Stoiber moved from Nexus to Pothos on his Bedrock starter template because Pothos is best in class: https://bedrock.mxstbr.com/tools/pothos/ ).

And I might throw out NextJS (Webpack) for the equivalent experience in Vite:

- vite-plugin-ssr, since both architectural control (libraries > frameworks) and Vite rocks. I'd likely then have to make solito-vite https://github.com/nandorojo/solito/discussions/157 to have a unified navigation between React Native and Web, but Solito is allegely tiny, so recreating it should be doable.

(If doing all of these replacements, maybe starting from scratch would be easier than modifying create-universal-app ... That said, I think if someone made a starter repo with the above choices it would be a real killer!)

Then I'd also likely use:

- Vercel (and try their Edge Functions, for a serverless sweet v8 isolates experience without slow cold starts), or maybe Cloudflare Workers (cheaper, slightly more hassle?) for hosting.

- Planetscale or Supabase for the DB. (Not brave enough to try EdgeDB or SurrealDB just yet, though EdgeDB is close..) Unless I had a specific use case where a more specialized/optimized DB would make sense.

This stack should stick even post-MVP, as it's not only optimized for a solo developer but for scalability.

Have you used Pothos? It's a way to make GraphQL schemas in TypeScript, in a type-safe way. So the creator of Prisma Client Rust is thinking about making a Pothos-style API based on the t builder pattern:

I would recommend Pothos (https://pothos-graphql.dev/) as a more modern alternative to typegraphql or nexus.

Depends on language, I've build GraphQL servers in a few, though mostly JavaScript and Python. For Python I used to use Graphene, these days I use Strawberry.

For JavaScript, I originally used graphql-js and express-graphql, as these were the original libraries and I was a literal day 1 adopter. All the libraries are essentially just wrappers around graphql-js, so it's still viable to use directly. But for schema-building I now use Pothos (https://pothos-graphql.dev/), I'd probably use graphql-helix as the http layer (https://github.com/contra/graphql-helix).

Pothos is a breeze of fresh air when it comes to building GraphQL APIs. It is a library that lets you write code-first GraphQL APIs with an emphasis on pluggability and type safety. And it has an awesome Prisma integration! (I am genuinely excited about this one, it makes my life so much easier.)

In today's article we are going to create a GraphQL api using the Koa framework together with the GraphQL Yoga library and Pothos. In addition, we will use Kysely, which is a query builder entirely written in TypeScript.

If you're a GraphQL developer, Pothos is the best example - all your user-defined types just fits in it like a glove 99% of the time. It definitely makes the most use of TS generics.

https://pothos-graphql.dev/

(I'm a bit sleepy, so this is the main one I can think of at the moment that I really enjoy using.)

In my example I am using Redux Toolkit and I got a prompt for actions to login and logout the user. If I need more functions, I can simply start typing the name, and Copilot provides the completion. For instance, in the example, I'm adding a function to update the user. And of course at the end of the file it suggests the exports.

Check out the official documentation.

Redux Toolkit 2.0

Redux Toolkit 2.0 is almost here! Hopefully shipping by this weekend :) Migration page

I am _thrilled_ to announce that:

Redux Toolkit 2.0 is LIVE!!!

- https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0

This major version has new features, faster perf, smaller bundle size, and removes deprecated options.

It's accompanied by majors for all our Redux family packages

## RTK 2.0:

- a new `combineSlices` method for lazy-loading reducers - Updates to `createSlice` to include a `selectors` field and allow defining thunks inside

- Immer 10 w/ faster updates

- Removal of deprecated options

See the migration guide:

- https://redux.js.org/usage/migrations/migrating-rtk-2

All of the Redux libraries now have modernized packaging with full ESM/CJS compat. They also ship modern JS (no transpiling for IE11), which means smaller bundle sizes.

We've also done byte-shaving work to shrink the bundles (extracting error messages, de-duping imports)

## Redux core 5.0:

- The TS conversion we did in 2019!

- Action types _must_ be strings

- `UnknownAction` as the default action type

- Better preloaded state types

- Internal subscription improvements

- Still marks `createStore` as deprecated!

- https://github.com/reduxjs/redux/releases/tag/v5.0.0

## React-Redux 9.0:

- *Now requires React 18 and RTK 2.0 / Redux 5.0*

Oh hey, that's my post!

(yes I spend too much time refreshing HN :) )

FWIW I did end up with a packaging combination that seems to work sufficiently. I never did fix the "FalseCJS" issue that `are-the-types-wrong` is detecting. I played with double-emitting TS typedefs, and the `tsup` tool _does_ actually have support for that now (added by Andrew Branch from the TS team). So it might be more feasible now. But ultimately I decided I was tired of messing with packaging setup and that what I've got is good enough. (hopefully)

We're actually about to launch Redux Toolkit 2.0 and Redux 5.0 this week, assuming the last couple pieces come together. Here's the latest RCs - you can see the current `package.json` files in there:

- https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0...

- https://github.com/reduxjs/redux/releases/tag/v5.0.0-rc.1

However, Redux, or pure Redux to be specific, can be quite verbose and boilerplate-heavy. It requires a significantly lengthy setup, which is where Redux Toolkit comes in handy, offering a simplified and more efficient way to set up and manage state in your React applications.

State manager is a tool or library that helps manage the state of an application. It provides a centralized store or container for storing and managing data that can be accessed and updated by different components in the application. A state manager solves several problems. Firstly, it is a good practice to separate data and the logic related to it from components. Secondly, when using local state and passing it between components, the code can become convoluted due to the potential for deep nesting of components. By having a global store, we can access and modify data from any component. Alongside React Context, Redux or MobX are commonly used as state management libraries. Learn more Learn more