A fluent API can be incredibly helpful when sharing your application with other developers.
Fluent methods are a hot design idea and they can improve the readability of your code. However, they only make sense in specific scenarios.
A fluent interface (as first coined by Eric Evans and Martin Fowler) is a method for constructing object oriented APIs, where the readability of the source code is close to that of ordinary written prose.
A fluent interface is normally implemented by using method cascading (concretely method chaining) to relay the instruction context of a subsequent call (but a fluent interface entails more than just method chaining ). Generally, the context is
- defined through the return value of a called method
- self-referential, where the new context is equivalent to the last context
- terminated through the return of a void context.
— From Fluent Interface
Azure Content Delivery Network (CDN) is designed to send audio, video, applications, images, and other files faster and more reliably to customers using servers that are closest to each user. If you want to put binary files and blobs closer to your user, then CDN can be the right solution.
The CDN caches publicly available objects at strategically placed locations to provide maximum bandwidth for delivering content to users.
Essentially, when a user wants some content, the first user gets the data from the source server. When you use a CDN, that data is then cached at a site near the user. So subsequent users can get the data from the cache instead of going all the way back to the source server. For example, if a picture stored in a blob is in a European data center in Azure, a user in Portland Oregon would be able to access the file from a server set up in Seattle, making your image load much faster.
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.
Microsoft Azure Cache is a family of distributed, in-memory, scalable solutions that enable you to build highly scalable and responsive applications by providing super-fast access to your data. But what do you choose?
This post provides you with an overview of the options you have when you are considering caching technologies.
Microsoft Azure Cache is available in the following offerings.
Microsoft offers a strong recommended choice for these caches. “Microsoft recommends all new developments use Azure Redis Cache.”
That said, this post discusses each to give you a quick overview. This article also introduces you to one other cache.
Here’s the short answer:
- Use Azure Redis Cache when you want to cache string, hashes, .NET classes, data.
- Use CDN when you want to cache audio, video, applications, images, and other files.
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.
Everything is a resource in REST. As you learned in Choosing Between RESTful Web Service, SOAP, Representational State Transfer (REST) is an architecture style or design pattern for creating web services which allow anything connected to a network to something else on the network using Hypertext Transfer Protocol (HTTP).
In this post, you will learn the how to define your resource identifier. In the following post, you will learn how to use the HTTP verbs and response codes. And along the way you will learn many of the principles of a good RESTful API.
Let me second what As Thomas Hunter II writes:
The easier your API is to consume, the more people that will consume it.
Representational State Transfer (REST) is an architecture style or design pattern for creating web services which allow anything connected to a network to something else on the network using Hypertext Transfer Protocol (HTTP).
Typically we think of a RESTful Web Service as one that will get and set data. It works a lot the same way as a web page, but your user doesn’t see the data until it’s time to be displayed.
REST principles are based on the same underlying principles that govern the Web. Those principles are:
- User agents interact with resources, and resources are anything that can be named and represented. Each resource can be addressed via a unique Uniform Resource Identifier (URI).
- Interaction with resources (located through their unique URIs) is accomplished using a uniform interface of the HTTP standard verbs (GET, POST, PUT, and DELETE). Also important in the interaction is the declaration of the resource’s media type, which is designated using the HTTP Content-Type header. (XHTML, XML, JPG, PNG, and JSON are some well-known media types.)
- Resources are self-descriptive. All the information necessary to process a request on a resource is contained inside the request itself (which allows services to be stateless).
- Resources contain links to other resources (hyper-media).
Or your application may want to be “cloud ready” from the beginning. The vision may begin with a set of servers, each doing a specific task, each that can be scalable to meet demand, provide reliability. As soon as you take that second step, it’s time to look to well known practices.
Microsoft’s Patterns and Practices team has put together architectural guidance to help you design your cloud applications, Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications. Each pattern is provided in a common format that describes the context and problem, the solution, issues and considerations for applying the pattern, and an example based on Azure.
It also discusses the benefits and considerations for each pattern. Most of the patterns have code samples or snippets that show how to implement the patterns using the features of Microsoft Azure.
Although the guidance helps you adopt Azure, the patterns are relevant to all kinds of distributed systems, whether or not they are hosted on Azure or on other cloud platforms.
Big changes are coming to the .NET platform that affect your development wherever you use .NET. The direction helps you develop applications (Web, Azure, Phone, Desktop. Windows Store, Linux, MacOS, iOs and Android) easier. So if you are going horizontal and targeting more than one variation of Windows, then this is for you.
For developers and architects, it provides keys to a new way to looking at how your code should be written. The new .NET implements the kinds of features we face every day. And the solutions are evolving from vertical solutions where each problem was a subset of some other bigger problem. Rather it becomes a set of contracts, where dependencies are clearly defined, where the contract can be implemented in different ways to meet specific needs.
Migrating the .NET base is no small task. Yet, the Microsoft teams have taken on the challenge to make it easier to build applications across platforms — and not just Microsoft platforms.
The new direction includes:
- Merging APIs into contracts to allow the targeting of multiple verticals
- No longer have different versions of .NET Framework
- .NET Core is a modular development stack that is the foundation of all future .NET platforms
- Combine unified Base Class Library
- Open Sourcing more of .NET. You’ll get .NET via NuGet, with source on GitHub.
This post boils down what these changes mean to developers and architects. And what it means to your code today. I’ve selected key passages from Introducing .NET Core. But you will also want to dig more into the article and watch as features are rolled out.
Let me explain.
In Introduction to Templates in MVVM Using Knockout.js, Mustache, you learned how you can use templates to a display and interact with Knockoutjs. But what if you would like to reuse those templates? Would you like to be able to load the templates asynchronously? And would you like to use the same techniques to load templates that could be using in Knockout, underscore and jquery-tmpl?
Jim Cowart wrote infuser to provide a “generic-ized” utility that could interface with a given template engine and handle the fetching of templates from a remote resource.
This means you can put your template content in a folder so you can reuse it in multiple places. If your template engine expects your templates to be in SCRIPT tags, you don’t have to lose syntax highlighting, etc. in your IDE – you can still place them in their own files with a valid markup extension .
You can use template feature in Knockoutjs to render your data. Templates are a straight forward way to build complex UI structure, often with repeating or nested blocks. You can use templates to show repeating data, such as data in tables or portfolios.
Templates as they are used in this post, are reusable chunks of HTML that relate to your observables in Knockout.
There are two main ways of using templates:
- Native templating where you use foreach, if, with and other control bindings. The control flow bindings use the HTML markup in your element and render against your data. The feature is built into Knockout.
- String-based templating connects Knockout to third-party template engine, such as jQuery Templates, MustacheJS, or underscore.
In our previous posts, you learned how to build modules. In the next series of posts, you will learn how you can connect up modules to the user interface. You will learn, step by step how to use observables for your user interface to dynamically update itself.
Knockout helps you build rich client-side interactivity by using an MVVM-like (Model, View, and ViewModel) pattern. It does this by helping you separate the UI behavior and the data structures. To do this, you will use declarative bindings with observable data.
Knockout is free, open source, and available for your projects using the MIT License.
Knockout helps you:
- Synchronize JSON models with HTML elements using Observable Properties.
- Synchronize arrays, using Observable Arrays.
- Provide calculated properties using Computed Properties.