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.
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! :-)