Ok so I've officially migrated the site off of GraphQL, to now just a plain boring REST API, and react-query. (backend in Node.js + express.js). Took way longer than I anticipated. Still some work left so some things on the site are currently broken.

I'd initially built this site a year ago using GraphQL and Apollo just because it was what I was most familiar with having used it at my last job.

Why did I migrate off GraphQL? A few reasons:

- N+1 problem, or multiple SQL calls getting made instead of just one. Maybe there's a way to solve this with GraphQL, but honestly I'm not sure how to do this, and it's certainly more complicated than with a REST API
- REST API is simpler, and more people are familiar with it. The API is public and I'm planning to open source it, so I want it to be accessible
- Tooling and resources more limited than REST APIs. Standards less defined
- Too much lock-in with apollo. I don't like to be dependent on anybody. Sure there are alternatives, but not really. Apollo also updates a lot, and old code gets deprecated.
- My frustration with dealing with Apollo's cache on the frontend
- Having to type the entire schema is actually time-consuming. I'm trying to optimize for developer speed here since this is a startup / side project and I'm the sole developer at the moment. Also I don't love decorators (funny since I'm using TypeORM and TypeGraphQL)
- Wanting to personally get better with REST APIs. Since my previous employment had been with GraphQL, I wanted to improve my REST API skills, as well as try out react-query.

For the record, the thinking was that I'd eventually back in the GraphQL API. The way the code is setup, that should be fairly easy on the backend, could maybe even write some code to automate that. The frontend of course is a different beast.

Also I like and probably prefer the concept of GraphQL. It makes more sense for a client to specify just the data they want. The problem is just the tooling on the backend is pretty immature, and with GraphQL it's more difficult to optimize the SQL queries (or someone please tell me if there's an effective way to do this that I'm not aware of, ideally pointing me to an example GitHub repository)

Ok now that the site is migrated, was it the promise land I was hoping for?

No. I've realized that react-query's cache control is way worse than Apollo's, and right now it looks like I'll be moving off

The API does seem to be faster as it should, but not as much as I expected - though I admit I didn't test this very rigorously.

### React-query caching kinda sucks

There doesn't seem to be a nice simple way to set and retrieve items in the cache: <https://stackoverflow.com/questions/76563755/how-to-normalize-react-query-cache-to-only-use-a-single-key-when-there-are-multi>

Apollo's caching is far superior because you can use cache.identify() to directly modify any entity in the cache (btw Apollo's documentation never mentioned that for whatever reason, wasting a lot of my time before I discovered that). React-query doesn't seem to have an equivalent. The only way to update the cache seems to be to manually do it for each API endpoint utilizing the data, using the exact same inputs that were used to call each API endpoint. What a pain in the ass.

Upvoting/downvoting doesn't live reflect anymore on this site, and I'm not sure how to even fix it with react-query without making the code incredibly convoluted.

Thus my plan is to get rid of react-query and handle the caching myself - or maybe make something similar to react-query, but with the control over the cache that I desire.

Anyways don't get me wrong react-query is great for simple sites, but for anything more complex I'm going to pass going forward. Or maybe I'm missing some information, but I don't see any explanation in the docs or online, and never got any real responses on StackOverflow, GitHub discussions, or tweeting at the tanner guy on Twitter.

All that being said, I'm happy the codebase migration is finished, and CI/CD is setup (I do that on all my projects now, but back when I made this I was still fairly new to Google Cloud Run and manually deploying like a caveman) so I can start developing on this site again! Maybe no one's noticed, but the last few weeks I haven't actually updated anything on this site because none of that stuff was setup, and I didn't want to touch the codebase as it was anyways.

But now I'm ready to pump out a ton of features on Zsync. Just need to undo this react-query monstrosity.

Migrated Zsync from Apollo GraphQL to REST API + react-query, not liking react-query

Hi I'm Jeremy. I'm building this site because I'm not satisfied with other online community type websites and their lack of innovation (see the /about page). The goal is to make a superior, more open, and more decentralized online community.

