There are countless front-end workflows. In what we’re hoping will be the first of a series of episodes on workflows we talk with noted front-end guru and JavaScript master David Wesst (https://blog.davidwesst.com/). JavaScript or TypeScript? Gulp or Grunt? Hear what one expert thinks is the best combination.
If you happen to head over to https://www.nuget.org/packages and look at which package has been downloaded the most there is a clear winner: JSON.net. It is in everything, every where. JSON is so wildly ubiquitous that I play a little game with myself when I start a new project: how long can I go before I need to serialize or deserialize JSON and need to pull in JSON.net. I rarely last more than a couple of hours.
But it turns out that there is a lot more that JSON.net can do.
Adding deployment steps to your build pipeline is a lot easier than it used to be. In today’s episode, Monster Dave explores deployments and environment management using the AppVeyor hosted build service.
Previous Episode: Hosted ASP.NET Core Builds with AppVeyor
A continuous integration (CI) build is a helpful tool for any software project. In today’s episode, Monster Dave explores the AppVeyor hosted build service and shows just how easy it is to setup a CI build for your ASP.NET Core project.
In our last episode we set up a Docker container using Windows Containers, in this episode we’ll talk a bit about messaging and then send a message using RabbitMQ.
References:
ASP.NET Monsters blog on RabbitMQ
This blog is part of a series exploring RabbitMQ and MassTransit. Previous episodes are available at
In the last episode I did a lot of handwaving over the mess I made of configuration. There were hard coded values all over the place. In this article we’ll clear up some of the mess we made.
Docker is now fully sported on Windows 10. In this episode we’ll see what it takes to avoid installing RabbitMQ locally and, instead, use a Windows container. Keeping RabbitMQ in a container allows standing up a cluster on one physical machine, greater ability to experiment and a high degree of isolation. In the future we expect that a great deal of local development will leverage containers.
In the last post, we created an application which can send tasks to a background processor. We did it directly with RabbitMQ which was a bit of a pain. We had to do our own wiring and even our own serialization. Nobody wants to do that for any sort of sizable application. Wiring would be very painful on a large scale.
There are a couple of good options in the .NET space which can be layered on top of raw queues. NServiceBus is perhaps the most well know option. There is, of course, a cost to running NServiceBus as it is a commercial product. In my mind the cost of NServiceBus is well worth it for small and medium installations. For large installations I’d recommend building more tightly on top of cloud based transports, but that’s a topic for another blog post.
React is a fantastic view engine and one of its best features is that it can be attached to pre existing markup. This allows us to render out HTML on the server side and then hookup React to it once all the JavaScript has been downloaded and started. We can get the best of single page application and the best of full web applications. In this episode we mash on speeding up single page react applications on the server.
References
In the last post we looked at how to set up RabbitMQ in a Windows container. It was quite the adventure and I’m sure it was woth the time I invested. Probably. Now we have it set up we can get to writing an application using it.
A pretty common use case when building a web application is that we want to do some background processing which takes longer than we’d like to keep a request open for. Doing so would lock up an IIS thread too, which ins’t optimal. In this example we’d like to make our user creation a background process.