What are the core differences between service worker and AppCache. What are the pros and cons of each and when to prefer one over another .
The primary difference is that AppCache is a high-level, declarative API, with which you specify the set of resources you'd like the browser to cache; whereas Service Worker is a low-level, imperative, event-driven API with which you write a script that can intercept fetch events and cache their responses along with doing other things (like displaying push notifications).
The pros and cons are largely a function of API design: theoretically, AppCache is easier to use, while having more limited use cases; whereas Service Worker is harder to use, but is more flexible.
Nevertheless, AppCache is considered hard to use in practice due to poor design (see Application Cache Is A Douchebag for a list of design issues). And it has been deprecated, so it is being removed from browsers (per Using the application cache).
Thus the only reason to prefer AppCache is to offline an app on browsers that don't yet support Service Worker, as Kenneth Ormandy recommends in Don’t Wait for ServiceWorker: Adding Offline Support with One-Line.
Compare Can I use Service Workers? to Can I use Offline web applications? to see the differences in browser support. But note that browsers that support Service Worker, like Chrome and Firefox, are removing support for AppCache, so you'll need to implement both to offline your app across all browsers that support either standard.
In addition of what Myk Melez said, One of the main benefits of Service Workers against Application Cache is that Application Cache only works when user is disconnected from the network, so you can not manage situations of:
1- "slow network" - Your connection signal is strong, however some external entities (server, routes, etc) are delaying the transmission to your specific application.
2- "Lie-fi" (your phone shows is connected to a wi-fi or a cell network with low signal) so it seems to be connected when actually is not.
Service Workers is like a middle ware giving you control over the requests the browser is making, you can actually intercept the request and respond wherever you want, no matter you are connected or not. So you can implement "offline first" principle.
Related
From what I'm seeing you can even cache a web page. According to this documentation: https://www.mnot.net/cache_docs/#BROWSER, representation can be cached in browser cache. I see the that even serviceworker does the exact same thing(html, css and javascript files). What is the purpose of service worker?
A service worker is not just a script to cache a web page or scripts, it is actually a script that handles your background operations separately from the webpage, functionalities include but not limited to : caching resources, background sync, push notifications... Their main advantage is that they can be woke up, even if the browser is closed and the website isnt open.
it would be helpful to check here for basics.
A service worker is a specific type of JS Script, which runs in the background of the user’s browser. It acts like a proxy server exists between your app, the browser and the network. Among other things, service workers allow apps to continue functioning offline in case the user loses internet connection.
Improve performance of the website:
Service worker helps the website to load offline. Unlike AppCache API, it is having more control over the browser cache. Returning visitors can fetch the website instantly from the browser cache and get a smoother experience so that they’ll keep coming back.
How Do Service Workers Work?
Service worker scripts is independent and have their own life cycle:
The script first registered and then installed by the browser. After that it start caching static assets right away. If any errors occur, then installation will fail, and you must try again.
For successful installation, the service worker will activate and gain control over all pages under its scope. Active service worker alternate between two states: either it will handle fetch and message events, or it will terminate to save memory.
Service Worker Caching:
Service worker caching is much more manageable. It always checks network status whether it is online or offline and fetch or terminate the resource files accordingly. This means the site can work when there is no network, offline, or poor network connectivity, low bars or false cellular connectivity.
Supported Browsers
Browser options are growing. Service workers are supported by Chrome, Firefox and Opera. Microsoft Edge is now showing public support. Even Safari has dropped hints of future development.
Restrictions and Security:
• Service Worker can’t access the window object. That’s why it does not have any threat for spreading viruses.
• Require HTTPS. This ensures a level of security to allow the service worker to do the things it is designed to do.
• Only Asynchronous. This means synchronous APIs like XHR and local Storage are not available to a service worker.
Conclusions:
Service workers transform your website to an instant loading powerhouse. Apart from improving web performance, they can be used to implement push notifications to keep users engaged with mobile apps. Future applications for service workers might include things like Geofencing and Periodic sync.
Visit my video blog for more details: https://www.youtube.com/watch?v=nKHDUUvrkeg
I'm looking at the Apple networking guidelines that suggest that the user should try to work with the highest level of abstraction possible when dealing with networking.
I'm working on a client-server app, where the server is master, and an iOS device is slave. These communicate over HTTP, establishing a connection that lives for the lifetime of the app's usage session. The app and the server synchronize assets over this connection.
My question is - what level of abstraction is appropriate for implementing bi-directional sync over HTTP? Is it sockets, NSURLConnection, some AFNetworking subclass, input/output streams?
There are a lot of possible good answers to this. I think all I can do is offer one pattern which has worked well for me but it may not apply to your needs and use cases. To restate my comment above "whatever you do will be a tradeoff between responsiveness, power consumption, data consistency, and implementation cost."
The level of abstraction I aim for is a set of service objects which expose an interface in terms of the application's domain models. The rest of the app, primarily objects in the controller layer, should be able to communicate with these services by passing models to methods (e.g. "fetchUserWithId:userId" or "createUser:user") and without any awareness of the urls, paths, or HTTP verbs involved at the network layer.
Those service objects can map domain model operations into paths, HTTP verbs, and possibly request bodies or headers. In most cases I find that the services themselves can then share a lower level service which accepts those values and constructs the actual HTTP request. This provides a single location to configure host names, set global headers, and manage a request queue via NSURLRequest, NSURLSession, AFNetworking, or whatever library you prefer.
I'll include completion blocks on my service object methods so that controllers can be notified of success or failure but try not to use those blocks to pass models back up to the controller layer. Instead I prefer to have controllers monitor Core Data or some other persistence layer and react to changes. That way controllers remain flexible and respond to any update in the models they are concerned with and do not assume that they are aware of all possible sources of changes to those models.
So far none of this addresses how you should check for remote changes to your models. The best option may be to design a system which does not need to do so. What if your client obtained a set of recent changes only when posting data to the server, could it still provide a good user experience? Could the server use push notifications to occasionally notify clients of updates?
If you must check for changes sockets or long polling are usually more responsive than short polling but it may be hard for roaming mobile clients to keep those connections open. All of these approaches also tend to keep the client's radios active and consume lots of power in the process.
Without knowing more about the problem I'd default to short polling but try to design interactions which allow this to be as infrequent as possible (e.g. one check when the app resumes). I also use HTTP features (etags, if-modified-since, or custom content ranges) to limit the size of responses when there are no changes. If you have a good service layer managing network requests that also gives you a good place to introduce rate limiting. Allowing controllers to express interest to fetching up to date information but deferring to the services to throttle or batch requests based on what the rest of the app is doing (e.g. don't repeat the same request if those models were updated recently unless the user deliberately triggered the action).
I'd like to decouple a number of business objects that my website is using to support actions of the users.
My website is a SaaS/B2B site and I do not anticiapte to have a need for "mega scale". My primary issue is a need to decouple business objects from each other, and perform occasional longer-running operations asynchronously - outside of execution of threads that handle user traffic.
Having said that, I really do not want to have a separate set of servers that process my messages, and would prefer for web servers to just host MassTransit or other Bus software) internaly in memory. Assured message delivery (at this point) is also not yet my most important concenrn. I plan to "outsorce" a number of supporting business actions to the bus so that they do not pollute my main business services/objects.
Is this possible? Do I need Loopback for now as a transport or do I need full RabbitMq? Will RabbitMQ require me to install yet another set of servers to host it?
TIA
Loopback is just for testing. Installing RMQ is the right path. You don't NEED different servers for it, but would suggest it. If you off load work to a bus, you don't really want that contending with resources for the website. Given that, you can run RMQ locally without any issue. It message volume is low, so is resource usage in RMQ. When you reacher higher volumes, IO can be a problem with RabbitMQ (or any MQ).
I'm designing some OSX/iOS apps that I'd like to share a resource to be hosted on a webserver. I would like to have some sort of web app or script that can store a list of subscribers, and to notify them when the resource is updated. (The obvious goal here is to avoid having every app poll the webserver for updates.)
The only trick here is that I'd like a significant number of clients (say, a dozen) to be subscribed for updates on a 24/7 basis. I'm not sure if it's a good idea for all of the clients to maintain a live connection... I imagine that many web service providers will be happy about their webserver maintaining a dozen persistent connections (especially if they're virtually always idle).
(Edit) I looked into the Apple Push Network Service (APNs), but it's not the right solution for my problem. APNs requires an Entrust SSL Certificate, and some heavy interaction with the Apple Push Network service. My project is much simpler and more lightweight: I just need a script that says, "Upon receiving data from Device A, push it out to Devices B/C/D" (presuming those devices are somehow accessible... either through a persistent connection or some other technique).
What's the absolute simplest way of providing this mechanism?
The "simplest way" probably means different things to different people. If you're not a fan of locking yourself into third party services then there's a veritable plethora of app frameworks and open source tools you could use to build something yourself. But this is hardly 'simple' if web app development isn't your strong point.
There are several 'off the shelf' services available to do real-time messaging on iOS: bear in mind I'm just listing the ones I know from memory, there are other alternatives. Pusher and PubNub both offer real-time messaging services for mobile apps, along with ready to go SDKs. You can interface with them to send messages bi-directionally via sockets (so similar to how APNS works, but with considerable more control).
You could use these services with your own device/user management system, or you could use a 'backend as a service' provider such as Parse or Stackmob - you may not need this step, it depends how complex your intended app/integration is.
XMPPFramework has a publish–subscribe module (for XEP-0060) which works with most XMPP servers. I've even adapted it to work with Chat Server which comes with Snow Leopard.
If you already have an XMPP server this might be worth doing; otherwise it's kind of a heavyweight solution.
I am putting together a REST API and as I'm unsure how it will scale or what the demand for it will be, I'd like to be able to rate limit uses of it as well as to be able to temporarily refuse requests when the box is over capacity or if there is some kind of slashdotted scenario.
I'd also like to be able to gracefully bring the service down temporarily (while giving clients results that indicate the main service is offline for a bit) when/if I need to scale the service by adding more capacity.
Are there any best practices for this kind of thing? Implementation is Rails with mysql.
This is all done with outer webserver, which listens to the world (i recommend nginx or lighttpd).
Regarding rate limits, nginx is able to limit, i.e. 50 req/minute per each IP, all over get 503 page, which you can customize.
Regarding expected temporary down, in rails world this is done via special maintainance.html page. There is some kind of automation that creates or symlinks that file when rails app servers go down. I'd recommend relying not on file presence, but on actual availability of app server.
But really you are able to start/stop services without losing any connections at all. I.e. you can run separate instance of app server on different UNIX socket/IP port and have balancer (nginx/lighty/haproxy) use that new instance too. Then you shut down old instance and all clients are served with only new one. No connection lost. Of course this scenario is not always possible, depends on type of change you introduced in new version.
haproxy is a balancer-only solution. It can extremely efficiently balance requests to app servers in your farm.
For quite big service you end-up with something like:
api.domain resolving to round-robin N balancers
each balancer proxies requests to M webservers for static and P app servers for dynamic content. Oh well your REST API don't have static files, does it?
For quite small service (under 2K rps) all balancing is done inside one-two webservers.
Good answers already - if you don't want to implement the limiter yourself, there are also solutions like 3scale (http://www.3scale.net) which does rate limiting, analytics etc. for APIs. It works using a plugin (see here for the ruby api plugin) which hooks into the 3scale architecture. You can also use it via varnish and have varnish act as a rate limiting proxy.
I'd recommend implementing the rate limits outside of your application since otherwise the high traffic will still have the effect of killing your app. One good solution is to implement it as part of your apache proxy, with something like mod_evasive