FactorioBlueprints
"Real Server"
As to this comment. Essentially, running an actual backend instead of using firebase's.
Reasons to do it:
- Verify blueprint strings and other information (also prevent spamming)
- Could fix issues like #5
- Will help expansion of new features that could require a backend (read contents of blueprint string?)
- Less load on client (can do more on server)
Reasons not to:
- If server-side rendering was one of the considerations (my personal favorite is EJS...), that would be scraping a lot of the existing react content
- Have to handle logins and databases ourselves. This could mean express+passport+mongo (or whatever combo you choose), but it becomes much more of a hassle (in terms of code, it might be easier to for devs to test since there's no worry about modifying the production database).
- Transfer firebase data (wouldn't be too hard in JSON format, but transferring users is a larger pain since you'd need to transfer the users over, map their firebase-id to their new id, and insert that into the old blueprints when adding those)
TL;DR
Pros: Client runs faster, more control over what we can do, clearer separation between server and client
Cons: Risk scraping a lot of the JS if a lot would be moved to backend, more hassle in terms of databases & logins
It's also possible to run a combo of a real server plus use firebase. This is a lot easier than scrapping everything. Basically you'd disallow the Javascript clients from writing to big sections of the database, but they'd still be able to read those sections. And then the Javascript UI would probably call plain rest services and the server would handle writes. Authentication using oauth gets trickier.
I'd like to warn if people post invalid blueprint strings. As you know, I'd like to allow blueprint string books, which mods export in a slightly different format. Also, one user changed a poorly thought-out blueprint into the text DELETE ME, and I guess I'll delete it.
I'm working on speed issues that I know about. I won't know how much they help until I'm done, but I don't know if server side rendering will be necessary for further speed improvements.
One goal with this project was to learn React.js and I don't want to scrap it. I plan on using it more in future projects unrelated to Factorio. I've started reading about server side rendering and the main benefit is SEO. Speed / client load seems to be a wash.
Another advantage of server side rendering is mobile browsers/browsers running on embedded systems that may or may not want heavy JS.
Not sure if you two are describing rendering static html, but react server-side rendering is different. It renders the html of whichever route you're requested to load, prepopulated with the data for that route. So far that is static html. But it also loads all of the same javascript, plus a bunch of extra stuff like dom ids that help the client javascript "take over" from the server. It helps with initial page load time but not much else. It doesn't even shrink the overall load on the client. I'm not sure whether it will be worth doing - I'm waiting to first see how much the imgur integration helps with page load time.
Not sure what this gains us. Everyone with a "server side" page has been moving more to the client with things like AngularJS. If I were to build this now I'd probably use AngularJS with an ASP.NET Web API backend, essentially the backend would just act as a REST client for the front end.
