About AWS Beanstalk
When you want a web app on AWS that can just run without having to manage the operating system, you want AWS Beanstalk. It can be Internet facing or it can be a worker without facing the Internet.
You simply upload your application, and Elastic Beanstalk automatically handles the details of capacity provisioning, load balancing, scaling, and application health monitoring. Elastic Beanstalk uses highly reliable and scalable services that are available in the AWS Free Tier.
AWS has many services. AWS provides nearly 100 services: many types of virtual servers, several types of storage services, ways for you to build and deploy your application on virtual networks. machine learning.
For our simple web application, in this series I’ll start with AWS Elastic Beanstalk. But you can also deploy .NET applications to AWS Lamdba for serverless apps or to Docker Containers on ECS. AWS supports the AWS Management Console or Git or Eclipse or Visual Studio to upload the application. This walkthrough will use Visual Studio.
Containers give you a way to run you application in a controlled environment, isolated from other applications running on the machine and from the underlying infrastructure.
It means that when you go to deploy, all the dependencies are published together. So you can finally say, “It worked on my machine” and mean it. All the dependencies with the same versions in your container will be there when you deploy to the cloud.
In the last post, Building Stateful jQuery UI Plugin Using Widget Factory, you were introduced to the working structure of jQuery UI Widgets. You learned that it uses the factory pattern is a way to generate different objects with a common interface. And that it Widget Factory adds features to jQuery plug-in.
jQuery UI Widget Factory is under jQuery UI, but you can use it separately for your own widgets. In this post, you will learn the steps you can take to build your own widget. This posts walks through an implementation of the filterable dropdown from Adam J. Sontag’s and Corey Frang’s post: The jQuery UI Widget Factory WAT?
My motivation in this post is to show what goes where when you are designing your widgets. And provide some direction in the steps you can take when building a widget from scratch.
In this post, you will learn step-by-step to build your own custom, reusable, testable jQuery UI widget.
You will extend the jQuery library with custom UI code and then use it on a page. The initial plug-in will be trivial to demonstrate the jQuery Widget Factory pattern. You will provide properties that you can change to change the look of your widget and you will provide some methods that will respond to user input.
In this post example, you will learn how to create a simple click counter. Click a button, increase the count. The idea is to show you the steps to create a jQuery UI Widget.
The Widget Factory system manages state, allows multiple functions to be exposed via a single plugin, and provides various extension points.
In this post, you will learn step-by-step to build your own custom, reusable, testable jQuery Plugin.
There are times where you will want to reuse code that performs a series of operations on a selection.
For example, you may want to embed information a span element and then have that information displayed in a references section near the end of the document. In this case, the jQuery plugin is stateless.
In the next post, Building Stateful jQuery UI Plugin Using Widget Factory, you will see how to create a stateful jQuery plugin using jQuery Widget. And you will see how the widget is a better solution for plugins that require user interaction, because the Widget factory helps you maintain state.
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.
John Munsch explains it like this:
When you go and get things out of the refrigerator for yourself, you can cause problems. You might leave the door open, you might get something Mommy or Daddy doesn’t want you to have. You might even be looking for something we don’t even have or which has expired.
What you should be doing is stating a need, “I need something to drink with lunch,” and then we will make sure you have something when you sit down to eat.
In designing an object-oriented application, a major tenet of design is “loose coupling”. Objects should only have as many dependencies as is needed to do their job – and the dependencies should be few.
There are three primary approaches to implementing DI:
- Constructor injection
- Setter injection (also called Property injection)
- Method injection
Constructor injection uses parameters to inject dependencies. In setter injection, you use setter methods to inject the object’s dependencies. Finally, in interface-based injection, you design an interface to inject dependencies.
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).
Moving applications to the cloud provides you with a cloud infrastructure for backup and resiliency. When you move to the cloud, you move from a standard physical implementation tool, including data centers, software, hardware, networking and servers – and move to a service, where much of the infrastructure is maintained for you. Cloud offerings such as Microsoft Azure provide you with a standard configuration. If your application fits those parameters, migration is easier. Other times, the application may require particular settings in Internet Information Services.
Although not all applications will seamlessly move to the cloud, a tool from Microsoft Azure Websites Migration Assistant offers you a way to determine what challenges you may face in moving your application to Azure. The Azure Websites Migration Assistant help you migrate your on-premise app to the cloud in a few clicks.
For example, if you want to move a departmental application from Windows Server 2003 running ASP.NET 2 running a version of SQL locally, you might not think of that being a candidate for migration to the cloud.
Windows Server 2003 will reach end of support on July 14th 2015. If you are currently your websites on an IIS server that is Windows Server 2003, Azure Websites is a low-risk, low-cost, and low-friction way to keep your websites online, and Azure Websites Migration Assistant can help automate the migration process for you.
Azure Websites Migration Assistant can analyze your IIS server installation, identify which sites can be migrated to Azure Websites, highlight any elements that cannot be migrated or are unsupported on the platform, and then migrate your websites and associated databases to Azure.
Applications can be deployed to Azure Websites.
The latest version of TypeScript includes of new features in the language, compiler and associated tools. And it comes in the box as part of Visual Studio 2013 and Visual Studio 2015.
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
You may want to use storage to store data. You can save the data your user has entered in a wizard. Or you might want to save data so you can provide an offline experience. Or you may want to store user preferences. Local storage is a good idea anytime you do not want, or need your user or your application to start all over.
AmplifyJS is a very neat library that provides a consistent API to handle client storage that works in most browsers.
In this post, you will learn to retrieve the data through amplify.request without concern for data caching, server interface, resource location, data types, wrappers, and all the other specificities of the client/server interaction.
Requests made through amplify.request will always be resolved asynchronously, even if the resource invokes the callbacks immediately.
You will probably need jQuery for Amplify Request. The default request type shipped with AmplifyJS does utilize jQuery AJAX, but you can just as easily create a new request type that uses Dojo, MooTools, etc.
However the publish/subscribe and store components do not use jQuery at all.