JS Clientside + Database Framework Serverside

[leanderr]

Hey,

im new to Webdevelopment with JS. Im almost done coding a little game with the 3D-Engine Babylon.js. Now I want to add Functionionality to for User Accounts and Scoreboards. Replays should also be stored in JSON files and uploaded somewhere.

Which Serverside and Database Framework would you suggest? Is nodeJS good to go for, I tend to use it because its so popular and demanded today.

Depending on the Framework you suggest, how would local/clientside JS communicate with the Serverside?

Best Greetings, Leander

[mattstyles]

1 hour ago, leanderr said:

Which Serverside and Database Framework would you suggest?

nodeJS would be more than capable of handling what you need (so would most anything though), the number of frameworks/db choices is staggering though. Scoreboards are fairly easy, but, depending on how complex you want to go cracking user accts can be trickier, usually due to auth and the level of security you want to use.

I've experience with Koa, Express and Hapi for nodeJS, all are well documented, well supported and very easy to use. DB's you have lots of choices, simple key-value stores are probably easiest for you with stuff like Redis and Couch being very fast in-memory stores (on-disk persistence, which you'd need, can be configured), I can also vouch for RethinkDB which is a relational document store, its likely more than you need but its easy enough to setup and very fast. I wouldn't recommend stuff like Mongo but, again, its very capable of handling what you need.

1 hour ago, leanderr said:

how would local/clientside JS communicate with the Serverside?

Create or use a RESTful api and communicate via ajax/fetch. RethinkDB supports web sockets out of the box and has a very nice streaming api which might be nice i.e. to see scores on the scoreboard update in real time, but, that would depend how complex you want to go, its not too tricky but just making a fetch request for the current state of the scoreboard is easier.

There may be services out there that can handle these sort of things for you (for a price, maybe try Firebase, I've never used it so can't really comment on whether it would fit for you).

[leanderr]

Thanks @mattstyles, I will have Research about REST.

I got 40-90kb sized JSON files that are recordings of the player input for playback. Vector3 x 10 Objects x 60fps x 60 seconds x 3minutes a game ==> ~40kb JSON file. Where would you store those? Which Database for storing and accessing them? Would a Database even be the right tool for the storage of those?

[mattstyles]

On 13/02/2017 at 1:51 PM, leanderr said:

Thanks @mattstyles, I will have Research about REST.

I got 40-90kb sized JSON files that are recordings of the player input for playback. Vector3 x 10 Objects x 60fps x 60 seconds x 3minutes a game ==> ~40kb JSON file. Where would you store those? Which Database for storing and accessing them? Would a Database even be the right tool for the storage of those?

Yep I'd stuff text into a DB, most have an in-memory cache with disk persistence and most handle it all in the background for you, giving you (hopefully) the best of both worlds by providing fast in-memory storage backed by on-disk storage. I've experience with RethinkDB and Redis doing this and I've never had to muck with the caching layer they manage, RethinkDB, for example, has a configurable cache layer that will be as hungry as it can be, hence they recommend a non-skinny box (I think they prefer 2GB of memory, which is still pretty small and cheapish) but I've run it happily on a tiny box (half gig, or maybe 750, I can't remember) with no issue for low traffic, in theory the only issue would be that less is held in memory so more disk access so less performance, note that most of these DB's handle sharding/slaves/etc so they can scale horizontally, I've never had to do this and I've no idea how it interacts across instance (presumably the cache layer would prefer to run on one box with disk storage shared across instances, this sort of DB management I've never had to do so I'm sure of all of the ins-outs of it).

Depending on your userbase you might want to consider restricting the playback info to last 3 or 5 plays, to save storage space, or kill old playbacks or whatever (the cache layer should manage itself i.e. stuff that hasn't been accessed for a while will get removed from the cache but persist on disk). Of course, if your users are paying for their acct then that should cover how much storage space you allow them to consume and hence recoup your costs.

[ClusterAtlas]

Whichever you use, optimise your JSON's, keep the real-time things in memory, and the sensitive ones (including checkpoints) in the database