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!
Related
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 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.
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.
we are planning a REST api for our application and are trying to make
a decision on if we should implement separate controllers for the REST
functionality or not.
We could use the withFormat{} in our current controllers but
separating the REST functionality in different controllers feels
somewhat cleaner..
In that way we can build our API seperate from the current controllers
and we could even take the REST controllers into another application
etc.
Any thoughts on this subject? Any real world experience in what the
best practice would be?
We recently faced the same decision and we decided to go for separate controllers for the REST API.
Advantages of separate controllers include cleaner/clearer controller actions and the possibility to support different versions of the REST API later on.
We also would like to keep the option to host the REST API on separate server instances open. These servers would use exactly the same .war, but with different configuration settings for the feature toggles.
A disadvantage of separate controllers might be the DRYness of the controller code. Although this should be limited, since IMHO you should keep the controllers as thin as possible and extract shared logic to Grails services or helper classes.
I will work with grails soon, but so far i have little experience with it. But in web apps i worked, we always left webservices separated from the controller code. We also separated REST from SOAP. Common methods for them would be in service layer. It, indeed, felt cleaner. We didn't had to insert a lot of ifs in the methods
I would, for a given resource, use one controller that interfaces with a service layer based on context (the media type received or requested -- SOAP, JSON, XML, etc.) This way, you have a truly uniform resource identifier that can accept and return various media types and the controller won't need to know anything but what method the user wants to perform on what resource and what media type is involved.
For instance, maybe the service layer returns objects that have methods such as 'toXml', 'toSoap', or 'toJson'. Then you can just ask the service layer to do whatever and use a switch statement on the requested media type to either return the requested information, or by default throw a 406 Not Acceptable status code. For unsafe or idempotent transactions, the object may have constructor or factory methods for a given media type and then you just ask the service layer to do whatever with that object.
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