next »

[everlive]

So, I am aware that there is no way to protect your code, especially in the case of JavaScript that is required to be visible.

But I am curious if there is a way to use PHP to generate it onto a page and are their any benefits or disadvantages like loading time and what not?

[oahda]

I think it would show up if you clicked to view the source even if generated, just like you can inspect generated HTML, so I don't really see the point of doing that instead of just writing the JS directly. Seems harder to work with for no particular reason.

[everlive]

Mostly to explore the idea of manipulating JavaScript through PHP and used a PHP database to do it.  Apart of JSON of course.

[oahda]

Oh. Right. Yeah, was gonna suggest JSON before I read the end of your message...

Well, it's possible, of course. But I can't think of any use case for it.

[Cheezmeister]

This again? "Protect" your code from what?

If it's code generation you want, sure, you can do that through PHP, but like Prinsessa I don't really see what it actually buys you. (Databases are for data, not code. It's in the name )

[wccrawford]

No, there would be no benefit to loading time, and it would probably only be worse than normal since you've added PHP into the mix.  (Any other language would have the same problem.)

The only way to protect your code is to not send it to the user.  As such, you could have most of your code server-side (PHP or NodeJS or others) and then the user only has access to the code that shows the game state and lets them interact with it.  The real logic would all be on the server.

Of course, you pay a performance penalty there, and you have to run all the code on the server, so your server costs go up, too.

[everlive]

No, there would be no benefit to loading time, and it would probably only be worse than normal since you've added PHP into the mix.  (Any other language would have the same problem.)

The only way to protect your code is to not send it to the user.  As such, you could have most of your code server-side (PHP or NodeJS or others) and then the user only has access to the code that shows the game state and lets them interact with it.  The real logic would all be on the server.

Of course, you pay a performance penalty there, and you have to run all the code on the server, so your server costs go up, too.

Yes, as I said in my first post I know you can't hide anything once it is in the browser.

The main point of this thread to get some answers about JavaScript/PHP interaction.  Most importantly, how to attach a JavaScript game to a PHP database, then assign each player an area of the game so that no player can control another.  Then feed the results of the match back to the PHP database to update the player's statistics.

I would assume object instances in the game state via JavaScript would do the trick based on what the MySQL database gives it.

It's partly my lack of knowledge in the area at fault.

[oahda]

To talk with a database I'd use AJAX to talk to a small PHP page that outputs JSON, sort of like you said, but you never mentioned AJAX.

[bun]

The main point of this thread to get some answers about JavaScript/PHP interaction.  Most importantly, how to attach a JavaScript game to a PHP database, then assign each player an area of the game so that no player can control another.  Then feed the results of the match back to the PHP database to update the player's statistics.

I would assume object instances in the game state via JavaScript would do the trick based on what the MySQL database gives it.

There are really two separate questions here:

• state initialization
• ongoing communication

For the second point, Javascript & PHP themselves are irrelevant: like in any other networked game, you need to communicate with the server over some protocol. JSON messages over HTTPS connections or websockets is the popular and obvious option.

The first point is more interesting. As you suggest, you can use PHP to generate some or all of the Javascript that is being served on the page.

However, this has some consequences:

• security: if you're directly generating Javascript code in PHP, you could end up opening yourself up to script injection and other nasties caused by malicious user input, and
• poor separation of code: your client-side code becomes tightly coupled to the backend, which makes it harder to test, move, refactor, etc.

The more modern option - which has become increasingly popular with the rise of bundling tools like Webpack - is to serve your Javascript code as a library on your own page that has an explicitly constructor / initialization pattern / entry point. You still might need to get some initial user state onto the page to pass into your JS code - such as a user ID or an auth token or whatever else - but that can then just be a plain JSON object, which you can sfely serialize onto the page from a native object in your backend code.

It's a little bit more work initially to get it set up, but it's well worth it for the strong logical separation you get out of it, and makes it easier to add nice stuff like offline storage on the browser side, to swap out the backend, etc.