Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am looking for real-world scenarious for using Web Workers API.
John Resig (of jQuery fame) has a bunch of interesting examples of using web workers here - games, graphics, crypto.
Another use is Web I/O - in other words, polling URLs in background. That way you don't block the UI waiting for polling results.
Another practical use: in Bespin, they’re using Web Workers to do the syntax highlighting, which you wouldn’t want to block your code editing whilst you’re using the app.
From Mozilla: One way workers are useful is to allow your code to perform processor-intensive calculations without blocking the user interface thread.
As a practical example, think of an app which has a large table of #s (this is real world, BTW - taken from an app I programmed ~2 years ago). You can change one # in a table via input field and a bunch of other numbers in different columns get re-computed in a fairly intensive process.
The old workflow was: Change the #. Go get coffee while JavaScript crunches through changes to other numbers and the web page is unresponsive for 3 minutes - after I optimized it to hell and back. Get Back with coffee. Change a second #. Repeat many times. Click SAVE button.
The new workflow with the workers could be: Change the #. Get a status message that something is being recomputed but you can change other #s. Change more #s. When done changing, wait till status changes to "all calculations complete, you can now review the final #s and save".
I have used them for sending larger amounts of data from the browser to server. Obviously, you can do this with regular AJAX calls, but if this takes up one of the precious connections per hostname. Also, if the user does a page transition during this process (e.g clicks a link), your JavaScript objects from the previous page go away and you can't process callbacks. When a web worker is used, this activity happens out of band, so you have a better guarantee that it will complete.
Another Use case:
Compressing/De-compressing files in the background, if you have a lot of images and other media files that are exchanged from the server in compressed format.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 13 days ago.
Improve this question
I have a react web app which generates solutions for rubik's cubes. When the user makes a query on my site, it starts a long computation process (anywhere from 1 second - 240 seconds). Every time a solution is found, the state is changed and the user can see the new solution.
However, this app often crashes on mobile for large queries, I believe the browser is demanding too much memory and kills my page. Because of this, I want to add a node.js backend to handle the computation.
I would like for the following functionality:
When the user makes a query request, it sends that to the backend which can start computing. Every so often, the frontend can update to show the current tally of solutions.
If the user prematurely wants to cancel the process, they can do so, also killing the backend thread.
How can I set this up? I know I can very easily make HTTP requests to my backend and receive a response when it is done. However, I'm not sure how to accomplish the dynamic updating as well as how to cancel a running thread. I have heard of long polling but I'm not sure if this is the right tool for the job, or if there is a better method.
I would also like this app to support multiple people trying to use it at the same time, and I'm not sure if I need to consider that in the equation as well.
Any help is appreciated!
However, I'm not sure how to accomplish the dynamic updating. I have heard of long polling but I'm not sure if this is the right tool for the job, or if there is a better method.
Three main options:
A webSocket or socket.io connection from client to server and the server can then send updates.
Server-sent events (SSE is another way for the server to send updates to the client)
Client polls the http server on some time interval to get a regular progress report.
as well as how to cancel a running thread
If by "thread" here, you mean a WorkerThread in nodejs, then there are a couple of options:
From your main nodejs process, you can send the thread a message tell it to exit. You would have to program whatever processing you're doing in the thread to be able to respond to incoming messagessto that it will receive that message from the parent and be able to act on it. A solution like this allows for an orderly shut-down by the thread (it can release any resources it may have opened).
You can call worker.terminate() from the parent to proactively just kill the thread.
Either of these options can be triggered by the client sending a particular http request to your server that identifies some sort of ID so the server's main thread can tell which workerThread it should stop.
I would also like this app to support multiple people trying to use it at the same time, and I'm not sure if I need to consider that in the equation as well.
This means you'll have to program your nodejs server such that each one of these client/thread combinations has some sort of ID such that you can associate one with the other and can have more than one pair in operation at once.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
This question is more about looking for an idea, rather than an implementation or technical solution. I'd like to hear how you would solve this kind of problem (or task).
I have an application build with Javascript using React & Meteor. At the moment every time a client does something there is a Meteor Call to our server which will write Data to MongoDB and every other client will notice this change (and will respond in some way). This is working fine atm.
Now i want to add a new feature which allows two clients to communicate with each other (LAN only - atleast in the first version). So as an example: I have a room with 4 clients - A, B, C and D and i want to match two of them, e.g. A & C. This connection should only exists between those two clients and i want to minimize traffic to my server and meteor calls. (My server should not be involved in this communication at all, besides maybe saving some data every few minutes, but all in all it should work without my server) and it should be possible to open up more than one communication, if A & C are working together B & D should be able to do the same, the data which is transmitted - at this time - is JSON.
Further thoughts: A presses a Button in my webapplication which is a React Component. The React Component than establishes a connection to another person who is also looking for a partner (in the case above C) - Some sort of document/page opens up and both can work on the same document in real time or near real time. In worst case: The communication should be able to work without a connection to my Server (or Internet connection in general), but it doesn't have to.
I first thought about using sockets (SocketIO or something along that line), e.g. A creates a server when he wants to work with C and C connects to A, but this comes with some problems in JS
and i am not sure if its really a good way to approach this.
I'd like to hear some other ideas, perhaps im running in a completely wrong direction.
Use the WebRTC API.
Although often associated with real time audio/video communication, it can also be used for peer-to-peer communication with arbitrary data.
As far as I know this is, as of this writing, the only client-side web-native peer-to-peer API available which is widely implemented by major browser vendors.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Which programming language would a designer/developer use in order to "pre-populate" events on a website based on the date the events would happen?
For example: suppose you have a restaurant, and each day you have a different "lunch special" or something. And on the homepage of the website, you've got a div that says "today's lunch special," followed by whatever the special that day is. Suppose you know what the special is going to be for the next 30 days, each day. January 1 - sandwiches. January 2nd - soup. January 3rd - pizza. and so on.
Would there be a way to put all of this information in ahead of time (presumably some kind of database), so that on January 2nd, the website automatically changes to "soup," on January 3rd, it changes to "pizza," etc etc? would it be possible to put the info in ahead of time, and have the site populate the info based on the date? or would you just have to go into the HTML every day, change it, then upload it to the server?
I'm assuming there is a way to do this, but I have no idea what kind of language one would use to do it. Maybe PHP for the data, then JavaScript to call on the data? I'm a bit of a newbie so any advice would be welcome.
There are three fundamental ways to do this:
On the server: In this situation, your server-side code (PHP, Perl, Java, C#, Python, JavaScript running on NodeJS/SilkJS/etc., or almost any other language) responds to the request for the page and builds the HTML on-the-fly; what gets sent to the browser is the complete, pre-filled page. A single HTTP request is made (for the main page; there will presumably be CSS and images and such).
On the client: In this situation, the page that is returned by the URL is static, but then it contains JavaScript code that makes a second request for the data from the server via another URL. Server-side code on that URL runs, returns the data to the client (typically as JSON or XML), and the client-side JavaScript code interprets that data and fills in the page. Note that there's still server-side code involved, but the code actually filling in the page is on the client. Since it's on the client (browser), this'll be JavaScript. At least two HTTP requests are made (one for the main page, one for the data).
On the client, take 2: The main URL is handled by server-side code, but the server-side code returns static HTML (as in #2) but with the data the client would request in #2 embedded in the page. Client-side code reads the embedded data and fills in the page. Again that code would be JavaScript. A single HTTP request is made (other than CSS and such).
#2 seems a bit silly — why make two HTTP requests? — but isn't uncommon for sites with large, complex HTML pages: They serve those large static pages from a CDN (Content Delivery Network, a high-speed, usually static-pages-only way to get data to end users) and allow them to be cached, and the dynamic data from a server that just responds to data requests and doesn't allow caching those responses.
#3 is for the case where you may request updates to the data while viewing the page. So you want the client-side code to have the logic for populating the page, but you want to minimize HTTP requests when the user arrives to start with. So you pre-bake the first set of data into the page, but then periodically request updates, which is why you use client-side code to populate the page.
Above I've said that the client-side code would have to be JavaScript. It has to be JavaScript by the time it reaches the browser, but there are now several languages that "compile" to JavaScript, such as TypeScript, CoffeeScript, and Dart. So if you liked, you could write your code in one of those languages and "compile" it to JavaScript to send to the browser.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What I would like to get some help with dividing a website in pages, similar to how a forum is organized.
What I mean is that for example a thread has at most 10 posts and when you post an 11th, the oldest post will go to Page 2 and continue that way. Whats the best or easiest way to achieve this? Are there several ways of doing that with HTML alone, or html and Javascript, or PHP?
The concept of what you are describing is called pagination.
Pagination in web content
On the Internet, pagination is used for such things as displaying a
limited number of results on search engine results pages, or showing a
limited number of posts when viewing a forum thread. Pagination is
used in some form in almost every web application to divide returned
data and display it on multiple pages. Pagination also includes the
logic of preparing and displaying the links to the various pages.
Pagination can be handled client-side or server-side. Server-side
pagination is more common. Client-side pagination can be used when
there are very few records to be accessed, in which case all records
can be returned, and the client can use JavaScript to view the
separate pages. By using AJAX, hybrid server/client-side pagination
can be used, in which Javascript is used to request the subsequent
page which is loaded and inserted into the Document Object Model via
AJAX.
Server-side pagination is appropriate for large data sets providing
faster initial page load, accessibility for those not running
Javascript, and complex view business logic.
Correctly implementing pagination can be difficult. There are many
different usability questions such as should "previous" and "next"
links be included, how many links to pages should be displayed, and
should there be a link to the first and last pages. Also ability to
define the number of records displayed in a single page is useful.
Also you can read this for comparison of pagination algorithms.
Paging is something you're going to want to do on the server with PHP before you get to HTML. The primary goal of paging is to conserve bandwidth. (You don't want to send 1000 records down to the browser if the user is going to stop reading after the first 10.) There are also performance and usability concerns.
The actual implementation varies wildly depending on your toolset, database technology, application framework, and personal preference.
If you're using MySQL, you'll want to look into OFFSET and LIMIT, which will allow you to select "pages" of data for a query. It may be as simple as adding a couple query string parameters to your URL and passing those on (being careful to clean them of any SQL injection attacks, of course) to your existing query.
I don't know if I can be more specific without having more details about the code you're working with.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
How can I prevent the user running my web page after downlading the page source?
We can't prevent downloading the source code, but can encrypt it.
But it doesn't good enough for me, because the encrypted code can work after downloading.
Thank in advance.
As a general rule, if the code runs on a remote machine it can be manipulated so they can execute it anyway.
You can make this more difficult through code obfuscation or by implementing some sort of DRM, but I would suggest that this will largely be more trouble than it's worth (since it just takes one person to break it and your code is back out).
1) You could, for example, require that some key be downloaded from a site you control before it'll execute, but the recipient might simply sniff their traffic and pass that value to the game themselves.
2) Or you could possibly set up your game to stream each of the levels or some important aspect of it to your game client, but again, there's not a whole lot stopping someone from just reading these aspects and implementing this mechanism themselves.
3) Perhaps you could encrypt these level packages dynamically on the server with a time-based key, but it just takes that one bored programmer with the technical know-how to reverse-engineer what your method is.
4) Another option that comes to mind is requiring some regular polling to a server you control and requiring some sort of response, but again, if your client can predict what this response is supposed to look like, it's easy for someone to rewrite the game to talk to their own program instead of your server.
5) You could also daisy chain a ridiculous number of dependencies of your javascript logic (breaking your own code into a number of dependencies) so it's slightly more difficult for another user to rebuild the required paths on their system. This might be useful to put off a casual user, but I doubt it'd put off a more knowledgeable user.
All in all, I'd suggest that you simply make the game available as is. Various game companies larger than you have attempted to implement DRM measures of their own with disastrous results (when they don't work as advertised) or just plain annoying for the end user.