I have multiple pain points, my main grief is their routing, I very much prefer the way react-router does it. I realize Remix seems to have adopted this file based routing and even added some (imho) bad conventions when it comes to loaders having to be named the same as the route. I just have the constant feeling that Next is trying working against me :-)
Regarding GQL:
I am building my own because of performance, there's a lot of combining data from redis and postgres (I host my own redis and PostgreSQL on the one server I am running).
Regarding gRPC:
It's just so extremely convenient to use gRPC to talk between microservices, plus I've wanted to dig in to that for a good while now so this was the perfect opportunity! :-)
Regarding CloudFlare:
I only run it in front of the API, which is hosted on my dedicated server (again, for performance reasons). Hosting the API on Vercel (AWS Lambda) would have added a lot of latency, plus, reduced the performance with thousands (maybe hundreds of thousands of percent!). I'm pretty sure my server will have parsed and returned the result before Lambda has even started (even on warm starts). The main site (which I host on Vercel) is set up using their SSL already!
Thanks for the answer! NextJS does file-based routing and quite a few people I've met aren't really fans of it. I wasn't too at first. Remix afaik does the same thing but provides a more granular set of tools to optimize for your use case.
If the issue is having to name your component the same as your route, what you can do is to create the component in a different directory (name it views, screens, etc.) and then import that component, and export it from the pages directory. You could use the babel-module-resolver-plugin to help ease on the relative import paths (the ../../../ nonsense).
I really like the fact that you mentioned that your server would've finished a task before a cloud function would, but then again though you have to worry about scaling, and that's quite tedious. In your particular situation do you think it is worth this potential future work?
Yeah I'm probably giving Remix a go pretty soon, hopefully there'll be some more content around it out soon to really help cement that decision. I really want to support the great work Ryan and Michael is doing for the React ecosystem.
About future scaling, it's not going to be a problem to switch over to cloud solutions in the future to meet the demand, but I also enjoy running my own servers (10+ years of sysadmin background). At my startup we are all-in on AWS so that's probably where I would set stuff up if I needed to. The performance difference per $ for going from bare metal to cloud is pretty insane though and this specific applications need to extremely fast in order to be helpful.
I was on the sysadmin team for one of the most trafficked sites in Sweden for a few years, which at that point ran on bare metal servers in three different DCs in Stockholm. That said, my dream scenario is definitely to host this on AWS at some point, but since performance per $ is extremely important in the beginning, bare metal is the way to go! :-)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Regarding Next.JS:
I have multiple pain points, my main grief is their routing, I very much prefer the way react-router does it. I realize Remix seems to have adopted this file based routing and even added some (imho) bad conventions when it comes to loaders having to be named the same as the route. I just have the constant feeling that Next is trying working against me :-)
Regarding GQL:
I am building my own because of performance, there's a lot of combining data from redis and postgres (I host my own redis and PostgreSQL on the one server I am running).
Regarding gRPC:
It's just so extremely convenient to use gRPC to talk between microservices, plus I've wanted to dig in to that for a good while now so this was the perfect opportunity! :-)
Regarding CloudFlare:
I only run it in front of the API, which is hosted on my dedicated server (again, for performance reasons). Hosting the API on Vercel (AWS Lambda) would have added a lot of latency, plus, reduced the performance with thousands (maybe hundreds of thousands of percent!). I'm pretty sure my server will have parsed and returned the result before Lambda has even started (even on warm starts). The main site (which I host on Vercel) is set up using their SSL already!
Thanks for your input ❤️
Thanks for the answer! NextJS does file-based routing and quite a few people I've met aren't really fans of it. I wasn't too at first. Remix afaik does the same thing but provides a more granular set of tools to optimize for your use case.
If the issue is having to name your component the same as your route, what you can do is to create the component in a different directory (name it views, screens, etc.) and then import that component, and export it from the pages directory. You could use the
babel-module-resolver-pluginto help ease on the relative import paths (the ../../../ nonsense).I really like the fact that you mentioned that your server would've finished a task before a cloud function would, but then again though you have to worry about scaling, and that's quite tedious. In your particular situation do you think it is worth this potential future work?
Yeah I'm probably giving Remix a go pretty soon, hopefully there'll be some more content around it out soon to really help cement that decision. I really want to support the great work Ryan and Michael is doing for the React ecosystem.
About future scaling, it's not going to be a problem to switch over to cloud solutions in the future to meet the demand, but I also enjoy running my own servers (10+ years of sysadmin background). At my startup we are all-in on AWS so that's probably where I would set stuff up if I needed to. The performance difference per $ for going from bare metal to cloud is pretty insane though and this specific applications need to extremely fast in order to be helpful.
I was on the sysadmin team for one of the most trafficked sites in Sweden for a few years, which at that point ran on bare metal servers in three different DCs in Stockholm. That said, my dream scenario is definitely to host this on AWS at some point, but since performance per $ is extremely important in the beginning, bare metal is the way to go! :-)