re: Your Degree of Interest in Microsoft VIEW POST


We use Microsoft technologies at work. Initially for historical reasons. But I still choose to use the platform because of F# and a decent ecosystem (libraries, IDE, etc).

We have started to switch over to .NET Core, and have it in production. The tech is in a decent state and with Core they are finally offering more flexible deployment options (linux, native binaries, etc). With the natural consequence being that the configuration is different and a little more complex vs Framework.

I am only interested in ASP.NET up to Kestrel in the stack. The frameworks that are higher on the stack like MVC are of no interest to me. (I have previous experience with most of the ASP.NET frameworks since .NET launched -- e.g. WebForms, MVC, WCF, Web API, etc.) Newer apps/services that we develop are by and large framework-less. However, I believe our approach is different from most Microsoft shops. And MVC knowledge is generally in demand if you use ASP.NET Core.

The only tech-related certifications I have seen which directly correlate to capability and therefore salary are Cisco certs (which is networking, not dev). It doesn't hurt to have Microsoft certs if you want to be in the Microsoft stack. But in my view the amount it helps is marginal at best. Your effort would probably be better spent setting up a github repo as a practiced example to put on your resume.


"Newer apps/services that we develop are by and large framework-less." - I would LOVE to hear more about this.


I've been thinking through a blog post on this exact topic for APIs. The main challenge has been teasing out what is required for framework-less from the rest of the design principles we used. Here is a rough overview. Feel free to comment or ask more questions.


For us, I think the primary factor to become framework-less has been the pragmatic use of functional programming. No more inheritance, interfaces, overrides, attributes, etc. Just types and functions on those types, and everything is easy to compose together. Here is a humorous video on these "functional design patterns". Functional programming informs the other things I mention below.

I had to write a few small libraries myself where the alternatives already in the ecosystem were frameworky. For example, HTTP request filtering/routing (7 source files), SQL (7 source files), and validation (4 source files). The theme of these libraries are: instead of having to inherit and override preset methods, provide common functions that users can chain together. And allow the user to add their own functions for cases not covered.

I believe another important factor is the pervasive use of messaging. Primarily that our business logic only returns decision events rather than actually performing the IO themselves. Subsequent steps in processing the request can simply map the decision events to whatever IO is appropriate (SQL statements, email, etc), even ones we think of later. Whereas a framework usually does not make it easy to plug in new IO integrations. And IO in business logic just makes that logic hard to test and compose with other code.


This one is a bit easier, because there already exist some "platforms" that tie most everything together into a unified solution. Elm is the most obvious example. The most "frameworky" bit of it is the JS interop using ports. Otherwise, Elm prescribes an application structure (Model/Msg types and View/Update functions - aka MVU) and that's it. Most everything you do after that is your own code to solve your own problem. It uses a virtual DOM library to render HTML, similar to React's. It also provides some other libraries like HTTP, Regex, etc. Even if you ultimately choose another MVU platform, Elm is a great teaching tool. We're using it in production currently, but evaluating other options.

Note that MVU is designed to handle different circumstances from a back-end API. MVU is designed to collect user inputs that may be haphazard or never come at all. Whereas request/response APIs usually expect to execute a use case in a consistent and sequential way. So using MVU for APIs is paying overhead for flexibility that will not be used. However, MVU is a lovely pattern for Process Managers.

I think my mouth was open the entire time I read that just now ...


This is interesting. I'll give certification the second priority. Let me collect more feedback. Thank you very much.

code of conduct - report abuse