In 2015 as Xelex Digital was paving a new technology path, moving from ASP.NET web services and web applications, we knew that we wanted to move to a more modular decoupled base of applications centered around REST APIs.

To that end we spent several months studying API design patterns and decided to use our own adaptation of CRUD, specifically a SCRUD pattern that elevates query params to a more central role via the Search action.

Once we nailed down the API design pattern it was time to decide what language(s) our new APIs would be built upon. Our team has always been driven by the right tool for the job rather than what we know best. That said, in balancing practicality we chose to focus on 3 options that our team had deep experience with and knew the pros and cons of.

For us it came down to C#, JavaScript, and Ruby. At the time we owned our infrastructure, racks in cages, that were all loaded with Windows. We were also at a point that we were using that infrastructure to it's fullest and could not afford additional servers running Linux. That's a long way of saying we decided against Ruby as it doesn't play nice on Windows.

That left us with two options. We went a very unconventional route for deciding between the two. We built MVP APIs on both. The interfaces were identical and interchangeable. What we found was easily quantifiable differences.

We were able to iterate on our Node based APIs much more rapidly than we were our C# APIs. For us this was owed to the community coupled with the extremely dynamic nature of JS. There were tradeoffs we considered, latency was (acceptably) higher on requests to our Node APIs. No strong types to protect us from ourselves, but we've rarely found that to be an issue.

As such we decided to commit resources to our Node APIs and push it out as the core brain of our new system. We haven't looked back since. It has consistently met our needs, scaling with us, getting better with time as continually pour into and expand our capabilities.

C# and .Net were obvious choices for us at LiveTiles given our investment in the Microsoft ecosystem. It enabled us to harness of the .Net framework to build ASP.Net MVC, WebAPI, and Serverless applications very easily. Coupled with the high productivity of Visual Studio, it's the native tongue of Microsoft technology.

When I started on this project as the sole developer, I was new to web development and I was looking at all of the web frameworks available for the job. I had some experience with Ruby on Rails and I had looked into .net for a bit, but when I found Laravel, it felt like the best framework for me to get the product to market. What made me choose Laravel was the easy to read documentation and active community. Rails had great documentation, but lacked some features built in that I wanted out of the box, while .net had a ton of video documentation tutorials, but nothing as straightforward as Laravels. So far, I am happy with the decision I made, and looking forward to the website release!

Comparing to ASP.NET Core MVC or ASP.NET Core Web API Simplify.Web allows you to easily build your web-site or REST API without any additional/complicated setup, covering cases like localization by default. It's projects structure very lightweight, just a minimum amount of what you need to setup ASP.NET Core request pipeline.

It is build on top of Simplify.DI IOC container abstraction, no dependency on Microsoft.Extensions.DependencyInjection and it's syntax. You can easily switch between DryIoc, SimpleInjector, CastleWindsor etc.

Any internal module of Simplify.Web can be easily replaced on extended by your custom module, covering your custom cases.

For HTML pages generation Simplify.Templates can be used allowing you to use just regular plain HTML without additional setup.

Can be easily integrated with Simplify.WindowsServices converting your web application not just to web-application, but a standalone windows service which can also do some background jobs via Simplify.WindowsServices.

And it is open source, of course :)