The site is still in early stages in active development (see the dev masterthread here: https://zsync.xyz/p/zsync-dev-update-masterthread)

Join us if this sounds interesting! Feel free to send me any feedback or reach out directly!

Hey guys,

So at the moment I'm prepping the code to open source it. Basically I'm migrating the codebase from GraphQL (what a mistake) to plain REST API, and cleaning up the code a bit. I built this last year on a tech stack I no longer like, and the code is crap, so I want to clean that up. I'd estimate the code migration is probably 80% done. Also going to add a few more features (eg. captcha, maybe a proper "subreddits" feature, basic mod tools)

Once it's open source, the idea is that anyone can contribute to the codebase, and changes will update on the live site. Or someone could just make their own frontend, fork it, whatever. I also think there's a shortage of open source code for real production apps in Node.js (more complex than a damn to-do app, the dumbest app to use as an example yet for whatever reason everyone does for reasons I'll never understand), so I think there's educational value as well. Also to be honest I'd like a code review myself as I'm sure there are many ways to improve it that I hadn't thought of. AI will make all this hand coding obsolete in 5-10 years anyways, so gotta take advantage of our last vestige of relevance before either AI apocalypse or UBI utopia.

After that, unless this actually gets a ton of traction, I'll probably redirect my focus to other projects (<https://mindgarden.app/>, and some other ideas I have), and start looking for paid work. Hit me up if you're hiring and open to remote work from any timezone (I'm currently in Seoul). It's weird how I'm such a significantly better developer than I was 4 years ago, yet it seems harder to find work and the compensation packages I'm seeing are often no higher than what I was getting 4 years ago - except now prices are like 50% higher. I think the golden age of software engineers is over. But on the positive side there's always opportunity, and I'm way more focused than my older self, so I know I'll make it work.

Also I welcome all feedback and suggestions on how to potentially make this thing site succeed. I've got some ideas, but I think it's probably going to be more of a long game.

Current Plans with Zsync (open source coming soon)

Here's the tech stack I used to build this site (if anyone cares). Using Typescript on the frontend and backend

- Frontend - Next.js, TailwindCSS, Apollo

- Backend - Node.js, Express, Apollo (GraphQL), TypeORM, TypeGraphQL. Database is PostgreSQL. Redis used for sessions.

- Servers are hosted on Google Cloud Run, and PostgreSQL database hosted on Digital Ocean (a lot cheaper than Google Cloud). GitHub actions for CI/CD, and pnpm workspaces for the monorepo (actually I didn't set up the last two for this project yet, but I did for my more recent projects so definitely will implement).

I've got mixed feelings on GraphQL to be honest. I like that the schema is built into it, but I'm not a big fan of Apollo, and the tooling is more immature than REST APIs.

These days I'm just using traditional REST APIs for my projects as it's simpler (eg. for [mindgarden.app](http://mindgarden.app) which is a Notion clone I've been building). I built zsync last year though when I was more comfortable with GraphQL. I guess we'll see which makes more sense. Beauty of using TypeGraphQL/TypeORM is that it makes it relatively simple to implement both. With a public API, I think it makes sense to offer both a REST API and a GraphQL API.

I also want to add websockets support so that posts update in real-time. Honestly there should just be a good backend abstraction that offers the REST API, GraphQL, and websockets (eg. feathersjs does this). If there's a good abstraction for this please post in the comments. Otherwise maybe I'll end up making my own, admittedly for the fun of it.

That's the challenge with building stuff as an engineer though - so easy to get lost in technical rabbit holes when users don't give a f about your tech stack as long as your product has the right features and works.

How I Built Zsync - The Tech Stack

I will post dev updates as comments in this thread.

Feel free to comment with any requests / feedback / thoughts

ZSync Dev Update Masterthread

Post all site feedback here. Unfiltered honest feedback welcome(fyi here is the dev update thread: <a target="_blank" rel="noopener noreferrer nofollow" href="https://zsync.xyz/p/zsync-dev-update-masterthread">https://zsync.xyz/p/zsync-dev-update-masterthread</a>)

ZSync Site Feedback Thread

Here's the current tech stack of this site:Hosting: Google Cloud (Cloud Run, Cloud Storage)Database: PostgresSessions, caching (not implemented yet): RedisBackend: Node.js with TypeGraphQL, TypeORMFrontend: Next.js, React.js, Apollo GraphQL, TailwindCSSEthereum: ethers.js, hardhat (not implemented yet)Once the features I want to build are finished, I'll start moving things to IPFS and Arweave. For full decentralization may consider Ceramic. But my priority now is getting all the core features implemented first before going full decentralization. The main problem with decentralized webdev now is immaturity in the ecosystem (which I wrote about <a target="_blank" rel="noopener noreferrer nofollow" href="https://jeremyfreedom.substack.com/p/the-biggest-missing-piece-in-web3">here</a>) and performance.I didn't pick this stack because I think it's superior to others, I picked it just because it's what I'm most familiar with, and thus what I can develop the fastest in. Tech stack really isn't the highest priority for an early stage startup because the primary goal for a startup is getting product-market fit.Once things are production-ready and in a good enough state, will move to open source. In the meantime if you're interested in working on this, just comment here and/or shoot me a message and I'll get you access.

zsync-dev

t/zsync-dev

Migrated Zsync from Apollo GraphQL to REST API + react-query, not liking react-query

Current Plans with Zsync (open source coming soon)

How I Built Zsync - The Tech Stack

ZSync Dev Update Masterthread

ZSync Site Feedback Thread

How I Made This Site - The Tech Stack