My background includes:
- Programming since I was 7 (in 1987)
- 13 years in the Software as a Service industry
- Desktop application development in WPF on home automation software
- Building agile and waterfall project and resource management software in WPF, Silverlight, ASP .NET, SignalR, Angular, and TypeScript
- Focusing on software quality in Interstate and Local move pricing and surveying software in .NET and .NET Core Web API projects
- Team Leadership and Management
- Being an unabashed nerd
Top comments (7)
When the UI request a change that is propagated across multiple microservices, what is your criteria to decide if the UI will be responsible to call all service endpoints, or if a wrapper api should receive all changes from the UI and call all required microservices to complete the operation.
The second approach implies that the intermediate api should propagate any microservice error to the UI.
The first approach increases the UI complexity and also the number of requests.
Both solutions have its pros and cons, and would depend on the specs as well. But what would you take as major criteria to decide for one, or would consider any other solution for it?
I have to qualify this by stating that while I have studied microservices and am working towards a microservices architecture, I have not yet worked with one in production.
That said, if I had a UI as you described and it needed to talk to multiple microservices and be fault tolerant, my natural tendency would be towards an API specific gateway microservice that talks to individual microservices that are not necessarily accessible to the outside world.
My reasoning here is this: If you have an Angular Single Page Application, for example, running client-side in the browser, it might be running several states away from the servers the back-end logic runs on. I'd rather do one call to get to the API gateway microservice which could handle authentication, etc (possibly via outsourcing it to an auth microservice) and then chain a series of calls to other microservices running in the same AWS or Azure region or on proprietary hardware for performance. These services would not be publicly accessible, which enhances security.
Additionally, any error handling due to services being offline could be handled at the microservice level with the microservice potentially putting a request into a queue. Additionally, if I needed to patch a microservice in an emergency, I wouldn't need to wait for all the users to finish refreshing their web pages to get the new version of the application - the logic would be in that gateway service.
The downside is that you do have to introduce a new service in order to do this, and the client is now strongly-tied to the definition of that service's API, but it makes future updates to your back end systems easier, performance and fault tolerance better, and it keeps your client code simpler.
A lot of that is my values, and I value performance and simplicity. My suspicion is that this would also lead to better quality longer-term, but that's not proven and it does introduce one more point of failure in that the API gateway service could go down.
Thanks a lot for sharing.
What are your thoughts about cross-platform .NET? How hard is it to develop the same service in .Net Core vs .Net?
Cross platform .NET is the future of .NET. It makes an incredible amount of business sense from a hosting costs perspective, and the performance and maintainability gains of moving from .NET Framework to .NET Core are real. Plus, as I said, it's the future of the framework with .NET 5 coming out in Fall of 2021.
That said, there are some obstacles to getting there. My main obstacles at the moment at work are a reliance on things like the Windows Event Log and OLEDB for data access using technologies such as Microsoft Access (ew).
I'm a huge fan of .NET Core and believe Microsoft is going in the right direction. I strongly recommend moving to .NET Core - even on Windows only at first using the framework platform extensions. You've got some time, to be sure, but with these things it's good to get an early start, especially if you can take advantage of hosting cost improvements.
As far as difficulty in developing a new service in .NET Core, I find it's easier overall since the framework is slimmed down and simplified. The biggest difference is going to be in the web.config to the app settings JSON and the concept of the middleware pipeline, but these things aren't too hard to learn.
Have you migrated any projects to typescript? How did it go?
I'm currently doing a somewhat large typescript migration at my company so I'm curious what others experiences are.
I am a huge TypeScript fan. First of all, I think more naturally in TS vs JS, but secondly, it removes entire classes of defects by catching issues at time of transpilation. See my article on eliminating defects for some more thoughts on that.
Making Defects Impossible
Matt Eland γ» Aug 31 γ» 5 min read
On your specific question on migrating projects to TypeScript, while I can't go into detail due to confidentiality, I can say that I have taken a single page application written in JavaScript and JQuery and migrated the JavaScript to TypeScript. This was a project written by a first-time JavaScript developer and was known to be extremely brittle and buggy. The act of converting it resolved all known defects and drastically improved the application's maintainability / reduced the brittleness that led to bugs emerging when the application was modified.
Each application is different, but that particular one had major issues that could be solved via a strongly-typed language at time of transpilation as well as refactoring its state management techniques (though we stopped short of introducing Redux for state or Angular, Vue, or React for application management).