Azure Redis Cache helps your application become more responsive even as user load increases and leverages the low latency, high-throughput capabilities of the Redis engine. This separate distributed cache layer allows your data tier to scale independently for more efficient use of compute resources in your application layer.
Redis is an open source, BSD licensed, advanced key-value cache and store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets, sorted sets, bitmaps and hyperloglogs. Redis supports a set of atomic operations on these data types.
Microsoft Azure Redis Cache is based on this cache and store. It gives you access to a secure, dedicated Redis cache, managed by Microsoft, providing the best of both worlds: the rich features and ecosystem of Redis, and reliable hosting and monitoring by Microsoft.
You can use Redis from most programming languages used today.
Azure Redis Cache leverages Redis authentication and also supports SSL connections to Redis.
The purpose of this article is to help you decide if Azure Redis is the right technology for your project. The Azure documentation is pretty good to help you get started, but is spread all over the place, so this article focuses on the steps to get started, and gives you a peek into what your code looks like. (If you are like me, you can often tell if the technology is a good fit by seeing code.)
NOTE: Of course, you can use Redis without Azure. For more information on that, see Distributed Caching using Redis Server with .NET/C# Client.
In his talk on Some REST Design Patterns (and Anti-Patterns), Cesare Pautasso explains, “REST architectural style is simple to define, but understanding how to apply it to design concrete REST services in support of SOA can be more complex.”
Several SOA Design Patterns:
- Uniform Contract
- Endpoint Redirection
- Content Negotiation
- Idempotent Capability
In this post, you will learn the design methodology, walk through a step by step scenario where the client and server trade information to perform a set of actions, and you will learn more about the SOA design patterns.
In the previous posts, you learned how to design your RESTful API. In this post, you will learn about the best practices of versioning, analytics, how to set up your API root, what your consumers are expecting for results, why and how filtering should work, and caching.
In the post Designing Your RESTful API Part 1: The Nouns, you learned the importance of resources, request headers, and the request body when you defined your RESTful API. In this post, you will learn about the five or so request verbs and what is send back to the client in the response body and the response status code.
In the font-size property, you’ll know that there are many different measurements to use when defining the size of the font.
- xx-small through xx-large – relative to the default browser font size
- percentages – relative to the surrounding text
- em and ex – relative to the parent element
- pixels – relative to the screen resolution
Web sites reflect the company’s professional image. If your site renders improperly or not at all, your company’s reputation can be tarnished. If your site has browser display problems, visitors and potential customers will leave your site and not look back.
In the post Using Modernizr, Polyfills, YepNope, you learned how you can support browsers that might not have the capabilities that you need. But at some point you may not be able to support really old browsers. At that point, you may just want to recommend the user update. Even for enterprise apps, you will want to remind users to use a current browser rather than have your app fail because your app is expecting something that does not exist.>p>You can use the following code to help your users get up to date browsers. Continue reading
Q is a library that implements the standard and has some extra helpers. Q works in the browser and in node.js.
Q was designed to provide a robust way to provide you ways to write asynchronous code cleanly.
If a function cannot return a value or throw an exception without blocking, it can return a promise instead. A promise is an object that represents the return value or the thrown exception that the function may eventually provide. A promise can also be used as a proxy for a remote object to overcome latency.
You can read the specifications for Q at Promises A+, which aims to clarify “the behavioral clauses of the Promises/A proposal, extending it to cover de facto behaviors and omitting parts that are underspecified or problematic.”
You use deferreds and promises in ways similar to the ways you would use them in jQuery. However, Q has some important features.
You need promises as soon as you do anything that involves an asynchronous API. It also does not take very long before writing promise chains for sequential asynchronous operations becomes second nature.
A Promise is an object that basically represents a process that is or will take place at some point in time, but allows you to register callbacks to it for when the process gets terminated or completed.
Instead of blocking and waiting for the long-running computation to complete, a promise returns an object which represents the promised result.
The value of
this inside a function, effectively depends on the object which called it. The ECMAScript Language Specification says, “The this keyword evaluates to the value of the ThisBinding of the current execution context.”
The use of the “this” keyword inside a function should be familiar to the C++/C# developers among us—it refers to the object through which the method is called ( developers who use Visual Basic should find it familiar, too—it’s called “Me” in Visual Basic).
As you learned in my post on Scope, Namespaces, “use strict”, all variables are accessible from the global scope except variables that are declared within a function using the
var keyword. In this post, we add the idea of closures.
Closures are functions that retain a reference to their free variables.
And we show how you can use closures in building a robust revealing module pattern. Along the way, we explore some other patterns, such as the self-invoking anonymous function. And in the conclusion show how you can use the revealing module pattern to extend existing modules.
When you see Asynchronous Module Definition (AMD), you will see how asynchronous modules build on these concepts.
The work around is to use the revealing module pattern.
I am a huge fan of the revealing module pattern. It keeps your objects encapsulates and was easier to understand for me as a C# guy.
In this lesson, you will learn about prototypes. A prototype is an object from which other objects inherit properties.
Every object has a prototype by default. Since prototypes are themselves objects, every prototype has a prototype too. (There is only one exception, the default object prototype at the top of every prototype chain.)
The purpose of this series is take your knowledge to the next level, for you to add skills that will help you build commercial-quality code.
In this post, you will learn
- Create objects using a constructor and literals.
- How to access property values.
- How methods operate on an object.
- What an instance is.