[Pull Request] Implement local SSL proxy for running the app with a .test domain instead of ngrok

[meditto]

This pull request introduces the implementation of a local SSL proxy to facilitate running the application using a .test domain. Currently, the app relies on Ngrok for tunneling and exposing the local server to the internet. However, this approach has limitations and can be cumbersome for testing and development purposes.

The local SSL proxy provides a more streamlined solution by allowing the app to be accessed locally through a .test domain. This simplifies the setup process and ensures a secure and reliable connection for local testing.

Key Changes:

Added the local-ssl-proxy library to the project dependencies.
Added an npm script to generate the certificate and configure the proxy.
Updated the app's configuration to utilize the local SSL proxy for serving requests.
Documented the necessary steps for setting up and using the local SSL proxy in the README file.
Benefits:

Improved development workflow: With the local SSL proxy, developers can quickly and easily access the app using the .test domain, eliminating the need for external services like Ngrok.
Enhanced security: The local SSL proxy ensures secure connections between the app and the local machine, protecting sensitive data during testing and development.
Simplified setup: By utilizing the .test domain, the setup process becomes more straightforward and reduces the dependencies on third-party services.

[kinngh]

.vscode contains snippet library and cannot be ignored.

[kinngh]

Unnecessary complications. it's going to be really difficult to explain to people who don't understand what's happening under the hood and later for them to debug it.

[kinngh]

Also, while understandable why you potentially see running a local proxy server instead of using ngrok, it's easier to debug, easily replaced with other tunneling services and more importantly, more approachable. Explaining everyone how to find your hosts file and sudo it for permissions is going to drive beginners / mid level devs insane, is not easily portable to other machines (should they decide to change it) and requires device specific setup.

The repo should be npm i, npm run ngrok, npm run dev, which it delivers on. Anything that is added in, like npm run update:url is to improve dev experience and should work across all devices. The moment there's more complication to this process it's going to worsen the developer experience.

What I'd recommend is to fork the repo and keep it synced to this repo so it's up to date while maintaining your preferred dx.

[meditto]

Hello @kinngh, I hope this message finds you well. Firstly, I am grateful for reviewing my pull request. Your feedback is greatly appreciated, and I value your insights on improving the developer experience.

I understand your concern about the approach I took with running a local proxy server instead of using ngrok. However, I fully agree that ngrok provides a convenient and beginner-friendly solution for tunneling services. I initially implemented it to cater to the needs of advanced users who prefer a more robust experience.

However, my intention was also to provide an additional feature that could benefit advanced users without affecting the experience of beginners. By introducing the option to use a local proxy server, developers who are more experienced and comfortable with custom setups could enjoy a super fast loading speed and enhanced debugging capabilities.

It is important to note that ngrok has some limitations, especially in custom subdomains. Custom subdomains are only available for premium users, meaning non-premium users would have to change the application URLs each time they use ngrok. I guess this is why you build npm run update:url; this can be inconvenient and time-consuming, particularly for beginners who are just starting their development journey.
To strike a balance, it would be beneficial to provide a clear guide in the documentation that outlines both the ngrok option for beginners and the local proxy server option for advanced users. This way, developers can choose the method that aligns with their skill level and requirements. We can also use localhost to eliminate the hosts file step.

Once again, thank you for your valuable feedback. I am open to any other suggestions or modifications you may have about this pull request. Again, your guidance and expertise are precious.

[kinngh]

About ngrok and ever changing subdomains - it's something that's bit of a problem, but if you're doing this fulltime I don't see why spending $8/month would be too much to ask for - besides ngrok can easily be replaced with Cloudflare Tunnel which allows for static subdomains without payments, so running npm run update:url once would suffice.

As far as senior devs are concerned, I'd say simplicity is the key. I like to consider myself a senior dev and other devs with the senior title around me have agreed while your suggested approach is great, it doesn't benefit enough to be working great with other devs who aren't as experienced and this approach will cause. There's enough forks of the repository with changes and libraries swapped out and I appreciate all of them.

The idea of my repos is:

1. This is the starter I personally use to build my apps.
2. This serves as a bridge between the official approach and the "I'm gonna build how I want" approach.

I personally prefer Cloudflare Tunnels but ngrok is more approachable. Even senior devs who are just starting out first need something stable enough to work, then move on to adding their own customizations. If the repo gets that opinionated, it hinders the ability for all devs, including you and me, to make incremental changes. This is also one of the reasons the repo doesn't come prebuilt with SWR or React Query, because this allows you and I to clone / fork and build our own versions while keeping the core in sync with the base repo, benefitting everyone in the process.

[meditto]

Thanks, @kinngh. I completely understand your viewpoint on simplicity.