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.
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 making a web app using Django.
I'd like events to trigger 'background' tasks that run parallel to the Django application. (by parallel I just mean that they don't impact the speed of the users experience)
Types of tasks I'm talking about
a user logs in and an event is trigged to start populating that users cache in anticipation of future requests based on their use habits.
a user posts some data to the database but that post triggers an api call to another website where the returned data will be parsed, aggregated and used to supplement that users post.
rolling updates of data used in the app through api calls to other websites
aggregating data and running general maintenance tasks.
After a few days of research I'm thinking that I should use twisted to accomplish this. Which has lead me to my question:
Is twisted overkill for what I'm trying to accomplish?
Many of these tasks are far more i/o bound than cpu bound. So I'm thinking asynchronous is best.
Anyone advice would be appreciated.
Thank you
Yes, I think it's overkill.
Rather than fold in a full async framework such as Twisted, with all the technical overhead that brings, you might be better off using a task queue to be able to do what you want as a background process.
When your app needs to do a background task (anything that would otherwise block the request/response cycle), put the task in the queue and let a separate worker process pick things off the queue and deal with them as fast as it can. (You can always add more workers).
Two of the most popular queue libraries for Python/Django are celery and rq. They're especially good with Redis as a backend, but there are other backend options, too.
Personally, I much prefer rq over celery, in terms of its API and its clean setup, but both are used by a lot of people.
And both are definitely easier to get your head around than something like Twisted, IMO.
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 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
I'm building out a RESTful API for an iPhone app.
When a user "checks-in" [Inserts new row into a table] I want to then take data from that insert and call a web service, which would send push notifications based upon that insert.
The only way I can think of doing this is either doing it through a trigger, or having the actual insert method, upon successful insert, call the web service. That seems like a bad idea to me.
Was wondering if you had any thoughts on this or if there was a better approach that I haven't thought of.
Even if it technically could, it's really not a good idea! A trigger should be very lean, and it should definitely not involve a lengthy operation (which a webservice call definitely is)! Rethink your architecture - there should be a better way to do this!
My recommendation would be to separate the task of "noticing" that you need to call the webservice, in your trigger, from the actual execution of that web service call.
Something like:
in your trigger code, insert a "do call the webservice later" into a table (just the INSERT to keep it lean and fast - that's all)
have an asynchronous service (a SQL job, or preferably a Windows NT Service) that makes those calls separately from the actual trigger execution and stores any data retrieved from that web service into the appropriate tables in your database.
A trigger is a very finicky thing - it should always be very quick, very lean - do an INSERT or two at most - and by all means avoid cursors in triggers, or other lengthy operations (like a web service call)
Brent Ozar has a great webcast (presented at SQL PASS) on The Top 10 Developer Mistakes That Don't Scale and triggers are the first thing he puts his focus on! Highly recommended
It depends on the business needs. Usually I would stay away from using triggers for that, as this is a business logic, and should be handled by the BL.
But the answer is Yes to your question - you can do that, just make sure to call the web service asynchronously, so it does not delay the insert while the web service call finishes.
You may also consider using OneWay web service - i.e. fire and forget.
But, as others pointed out - you are always better off not using trigger.
If properly architectured, there should be only one piece of code, which can communicate with the database, i.e. some abstraction of the DAL in only a single service. Hook there to make whatever is needed after an insert.
I would go with a trigger, if there are many different applications which can write in the database with a direct access to the database, not trough a DAL service. Which again is a disaster waiting to happen.
Another situation, in which I may go with a trigger, if I have to deal with internally hosted third party application, i.e. if I have access to the database server itself, but not to the code which writes in the database.
What about a stored procedure? Instead of setting it up on a trigger, call a stored procedure, which will both insert the data, and possibly do something else.
As far as I know, triggers are pretty limited in their scope of what they can do. A stored procedure may have more scope (or maybe not).
In the worst case, you can always build your own "API" page; instead of directly inserting the data, request the API page, which can both insert the data and do the push notification.
Trigger->Queue->SP->XP_XMDShell->BAT->cURL->3rd party web service
I used a trigger to insert a record in a Queue table,
then a Stored procedure using a cursor to pull Queued entries off.
I had no WSDL or access to the 3rd party API developers and an urgent need to complete a prototype, so the Stored Procedure calls XP_CMDShell calling a .bat file with parameters.
The bat file calls cURL which manages the REST/JSON call and response.
It was free, quick and works reliably. Not architecturally pure but got the prototype off the ground.
A good practice is to have that web page make an entry into another table (i will call message_queue ) when the user hits the page.
Then have a windows service / *nix daemon on a server scan the message_queue table and perform the pushes via a web service to the mobile app. You can leverage the power of transaction processing in SQL to manage the queue processing.
The nice thing about this approach is you can start with everything on 1 stand alone server, and even separate the website, database, service/daemon onto different physical servers or server clusters as you scale up.