thomassharoon

We are in the middle of migrating from our monster react application into server rendered pages (with jinja2). The velocity at which we are able to ship and the reduction of complexity has been great so far.

Managing client side state for simple things like (is the dropdown open/closed), listening to keyboard events and such can be done with something like alpine-js [1] without all the baggage that something like react brings.

It appears this is already the trend with JS frameworks too - with server side rendering being the new norm.

Even on a REST API, you can achieve the same pros

> - It makes working with describing the data you want easy > - It can save you bandwidth. Get what you ask for and no more

You can describe the fields you need (and I assume that is what reduces the bandwidth)

GET /users?fields=name,addresses.street,addresses.zip

> - It makes documentation for data consumers easy

I don't think so in practice. You can see Shopify's GraphQL documentation [1]. If anything it is more complex than their REST API docs

> - It can make subscription easier for you to use

Not too different from using something like SSE or even websockets and every decent web framework seems to have a decent implementation

> - Can let you federate API calls

So many ways to achieve this at the application layer (which is what GraphQL federation does with a Router). In the python world this could be separate WSGI apps or racks in ruby? And makes no difference if done at the load balancer level.

If you are just starting out, I'd recommend starting with just the core tools [1] and a block plane.