[fChk]

I think there is some wisdom in what you advise: finish it first in php, and then add on what's needed, and change what can be improved. So for now, I think I'll stick with the traditional relational database and php for the backend, and focus on getting just these 2 pieces working as well as possible. If performance demands it, I can work on swapping php for nodejs. If performance demands more I turn to memcache. And if I'm fortunate enough to build a large community of paying users, I can look into redis.

That's the way to go!.. The point for me to bring Nodejs+Redis into the discussion was to emphasize that the LAMP stack has its limitation and that you shouldn't over-complicate(/engineer) your App setup. Instead when you hit a bottleneck just fall back to the Nodejs alternatives.

I've already converted a few of the scripts to js - but I can see what you mean about a different mind set. In php, I was very careful with a few things: to sanitize all the inputs, as php is known for injection vulnerabilities.  I made sure to place lots of exits in every script: if at any point anything goes wrong, the connection drops and error returned. None of this was too complicated; it just involved some learning.

That's because PHP is at its core a procedural language, while JavaScript is an event-driven one. Big difference in how you should think about things.. especially for handling errors/exceptions asynchronously.. And that's exactly what I meant by the mindset that is completely different. With the introduction of Promises, the mental exercise became less painful of what it was when it was all callback-based.

But js is proving more difficult. The language and syntax feels much more complex than php. There's uppercase and lowercase and punctuation everywhere. For me, it's quite simply hard to look at and read... but as you said, there is a learning curve. I'm  sure with practice I can improve. Nodejs recommends leaving the connection open and reusing it, as opposed to closing the connection - which in my mindset just seems odd, but I can see how it would get a little performance gain. The methods of sql injection prevention are very different and less well documented (unless I'm just looking in the wrong places - which is very possible). Although I do like that nodejs can run asynchronously, whereas php cannot.

It takes time to get to it, and yes JavaScript (aka EcmaScript: ES) has evolved beyond recognition during this decade--up to ES2019; so you should check that out too.

As for connection handling in Nodejs, you just trigger the end method of the response Object with the corresponding argumets:
See: https://nodejs.org/dist/latest-v14.x/doc...g_callback

Thus far, I've coded all of the server scripts by hand, and I'll probably do so for the immediate future, until I get my footing. I think it's important, starting out in the learning process, to code from scratch so I can get used to the syntax and structure of the language. At least until I can look at it and trace the flow of information in a script. Perhaps I'm wrong? Also, while it's handy to have ready made tools that do  what I want, it isn't always the most efficient. In my experience, it can lead to bloat and unnecessary complexity, so I'll try and stay away from libraries and packages until I have a better understanding of what they do and how to modify them to my needs.

No!.. you're not wrong!.. And I'm glad to read this response because that's exactly my general advice to anyone interested in the Web!.. It's way too easy to patch third-party scripts together and hack your way through them But you'll never learn how things really work and the result will always be highly insecure and way too dependent on other people's work/will, thus unstable (most likely dead at the 2/3 version iteration.)

Regarding your self-coded web server, it's a topic I never considered for myself (until now), and I'm curious why you thought it was necessary/beneficial: what purpose did you have in mind when writing it, and what methods did you use to achieve this purpose? Even your simple explanation has given me a few new terms to look up: while it might seem easy to you with your experience, it could prove an opportunity for learning for me (and others who might view this in the future)

The short answer is because I could do it :-) At that time, I've already had a fairly full understanding of how the Web works: the server part (mainly Apache back then), the client part (W3C-compliant web browsers) and the language they use to communicate with each others -ie the HTTP protocol-.

With the availability of Nodejs, the fact that I've came to master JavaScript around those times and my rising need to use Websockets for real-time WebApps gave me the motivation to start  building an HTTP-server that speaks HTTPv1.1.

It took me 9 months to came up with an implementation that's Okay-ish and that has evolved slowly since then. But I must say that it's still missing few features that I don't need/use but gets the job done as intended.

An urgent update that I must attend to ASAP and that I've been postponing for quite sometime now is the support of HTTPv2, which is built-in as of Nodejs v14.x.x

4. It's a risk. There is no guarantee that I'll keep the vps, even if I can win it. If someone comes along and makes more quality posts than me one month and asks for it, they might get it - and that would be fair. While currently we have an abundance of vps at the ready, that could change at any time. An influx of high energy posters could mean that our vps wins become highly competitive - much like the old days of freevps. Which would be great for the community,  but it'd suck for me to spend days/weeks/months setting up a redis system that's integral to my apps operation only to have it snagged from underneath me by a superior poster.

The main way a VPS is lost is when one misses the monthly post quota; the other ones are related to some form of breach (ToS etc..) And, yes, that's always a risk!

As for posts quality, no worries you're for-sure up to the challenge :-)


Few links related to Redis+Memcached:
A lot of the bookmarks generated 404, so here is what's left:

http://memcached.org/
https://www.digitalocean.com/community/t...centos-vps
https://www.pontikis.net/blog/install-me...-archlinux
https://www.cyberciti.biz/faq/rhel-fedor...ystem-rpm/

https://redis.io/documentation
https://github.com/TheDeveloper/redis-session-php
https://rtcamp.com/tutorials/php/redis-php-sessions/
https://www.digitalocean.com/community/t...untu-14-04
http://highscalability.com/blog/2011/7/6...redis.html
https://www.digitalocean.com/community/t...untu-14-04
https://www.sitepoint.com/saving-php-sessions-in-redis/

Good luck!