Honestly, I think either SQL or NoSQL would be fine, mainly depends on what ppl are comfortable with.
That said, Id like to suggest mongo for two reasons:
flexible schemas seems to fit well with a “variants” server where we might have multiple formats in the same Game table
native JSON - since the code is going to be some kind of JS, it will play nicely
Woah, yeah WebRTC games would be super cool. I don’t think I trust localstorage to last for correspondence games, but still something I’d be interested in seeing
I don’t think different definitions for moves are a problem. We just have to store which kind of moves they are. And the possible board positions may also vary between definitions. Anyway if we store one representation of the game history, we can always create a different representation if need be.
I think we just need to decide how the game history should be shared between frontend and backend as changing that later requires the most adaptions.
I agree, but mongo is a change for those who learned the use of relational databases (which I’d guess is the majority of developers, including me). That said, both is fine for me.
Also the real time communication itself can pose a challenge for correspondence games, right?
Hey y’all, so I thought it would be easier to put some of these ideas in action if we had some base to work from. It’s super rough right now, but at least one can play a game of Go on here!
Major Caveats:
No database, so games will be lost to the void every time the server restarts.
No user management, so anyone can play moves in any game.
If you create a game, you need to refresh for it to show up in the game list.
EDIT: I had to make a few decisions here (e.g. React, node, yarn) mostly based on the tech I’m most familiar with. All of these are totally reversible! If you want to add/remove tech, that’s welcome
EDIT2: In my experience, getting up and running on a new codebase is hard. I hoped to make it as easy as possible:
Seems like you were eager to do some programming, while I do like to take some thinking time for stuff like this . I guess we have to find some balance if we want to do this collaboratively.
In general I think we should make decisions like that together, but as long as things are easy to change there’s no harm in picking something until a decision is reached.
Regarding frontend vue.js would be an alternative to React, I’ve used Vue for the MPGO server and it’s quite nice. But i’ve never used React, so I can’t compare it. Do you know Vue @benjito?
Regarding runtime I’ll try to get some Deno project going (maybe even port yours), I’m still curious how that works. This week I’m pretty much available all the (central european summer) time and I’d like to work on the variants server, so if anyone wants to chat about the project, feel free to reach out to me here or via DM.
I haven’t used Vue yet, but I’ve heard great things about it and I’d be interested in learning! It’s more similar to Angular right? I know Lichess uses Vue so we may even be able to borrow stuff from there too. At this point, it would be pretty quick to rewrite the client if anyone is up for that.
I’m interested! Seems like I’m the farthest out timezone-wise (UTC-7) so feel free to meet without me if the time doesn’t work out, but I think the best overlapping block is Pacific morning/Europe evening:
Then you need to convince someone who is able to change data in the database (developer, or moderator if the process is automated) to re-establish the access to your games.
It would also require some feature to share your authentication between different devices (or browsers).
In the end it would be good to have multiple options for authentication, like OGS has. I’d really like SSO via OGS, but I don’t know whether OGS would like that too and how easy it would be to implement (on both sides).
Currently I think this should be handled within the moves, so no additional field. There will be variants that hide (some information of) stones in other cases too, so we’d want to keep it flexible. We’d have to filter the moves before sending them to clients, but I think that’s not a big issue. We can always do some sort of caching if there’s a problem with performance.
In that case, email/pass seems like a good place to start and we can add SSO for various providers as we go. Still I think it would be valuable to provide some kind of OGS linkage/verification if technically feasible.
Same. I imagine most of the work is in on the OGS side though, so I wouldn’t want to make this ask until we had some value on our end.
cool yeah I wasn’t thinking about hidden info. Filtering the moves array sounds like a reasonable way to do address both.
I can only speak for myself, but now that we have variants covering the major bases (hidden moves/alt boards), I’m going to shift my focus to smaller details - better error messages/error handling, less raw JSON in the UI, paying down tech debt etc… So if you have any thoughts on how to make the site more approachable (for users or developers) happy to hear them!
Ah yep. I realize that’s not totally clear. Maybe we should leave the “Take Seat” button visible all the time, but alert() if you haven’t clicked “Remember Me”?
Or show a text like “log in to take this seat” at each open seat or “log in to take seats” at the beginnig or the end of the seats panel? That would save the users two clicks.
Consequently the “remember me” button should then be called something like “log in as guest” or “log in with cookie”.
Or be moved to a nav bar at the top that says “(you are) not logged in” or “(you are) logged in as guest”.
/j
. I guess we have to find some balance if we want to do this collaboratively.
cool yeah I wasn’t thinking about hidden info. Filtering the moves array sounds like a reasonable way to do address both.
