I have two different Laravel 5.4 apps, a restaurant menu system to recieve and manage orders, and one website from where customer can place their orders. Both apps run on different server(localy), which means, in my (windows)system I can run only one app at a time(localhost:8000). Both are using the same database tables. My question is how can I notify the restaurant menu system when user places an order from the website i.e., adding new row to Orders table in db? I need a notification as well as auto generate new row in the table like here:
Restaurant Menu System . I have tried doing it with JQuery Ajax, but failed as there is nothing to trigger the ajax function in order page. Tried JQuery setInterval() from here but it seems like a very inefficient way and also gives an error of Uncaught SyntaxError: Invalid or unexpected token. I want to be as smooth as Facebook notifications. Is there any package or trick to do it?
The website looks just like any other ecommerce website with a cart and checkout system from where user can pay and place orders. Any leads is appreciated.
You have two options that I can think of.
One is a technique called comet which I believe Facebook uses or at least used at one point. It basically opens an ajax connection with your server and your server will occasionally check to see if there are any changes, in your case new orders, and when there is, will respond to the request appropriately. A very basic version of what that might look like is...
while (true) {
$order = Order::where('new', 1)->first();
if ($order !== null) {
$order->new = 0;
$order->save();
return $order;
}
sleep(5); // However long you want it to sleep for each time it checks
}
When you open up an ajax connection to this, it's just going to wait for the server to respond. When an order is made and the server finally does respond, your ajax function will get a response and you will need to do two things.
Show the order and do whatever other processing you want to do on it
Re-open the connection which will start the waiting process again
The disadvantage to this approach is it's still basically the setInterval approach except you've moved that logic to the server. It is more efficient this way because the biggest issue is it's just a single request instead of many so maybe not a big deal. The advantage is it's really easy.
The second way is a little bit more work I think but it would be even more efficient.
https://laravel.com/docs/5.4/broadcasting
You'd probably have to setup an event on your orders table so whenever anything is created there, it would use broadcasting to reach out to whatever javascript code you have setup to manage that.
Related
Building a web application.
User have access trough their browser to shared resources host on a server, however if UserA is already using Resource1, Resource1 should not be available to UserB until UserA release Resource1 or until a given amount of time.
For this part : I chose to use a MySQL table with a list of tuples (resource,currentuser) and run a cron task to delete expired tuples.
Now I want to be able to notify UserA that UserB wants to access Resource1 and if get not answer from UserA, then UserA lost his lock on Resource1 and then the Resource is then available to UserB.
For this part, I guess I have to use AJAX. I have thought about the following solution :
User's browser make periodic AJAX call (let's say each minute) to prove he is still alive and upon a call, if another User has requested the same resource, he has to challenge a server request in a given amount of time(for example a captcha). If the challenge fails, it means the user is not here anymore (maybe he left his browser opened or the webpage unfocused).
The tricky part is : "he has to challenge a server request in a given amount of time (for example a captcha)". How to do that?
Am I following the best path ?
Yes, what you've outlined is fine. Using ajax is also completely fine, especially if you're simply polling every minute.
For example, let's say you have the following:
setInterval(function() {
$.get('/resource/status', function(response) {
if (response.data.newRequest) {
//This would signal a new request to the resource
}
})
}, 60000)
When handling the new request to access the resource, you could use something like reCaptcha and display that however appropriate (overlay or inline). When you do this, you could also start a timer to determine if it's exceeded the amount of time allocated or not. If it has, then you can do another ajax request and revoke this person's access to the resource, or however you want to handle that.
i would use web sockets to control all the users that need to get the resource.
this way you will know who is connected and using the resource and when he finish using it you can let the next user the resource and so on ,
(this way can tell each user an estimation of how much time it will take him to get the resource and do some progress bar)
I think there're two problems here.
How to notify users that resource becomes available?
Periodic AJAX requests might be okay, but you can also consider long-polling or websockets to get close to notifying waiting users in real time.
How to find out that resource is still used by user?
If you want to catch the moment when human user is not doing anything on page, you can track mouse movement/clicking or keyboard button pressing. If nothing is done for last n minutes, the page might be considered as not active.
If you want to make sure that page is not exploited by automated software, you can ask to fill in captcha once in n minutes when resource is being used.
I'm trying to figure out what is the best way to handle a quite commons situation in medium complex apps using Flux architecture, how to retrieve data from the server when the models that compose the data have dependencies between them. For example:
An shop web app, has the following models:
Carts (the user can have multiple carts)
Vendors
Products
For each of the models there is an Store associated (CartsStore, VendorsStore, ProductsStore).
Assuming there are too many products and vendors to keep them always loaded, my problem comes when I want to show the list of carts.
I have a hierarchy of React.js components:
CartList.jsx
Cart.jsx
CartItem.jsx
The CartList component is the one who retrieves all the data from the Stores and creates the list of Cart components passing the specific dependencies for each of them. (Carts, Vendors, Products)
Now, if I knew beforehand which products and vendors I needed I would just launch all three requests to the server and use waitFor in the Stores to synch the data if needed. The problem is that until I get the carts and I don't know which vendors or products I need to request to the server.
My current solution is to handle this in the CartList component, in getState I get the Carts, Vendors and Products from each of the Stores, and on _onChange I do the whole flow:
This works for now, but there a few things I don't like:
1) The flow seems a bit brittle to me, specially because the component is listening to 3 stores but there is only entry point to trigger "something has changed in the data event", so I'm not able to distinguish what exactly has changed and react properly.
2) When the component is triggering some of the nested dependencies, it cannot create any action, because is in the _onChange method, which is considering as still handling the previous action. Flux doesn't like that and triggers an "Cannot dispatch in the middle of a dispatch.", which means that I cannot trigger any action until the whole process is finished.
3) Because of the only entry point is quite tricky to react to errors.
So, an alternative solution I'm thinking about is to have the "model composition" logic in the call to the API, having a wrapper model (CartList) that contains all 3 models needed, and storing that on a Store, which would only be notified when the whole object is assembled. The problem with that is to react to changes in one of the sub models coming from outside.
Has anyone figured out a nice way to handle data composition situations?
Not sure if it's possible in your application, or the right way, but I had a similar scenario and we ended up doing a pseudo implementation of Relay/GraphQL that basically gives you the whole tree on each request. If there's lots of data, it can be hard, but we just figured out the dependencies etc on the server side, and then returned it in a nice hierarchical format so the React components had everything they needed up to the level where the call came from.
Like I said, depending on details this might not be feasible, but we found it a lot easier to sort out these dependencies server-side with stuff like SQL/Java available rather than, like you mentioned, making lots of async calls and messing with the stores.
At some pages there are some not important queries (products views increments , grab facebook likes) that have to run after the full load page just for improving the performance
Until now I made that kind of jobs with ajax on $( document ).ready() .
How can I use Event or Queues features of laravel for achieving that.
Is possible to pass an object (like an eloquent collection) also?
Thank you.
A queue is a server side processing event, that is meant to occur after the user does something. For example, after the user signs up, the system 'queues' an email, so it can return to the user quickly, and send the email later.
You cannot use Laravel 'queues' for page loading. This is a user-side event that needs to happen immediately.
Your use of ajax to load slow elements after the initial page load is good. There are other ways to optimize page loads (such as reducing database queries, html + css + js compression etc).
Background
I'm working on a web application utilizing AJAX to fetch content/data and what have you - nothing out of the ordinary.
On the server-side certain events can happen that the client-side JavaScript framework needs to be notified about and vice versa. These events are not always related to the users immediate actions. It is not an option to wait for the next page refresh to include them in the document or to stick them in some hidden fields because the user might never submit a form.
Right now it is design in such a way that events to and from the server are riding a long with the users requests. For instance if the user clicks a 'view details' link this would fire a request to the server to fetch some HTML or JSON with details about the clicked item. Along with this request or rather the response, a server-side (invoked) event will return with the content.
Question/issue 1:
I'm unsure how to control the queue of events going to the server. They can ride along with user invoked events, but what if these does not occur, the events will get lost. I imagine having a timer setup up to send these events to the server in the case the user does not perform some action. What do you think?
Question/issue 2:
With regards to the responds, some being requested as HTML some as JSON it is a bit tricky as I would have to somehow wrap al this data for allow for both formalized (and unrelated) events and perhaps HTML content, depending on the request, to return to the client. Any suggestions? anything I should be away about, for instance returning HTML content wrapped in a JSON bundle?
Update:
Do you know of any framework that uses an approach like this, that I can look at for inspiration (that is a framework that wraps events/requests in a package along with data)?
I am tackling a similar problem to yours at the moment. On your first question, I was thinking of implementing some sort of timer on the client side that makes an asycnhronous call for the content on expiry.
On your second question, I normaly just return JSON representing the data I need, and then present it by manipulating the Document model. I prefer to keep things consistent.
As for best practices, I cant say for sure that what I am doing is or complies to any best practice, but it works for our present requirement.
You might want to also consider the performance impact of having multiple clients making asynchrounous calls to your web server at regular intervals.
I am just wondering what general best practice is for saving data in Ajax Forms. In Spree ECommerce for example, every time you change a value in a list of objects (say you change the quantity of a certain Item in an Order), it updates the database with an Ajax call.
Is it better to have the User manually press "Save" or "Update" when they're done editing a form, or if you can (you have setup an ajax alternative), to just automatically save the data every time something changes?
It seems like Stack Overflow Careers saves a "Draft" of your profile every few seconds using some ajax thing.
As such, it seems like there's 3 ways to save data in a form if you have Ajax going:
User presses button, saves all data at once, not good if data is important
Save every time interval
Save every change
What do you recommend?
Good question. I don't think there's a one-size-fits-all best-practice that covers all situations. Generally, the more user-friendly your solution is, the greater the complexity of implementation, the less likely the potential for a proper gracefully degrading solution (unless you have been very, very careful).
Also, there are implications to whichever approach you have opted to go with. For example, autosaving periodically might not be a good idea where substantial data validation is involved. A user might type some stuff in, and get an error message after a few seconds. Instant feedback would be much more beneficial to the user in such a situation, as it is possible that the input which led to the failed validation was, say, a few actions ago, so it might be somewhat confusing to the user.
Saving whenever the user changes something (a keypress, a checkbox selection, etc.) would seem to be the way to go from a usability perspective, but again, it depends on what you are doing and could have negative side-effects. For example, if the user is on a slow connection, he/she might feel that your site is slow or buggy. It would also yield a lot more database queries than the old-school 'click save' method.
I guess an obvious way to get around some of the above caveats would be to incorporate on-the-spot client side validation, but what works in the end might well be down to what your hallway testers say.
Final recommendation: create the old-style 'click save to save' forms and enhance from there, making sure things don't break without javascript (unless you have express permission from a higher authority). Hope that wasn't all nonsense.
It all depends on the situation. If the form is going to change due to user input then you may be better served save/update form on every change. Otherwise wait for an explicit user action.
I can only see trouble on the horizon if you adopt an autosave strategy for a form..
I know this post is old, but I like this simple solution, if the user change som data on your form and try to leave page without saving it, I prompt a remember message
In a global .js:
var validate=false;
window.onbeforeunload = function() { if(validate) return "You made some changes, are you sure you want to leave?"; };
In the form page, (i did it in jquery):
$('input,textarea,select').change(function(){ validate=true; });
$('form').submit(function() { validate=false; });
BR!