I am going to use/learn JavaScript once a week.  I am wondering what the best backend for a store/login game server/etc. would be :  PHP or C#, or something else.  The criteria is longevity of uses, efficiency, value, and quickness to learn. 

Am I forgetting anything that would be needed, i.e. : the unresearched :  JNode.  I want to be lean with my learning.

Thank you; it has taken quite a while to consider all this,

Josheir

The language that I know the best is C++.  I will be using/studying this more too (other days.)

Javascript runs at the client level, whereas PHP/others run at the server level... so the question is, what are you trying to accomplish?

Are you intending for a web-based game (HTML5) that would rely heavily on Javascript, or will it be in an engine such as Unity or Unreal that will talk to your server and retrieve information? Or something else?

Are you planning to store values in a database for your users?

What do you plan to use the Javascript to accomplish?

Javascript itself should come pretty naturally with an OOP background, and any server is able to run it on a web page. But it really depends on what you plan to do. If its not web based, you may find that it's not worth your time to learn Javascript at all.

I was thinking of a game with JavaScript and HTML5 and a backend either PHP or C# that stored values.  I would also like the ability to create an Ecommerce Site.  I didn't know which would of these two languages would be suggested.

I don't know anything about how Unity or Unreal work, will you explain to me this?  Maybe they are for high intensity three dimensional multi player web games?

What is recommended for multiplayer web-games?

Thank you,

Josheir

Server-side, you just need a web-server that you can program. Lots of those are probably programmed in Java, but other languages will work too, as in the end, the application just serves content to the network using the HTTP(S) protocol, using some form of data base to store the data (I used just files at the file system, so even a data base is not a hard requirement).

Python works nicely in such an environment too. I used the very small 'bottle' framework ('flask' is similar, but there are many many many! others, depending on what you want from the web server). An application that handles the HTTP details, and forwards incoming requests through to my code. My code then produces 'the page', the answer to send back. Often this is a HTML text, but it can also be a JSON file or an image or just plain text.

With web development being very popular, the above holds for just about any programming language you can imagine, and quite a few you cannot imagine. Just search a bit on "web server and <programming language>", and read what the various packages provide, so you can form an opinion on the kind of things that you may want to have in such a package. Play a bit with the 'short list' to verify that you made the right choice, and it feels ok to you.

Javascript runs on server as well, just need a specialized server like digitalocean or heroku. Alternatively you could just write frontend/backend w/c++ if you really wanted to using emscripten/other tricks.
Y'aint gonna learn it all studying once/week though. 

Node.js (backend javascript) is quite good for multiplayer web games of most types btw. some caveats.

On ‎4‎/‎25‎/‎2018 at 1:26 AM, Alberth said:

(I used just files at the file system, so even a data base is not a hard requirement).

Alberth, what does this mean I'm not understanding...

Thanks,

Josheir

Thank you SkyPenguin, this is where I left off too.

Josheir

Yeah i gave up on using database too. File system is enough for many apps and often less ram/processor intensive to boot. Little javascript logic and you can get a barebones DB from it anyways.

6 hours ago, Josheir said:

>> (I used just files at the file system, so even a data base is not a hard requirement).

Alberth, what does this mean I'm not understanding...

Everybody always discusses server applications where the storage backend is a database. This makes it easy to fall in the trap of thinking a database is the only viable storage option for a server application.

However, a server application is still an application, so you can also do all the things that 'normal' applications can do (modulo things that would be trivially exploitable from a remote site, as the application reacts on unknown potentially hostile user input).

Depending on the application, using a data base for storage may not be the best choice. In my case, I had to load a bunch of translated strings in various languages (around 4000 strings in 50+ languages). Since translators (my users) work on one language rather than on one string, the typical access pattern would be to load many strings of a single language. Actually, "many strings" soon became "all strings", due to providing a list of "related string translations" as a service to the user (hopefully getting more consistent translations).

The database solution would be a 'language' table, a 'string-identifier' table (name and description of each string), and a table with the translations, for each language and string. Getting all strings of a language accesses the language table, and then iterates over the strings table, while getting the actual text from the translation table (actual database engines are probably smarter than that though).

Not being very happy about that solution, I continued looking for a better solution, and found the alternative to simply store all string-names, descriptions and actual text of one language into 1 file. That makes loading a language as simple as "open file, load the contents straight from the file system, close the file, done!". Given that the database is also stored in a file, My file-based solution is much quicker, since I am not looking for keys, and joining several tables. Writng is quicker too, as it's 1 file creation, and a few rename operations (with a possible remove to delete the oldest version).

Heard of a case similar to that... they cut down ram requirements by running stats to see what the top 99.99% of searches comprised of, which turned out to be <25% of the total database since there's a lot of stuff that no one's interested in. (think this involved pictures rather than words... but still. No one looks up a word like nikhedonia

On the note of file systems in particular as a DB, new-ish thing is to not open files but stream them direct to user and let their machine process the data.  Allows for a base C library function to handle the i/o at lightning speeds w/o bogging your server down in javascript & open files.