At the moment, you'll need to use service workers and offline application caching to make sure every browser works with your offline website, as some browsers do not support service workers as of yet. (Edge and Safari).
My question is how do the browsers react when they use both service workers and application caching?
Does the browser use service workers over application cache if both are in use?
Or do they work side-by-side, causing possible conflicts?
If there's an existing Application Cache associated with a web page client at the time that a service worker activates, that association is dropped, and the service worker will be the only thing consulted moving forward.
That behavior is documented in the service worker specification, so it should be consistent across all browsers that support service workers:
For each service worker client client whose creation URL matches
registration’s scope url:
If client is a window client, unassociate client’s responsible
document from its application cache, if it has one.
Else if client is
a shared worker client, unassociate client’s global object from its
application cache, if it has one.
Note: Resources will now use the
service worker registration instead of the existing application cache.
Related
In progressive web application (PWA), it is said to make a web app fully PWA-compliant, I need to have a manifest file.
(1) But what happens if my web app registers a service worker but I didn't define a manifest file? Any typical examples?
(2) Is it correct that service worker is a technique used in PWA, but is not necessarily exclusive to PWAs (i.e. non-PWA web apps could have service workers as well)?
PWAs are Progressive Web Apps which means you progressively enhance your site with the features you need.
If you want your site to be installable you'll need a web manifest.
If you want your site to cache resources on the device or work offline you'll need a service worker.
Those pieces work independently but complementary and you can pick and choose them at your whim.
Answering to the first part:
It won't prompt user for add to home screen as this is one of the
requirements for PWA, but PWA isn't limited to it. So if you have
Service worker registered, you will get all the other functionalities of PWA other than Add to home Screen.
In precise, loading a
manifest files tell browser that our website is an application
Answer to your other questions. Can't see any other use of the
Service Worker other than PWA, as Service Worker is a proxy, sits between the user and N/W request and decides very cleverly if the internet is available or not or whether the SW should intercept the
n/w request or not. So, soon you register SW it automatically counts towards PWA.
Major components of PWA are:
Adding a Web App Manifest
Adding a Service Worker (SW)
Caching and serving Static assets
Serving Cached Contents
Dynamic Caching
Out of these 5 steps, you can achieve 2,3,4,5 with the help of SW. Adding a web app manifest is more like an intimation and giving your website a more native look/feel regardless of desktop or mobile device. cheers :)
I am working on an ASP.NET MVC 5 application (based on nopCommerce). I want to use MassTransit to communicate with another application that is used for inventory management, billing, etc. It would be easier if I could add receive endpoints directly into the web application and not have to create a Windows service for that. But the MassTransit documentation says it is not recommended and there is no explanation as to why that is.
MassTransit in a web application
Configuring a bus in a web site is typically done to publish events,
send commands, as well as engage in request/response conversations.
Hosting receive endpoints and persistent consumers is not recommended
(use a service as shown above).
Does anyone know the reasoning behind it? Is it not safe to add receive endpoints in a web application? Will they not work properly?
Hosting endpoints in a web application is not recommended because web applications often restart for various reasons. These reasons are typically outside the control of the application itself.
While using a standalone Windows service is highly recommended, as long as the bus is properly started and stopped using the Application_Start and Application_End methods, it can be okay if you have no other options available.
I currently have my web application hosted on AWS, and I use two ELB instances, one to load balance the frontend requests to the app servers, and a second to load balance the backend requests FROM the app servers TO the API servers, like so (sorry for the crappy ascii diagram):
/-->APP1--\ /-->API1
User-->ELB1 ELB2
\-->APP2--/ \-->API2
In other words, the API requests that the APP servers make are load balanced evenly across the two backend API servers.
But, because I'm caching responses on the API servers, and use a cache invalidation mechanism which is NOT shared between the API servers, I'd like for a user's session to be stuck to one backend API server.
I already have the user's session stuck to one APP server, using the normal ELB load balancer-generated cookie stickiness, but is there any way to get the backend ELB stuck to a session? Of course, those requests are not coming from a browser, so there's nothing to manage cookies, and it seems that ELB's can only manage stickiness with cookies. Can I emulate the necessary cookies my backend requests?
To close off this question, yes, this is fairly easy to achieve by simply capturing the 'Set-Cookie' response header from the ELB, and then passing the cookie back in subsequent requests. But, see my caveat below.
I don't believe it would be possible to achieve stickiness between your App servers and API servers without doing a whole load of messy work. I could be wrong, and am very open to correction but I don't believe there is an easy solution, unless the language you're using for your App Server logic has something to offer.
Regardless, the best solution here would be to decouple your App Servers and your Cache. It would make more sense to have a single cache shared between the API servers that is served by separate servers. This will increase your infrastructure's fault tolerance and give you better quality data in your cache (especially as you scale up). You could use the ElastiCache service to do this for you and avoid any heavy lifting.
I'm designing an API to enable remote clients to execute PowerShell scripts against a remote server.
To execute the commands effectively, the application needs to create a unique runspace for the remote client (so it can initialise the runspace with an appropriate host and command set for that client). Every time the client makes a request, the API will need to ensure the request is executed within the correct runspace.
An (over-simplified) view of the flow might look like this:
Client connects to Web API, POSTs credentials for the backend application
Web API passes these credentials through to the backend app, which uses them to create a RunSpace uniquely configured for that client
Web API and app "agree" on a linked session-runspace ID
Web API either informs client of session-runspace ID or holds it in memory
Client makes request: e.g. "GET http://myapiserver/api/backup-status/"
Web API passes request through to backend app function
Backend app returns results: e.g. "JSON {this is the current status of backup for user/client x}"
Web API passes these results through to remote client
Either timeout or logout request ends 'session' and RunSpace is disposed
(In reality, the PowerShell App might just be a custom controller/model within the Web API, or it could be an IIS snap-in or similar - I'm open to design suggestions here...).
My concern is, in order to create a unique RunSpace for each remote client, I need to give that client a unique "session" ID so the API can pass requests through to the app correctly. This feels like I'm breaking the stateless rule.
In truth, the API is still stateless, just the back-end app is not, but it does need to create a session (RunSpace) for each client and then dispose of the RunSpace after a timeout/end-session request.
QUESTIONS
Should I hack into the Authentication mechanism in ASP.NET MVC to spin-up the RunSpace?
Should I admit defeat and just hack up a session variable?
Is there a better SOA that I should consider? (Web API feels very neat and tidy for this though - particularly if I want to have web, mobile and what-have-you clients)
This feels like I'm breaking the stateless rule.
Your application is stateful - no way around it. You have to maintain a process for each client and the process has to run on one box and client always connecting to the same box. So if you have a single server, no problem. If you have multiple, you have to use sticky session so client always comes back to the same server (load balancers could do that for you).
Should I hack into the Authentication mechanism in ASP.NET MVC to
spin-up the RunSpace?
If you need authentication.
Should I admit defeat and just hack up a session variable?
No variable, just use plain in-memory session. In case more than 1 server, use sticky session as explained above.
Is there a better SOA that I should consider? (Web API feels very neat
and tidy for this though - particularly if I want to have web, mobile
and what-have-you clients)
SOA does not come into this. You have a single service.
I have a WCF service method which takes more than two hours to execute (runs some reports). how can I make sure that it doesn't timeout regardless of the time it takes? I think there are many timeout settings in WCF config, I am not sure which one is relevant for me. for ASMX webservices, there was an option to specify infinite timeout setting, is there a similar one for WCF?. also do I need to alter any IIS settings for this (WCF servcie is hosted in IIS), like recycling of worker processes, idle timeouts etc?
This is an abuse of web services. Don't do this.
Instead, have the web service kick off the long-running operation, running in a separate process. If the clients need to know when the reports are done, then have the "separate process" keep track of the report creation and have it note when the reports are finished. The client can call a web service to check that status.
You really don't want to be depending on an HTTP connection remaining open for hours. It's a network. Things happen on networks. Bad things.
Have you considered using callbacks? Your client sends a request and then waits for a notification from the server for when it is done? This would probably require a change in the client, but in that way, your service can "rattle the chain" and tell the client when the report is finished.
help: http://idunno.org/archive/2008/05/29/wcf-callbacks-a-beginners-guide.aspx
WCF timeouts:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/84551e45-19a2-4d0d-bcc0-516a4041943d/
You should also consider the timeouts on the client side, as well. (binding.OpenTimeout, ReceiveTimeout, CloseTimeout etc.)
Another option would be to host the WCF in a Windows Service, which could simplify your situation, as it removes IIS from the equation:
http://msdn.microsoft.com/en-us/library/ms733069.aspx
Or, what about using a one way WCF call? That way, the call will return to the client ASAP after sending the request.
Need sample fire and forget async call to WCF service
Consider creating a WCF workflow service (using WF) instead. These are specifically designed to handle long-running processes, especially if you use persistence.