What is .NET?
What is Node.js?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
The core Web application of Raygun is still a Microsoft ASP.NET MVC application. Not too much has changed from a fundamental technology standpoint. We originally built using Mono, which just bled memory and would need to be constantly recycled. So we looked around at the options and what would be well suited to the highly transactional nature of our API. We settled on Node.js, feeling that the event loop model worked well given the lightweight workload of each message being processed. This served us well for several years.
When we started to look at .NET Core in early 2016, it became quite obvious that being able to asynchronously hand off to our queuing service greatly improved throughput. Unfortunately, at the time, Node.js didn’t provide an easy mechanism to do this, while .NET Core had great concurrency capabilities from day one. This meant that our servers spent less time blocking on the hand off, and could start processing the next inbound message. This was the core component of the performance improvement.
We chose .NET because it was a platform that our team was familiar with. Also we were skilled enough with it to know many performance tips and tricks to get the most from it. Due to this experience, it helped us get to market faster and deliver great performance.
When starting a new company and building a new product w/ limited engineering we chose to optimize for expertise and rapid development, landing on Rails API, w/ AngularJS on the front.
The reality is that we're building a CRUD app, so we considered going w/ vanilla Rails MVC to optimize velocity early on (it may not be sexy, but it gets the job done). Instead, we opted to split the codebase to allow for a richer front-end experience, focus on skill specificity when hiring, and give us the flexibility to be consumed by multiple clients in the future.
We also considered .NET core or Node.js for the API layer, and React on the front-end, but our experiences dealing with mature Node APIs and the rapid-fire changes that comes with state management in React-land put us off, given our level of experience with those tools.
We're using GitHub and Trello to track issues and projects, and a plethora of other tools to help the operational team, like Zapier, MailChimp, Google Drive with some basic Vue.js & HTML5 apps for smaller internal-facing web projects.
I chose .NET Core because it finally let me work natively on my macOS and Linux machines but collaborate with coworkers using Windows. Devs use the devices that they feel most capable with.
Having services that can run without changes on Linux let us migrate to containerized deployments on Kubernetes without much effort. The performance we've gotten from small ASP.NET Core services running on Alpine images has been great.
While the versioning of SDK and libraries/meta packages/etc has been kind of nuts.. We also keep getting new features that are really valuable and easy to package into our services.
Just rolling out v3 of the WebJobs SDK which brought simpler DI, filters and more to our Async backend workers. Also preparing to run v2 of Functions in our Azure Kubernetes cluster with virtual-kubelet.
In the last year, the community has finally started heavily moving towards NETStandard 2.0 which has eliminated some of our last points of frustration -- not finding compatible clients/libraries/tools that we could use from .NET Core apps (and, funny enough our older .NET Framework apps too!).
We're all in on .NET Core now.
I have been working in .NET for more than 10 years. As an architect, I understand that enterprises want to lower costs. Full .NET framework, although excellent, has lot of costs around it - starting from Visual Studio for development (Enterprises cannot use Community edition) to Windows Server licensing for hosting. .NET Core makes development faster, cheaper and accessible to anyone. It is easier to convince bosses to go with .NET Core than with the full framework. With Visual Studio Code, development teams can install it in minutes compared to the full day they had to submit their laptop to IT team to get full Visual Studio installed. .NET Core is also highly performant and has been my choice for an IoT project that I have been executing with microservices running in a Docker container managed by Kubernetes! Unless I have a specific need, I preach the gospel of .NET Core.
I use .NET because of its community and Microsoft's commitment to open source. Game backends require many different design strategies, ranging from latency sensitive customer facing services to high-throughput eventually consistent data pipelines. Performance, tooling, and predictability are qualities that make these services successful and .NET helps me get there by having framework features which promote quick prototyping, but are mature enough to harden for production.
I use .NET Core 2.1 because it allows me to bring my OSS applications cross-platform. We're using .NET Core for everything since version 1.1- both front and back end services, or windows services. Moving to newer versions did cause us some problems though, because of the too many breaking changes brought by those versions. We really like dotnet cli extensibility model "DotnetCliTool", because we create plugin for docker build, reportgenerator.
I use .NET because because it allows me to use a functional language like F# and still get the benefit of a massively rich ecosystem of libraries and tools. Coupled with the ability to target different OSs and platforms (from cloud to mobile to IoT) it really feels like a solid investment. In my current contract we are using .Net to build REST APIs and websites - we do this using F# and the Giraffe framework (a functional wrapper on Asp.Net Core) allowing us to benefit from teh advantages of functional approach and yet leverage security and speed of Asp.Net Core. We package these as Docker containers based on an Alpine image and deploy into Azure manage Kubernetes service in the form of Helm Charts. The build and continuous delivery are handled by Azure Dev Ops.