I have setup a very basic first application where I can add and remove names from a list, which are then added/removed from a database using a RESTful API, using Ember-Data with the default REST Adapter.
I'd like to implement some form of polling/long-polling so my interface remains up-to-date.
So for example, lets say I open my 'list' in two tabs, delete a few names in one tab - I'd like for the changes to then (eventually) show up in the other tab.
How can this be done easily with Ember?
What you want to do is really a job for WebSockets, which would allow you to push changes to your models from the server to the Ember app whenever they happen. This type of approach can easily take care of keeping thing in sync between tabs. I would recommend checking out Socket.io, which has a great client-side JS library and many server side libraries. By default it will try to use WebSockets, which are better than long-polling, but will degrade to long-polling if it needs to. This might force you to change a bunch of your application set-up, but I would consider this the "right" way to go.
Related
I mainly have two questions. I haven't read this anywhere but, I am wondering whether or not it is a good idea to make it so that all the data that is going in and out of all apps in your project solely depended on REST API calls.
So that if you, for instance, want to register a new user. Gather the data from a front-end, with no back-end work, and just send this data as a REST call to you "registration-app" where all validation and back-end work is done.
I find this method effective when working in big teams as it makes dependencies even more decoupled, as well as making each part of the project more separated and "clear". My question is, therefore, is this a viable way of developing? Are there any security or performance issues with this? And where can I read more?
Thanks
Max
It is perfectly viable, I think like most choices it has pros and cons. Here are some of them:
Pros:
Decoupling - Clients depend on the abstraction (i.e. the REST API) rather than the concretion (i.e. the website), so you gain clarity of design, ability to test outside of the browser, and you can do things like substitute the REST API with different implementations e.g. with a mock service for development/testing purposes. If, in addition, the REST API is implemented by a separate back-end service, then you can update it independently, and potentially scale it independently.
Responsive user-interface - The REST requests can avoid HTML page reloads and improve UX. Also you can make asynchronous REST calls.
Reduced payload - Typically the REST calls would return less data than the HTML sent in a page refresh.
Cons:
More complex client - You require more complex javascript and especially so if you employ asynchronous REST calls.
Dynamic page building - Typically the result of a REST call might require some change in the UI, you are forced to do this dynamically in javascript which also adds complication. So your UI logic is split between your HTML page templates and your javascript UI updates. This makes the UI hard to reason about.
Timeouts - You need to handle timeouts and errors in javascript
Sessions - You need some means of authenticating users and maintaining sessions. REST services should not maintain client-session state themselves, so you either need to store state in the client, or explicitly add state as a new REST resource with its own distinct URI(s).
Forced page reload - If you use this mechanism to avoid page reloads, then users potentially might have the page open for a significant period of time, and you might need some kind of mechanism to cause them to reload it.
I'm now working on Ember CLI application. Now checking the strategy for implementing Authentication.
Now, I plan to create Auth.js, which would maintain the login state and can perform actions.
For example, in Balanced-dashboard, they are using "Namespace", but Travis-CI put it in Util folder.
I also feel like Ember.Service is appropriate for putting Auth.js.
It seems both Namespace and Service are kind of Alias of Ember Object.
So, I'm wondering which of them to choose.
What kind of rule I should apply?
I actually just answered a similar question there. Long story short: don't waste your time and use ember-simple-auth, you will save hours of work :) It is a very flexible library that can handle different authentication/authorization mechanisms in parallel and across different tabs of the browser.
Otherwise yes, Ember services are the way to go!
I was wondering what is the best way to implement certain features that don't require templates. IE My application template can have multiple outlets, one of them being a notification service, and it would be constantly checking for new notifications and so on.
However, lets say there is a service for if someone logs into the app from a different browser, it automatically logs you out from the previous one. Basically the ember app would constantly have to be checking for these events to be happening on the server. But what if I had a lot of similar services/tasks that constantly work in the background of the client. How would I implement something like that?
Should it all be in one parent resource/route (maybe the application route), constantly (reloading the model) getting data from the server, waiting for the server to tell the client to log out or what not. Or would it be able to have something like a BackgroundService, that would not be a route, but would basically mimic one by constantly going thru the store to adapter to server to get data.
I know I could simply put a recursive function in the application route's model/aftermodel/beforemodel to be doing this, but I'm not sure if its proper and safe. I also don't know the app would react if this would be a simple ajax call, instead of using ember data. I know ember data does not have to be used, but I'm just wondering how proper/safe this is.
Good question, In the app I'm developing I have also several tasks which just run in the background. I mostly use Ember initializers for this, because you can create as many initializers as you want and separate all background tasks nicely (with the use of an initializer you can even add an order to the tasks in which they need to be started). I'm using ajax requests, but it should also be doable with ember-data. Although this depends off course on what you want to do with the task.
Keep in mind though that when having a lot of background tasks it might slow down your app a bit (because of all the traffic to and from the server). So don't refresh too often.
I have a django backend set up for user-logins and user-management, along with my entire set of templates which are used by visitors to the site to display html files. However, I am trying to add real-time functionality to my site and I found a perfect library within Node.Js that allows two users to type in a text box and have the text appear on both their screens. Is it possible to merge the two backends?
It's absolutely possible (and sometimes extremely useful) to run multiple back-ends for different purposes. However it opens up a few cans of worms, depending on what kind of rigour your system is expected to have, who's in your team, etc:
State. You'll want session state to be shared between different app servers. The easiest way to do this is to store external session state in a framework-agnostic way. I'd suggest JSON objects in a key/value store and you'll probably benefit from JSON schema.
Domains/routing. You'll need your login cookie to be available to both app servers, which means either a single domain routed by Apache/Nginx or separate subdomains routed via DNS. I'd suggest separate subdomains for the following reason
Websockets. I may be out of date, but to my knowledge neither Apache nor Nginx support proxying of websockets, which means if you want to use that you'll sacrifice the flexibility of using an http server as a app proxy and instead expose Node directly via a subdomain.
Non-specified requirements. Things like monitoring, logging, error notification, build systems, testing, continuous integration/deployment, documentation, etc. all need to be extended to support a new type of component
Skills. You'll have to pay in time or money for the skill-sets required to manage a more complex application architecture
So, my advice would be to think very carefully about whether you need this. There can be a lot of time and thought involved.
Update: There are actually companies springing around who specialise in adding real-time to existing sites. I'm not going to name any names, but if you look for 'real-time' on the add-on marketplace for hosting platforms (e.g. Heroku) then you'll find them.
Update 2: Nginx now has support for Websockets
You can't merge them. You can send messages from Django to Node.Js through some queue system like Reddis.
If you really want to use two backends, you could use a database that is supported by both backends.
Though I would not recommended it.
I need to design and implement a Java web application that can be used by multiple users at the same time. The data that is handled by this application is going to be huge and may take about 5 minutes for a page to display the results(database records).
I had designed this application using HTML, Servlets and JSP. But when two users would try to get the records, only one user was able to view the results while the other faced an error.
I always thought a web application would take care of handling multiple users but this is not the case.
Any insights on this would be highly appreciated.
Thanks.
I always thought a web application would take care of handling multiple users but this is not the case.
They do if they're written correctly. Obviously yours is not. That's all we can tell you unless you give more information, most importantly details of the error shown to the second user.
One possibility is that everything is OK on the web layer but your DB access for the first user causes an exclusive lock so that the second user cannot access the data at the same time. This could be fixed by using non-exclusive read locks. How to do that depends mainly on what DB you're using.
Getting concurrency right requires you to choose the correct tools and use them correctly. It doesn't just happen magically because it's a web app.
What are are using to develop this web-application? If you are developing it in your own way from the start I must say you are trying to re-invent the same wheel which has been already created and enhanced by very solid frameworks.
I suggest you analyze your requirements thoroughly and study some available frameworks. Let them handle the things like multi threading and other aspects in the best possible manner.
Handling multiple request at a time is a container work and as an application developer we have to concentrate how we are handling and processing those requret being forwarded by the container.
I must suggest you to get some insight how web-application work and how request -response cycle happens