I am wondering about how should i implement certain things. I am new to the Microservices architecture, but i think i understood how it works in a certain way. But i am very confused in the shared code, and shared projects thing.
I am developing a new system which contains about 50 microservice including ApiGateWays as well. I am working only in ASP.net Core
I want to standardize the requests and responses. I created a new project which contians only models, so no logic included, just a few interface and some classes.
Is it hurting the core principals of microservice architecture any ways?
I know in a certain point it does, but i develop only in ASP.Net core, and it is a very basic no logic model collection, which standard in the whole system, so if i would create a node.js project then i would use the same model there as well.
The other thing is the HealthCheck middleware. I am thinking to create this in a shared project and i would just reference it from the microservices. This would contain logic, so i am confused, i think that if i would copy and paste it to everywhere than it would not be better than creating a shared project for it. It must be a standard thing, so if i have to change it for some reason then i would have to change it every single microservice as well.
What do you think about this? It is a good practice to do it? I know this is not the best practice, i know if i would work in a team i won't try to use the HealthCheck in a shared project, because that would cause more issues than it would solve, because which team should develop that and so on...
And the last thing, somebody can help me to understand this whole code sharing in microservices, if it is possible, i read a lot of articles about it, but everybody says that you can share, but you should avoid it. Please help me if you have time for it, i think a lot of newbie how jumps into microservices, and developing alone has this confusion in his mind.
Thanks for your time and i hope this would help some newbie in Microservices, which has the same confusion in Sharing code between microservices
In the microservices world, there will still be a need for shared libraries. Healthchecks is one of them.
On MSDN docs this is described in detail.
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-3.1
A healthchecks shared library would that use that code and provide ways for your micriservices to register healthcheck endpoints with a call of one extension method.
Also that way the endpoints registered would be the same for all microservices.
Tell me if you need more info and I elaborate more.
Related
We have an active fully developed ASP.NET web application which allows users to create/update data for various screens/modules.
Now, There is a requirement to build a Web API that will automate the data creation for a particular module alone.
This API will receive data from source system and saves the posted data to our application database
(eventually removing the front-end option to create)
The Web Solution has it's own Business & Data Layer included in the solution and we are looking at ways to re-use the layers
in the API as well.
One way I can think of is to refer the Business layer as a dll in the Web API but this would
provide access to other classes & methods in the BL which is not required at this point
Can anyone please suggest what is the right approach?
splitting up a solution into multiple projects is not a bad thing.
One project for your BLL, another for your DAL is a good approach and I would definitely recommend going with that.
Yes, it does mean that if you add a reference to the BLL project into the API then yes, the API will have access to more than it needs for now, but that is not really an issue. How much you use is up to you.
Plus, if you start using the API you will probably find that more and more code will naturally converge towards that so having access to everything will make life easier, long term.
You could also break out the specific bit of code you are interested in into an extra project / dll and reference that in the API, if you see value in that, but I don't think that's particularly useful.
Another thing that I highly recommend is to have a separate project for your model classes, it makes things much easier when it comes to sharing them.
Brief overview, I am working with Visual Studio 2017 and .Net Core 2.1. I am about to begin development on a website which will handle integrating 3 existing pieces of software which our company uses.
I have created WCF services already for use by some of the applications I have developed, but for this project, there are multiple APIs which I will be utilizing. It's quite possible that I may need to use these APIs in other projects down the road.
I apologize if this is an opinionated question, but here it goes, do you think it is good design to develop one central API which wraps all the calls to the integrated system APIs? My thoughts were that in this way, I only have to write the code once for making the desired API calls and I can then add to this API as I see fit moving forward, ie. another system API is needed.
Please feel free to give advice, I am still learning and appreciate constructive advice. I am using this to get started on building my API using .Net Core 2.1, https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-2.1
If the APIs are related then yes it does make sense to create a single assembly to call those for you and deal with the responses. You'd then consume that assembly in all your other apps.
However, if the APIs are completely different and require different set ups, then it may make more sense to create an assembly wrapper for each to keep the concerns separate.
You don't want to confuse the APIs. If anyone was to look at your code or assembly, they should be able to say that it relates to what it describes and not have to guess.
I have inherited an existing .Net/angularJS project. We have a need moving forward to allow customization per client, while still maintaining synchronization through version control (in this case, git).
I'm not a .Net developer--my .Net experience is limited to writing a service a couple of years ago, starting the BrowserStack tests for the project, and the occasional foray for code review type activities. I'm primarily a Flash/Flex developer with a fair amount of ASP Classic and some PHP experience.
My preliminary research seems to indicate that I can do what I need to do with a git subtree, but I need to find where the seams should be to separate out the custom stuff from the shared code. Right now, the HTML and JS are in the same directory as the web services. My first order of business will be to separate those out, but I don't completely understand
Why everything's all in one place to begin with
What the implications are of moving things (project settings, paths, etc.)
When I wrote the service way back, I do remember that we had to scrap the service because the server we had the site on didn't support that version of .Net and it wouldn't work across domains so I could host the service on a server where it would work. I know that things have changed and there's now a way to allow that, but I figure that's the sort of problem I should be looking to avoid as I do this.
I figure I can't be the first person needing to make this kind of separation in a project I think started from the monolithic web project template, but because of a short deadline and a lack of knowledge of .Net, I'd feel better if someone could point me in the right direction or at least alert me to some of the gotchas I should plan to encounter.
Are you Trying to decouple the Projects. If so than this might be a good help.
http://www.codeproject.com/Articles/439688/Creating-ASP-NET-application-with-n-tier-architect
One of my recent project was almost the same that you mentioned above, So I ended up scrapping the old version and Create a brand new Project and Decoupled the related stuffs in the solution.
The best way of understanding stuff is to make sure you seperate the Client Side (Javascript/Htmls/CSS) and Server Side (EF/SP Calls/DTOs etc) by creating different project to the same solution.
Hope this Helps.
So I kept digging, and I finally found a pair of tutorials that address exactly this issue.
Creating an empty ASP.Net Project Powered by Angular JS Using Visual Studio
AngularJS Consuming ASP.NET Web API RESTful Services
In a nutshell, you copy the client's url from the properties panel to the service properties panel and add '/api' to the end of the URL and allow VS to create a virtual directory for you.
Now for my next trick, figuring out how to publish it...
I need to create/publish a complex MVC site to several clients, each with mostly shared functionality but also custom stuff, such as client specific controllers / views / business logic etc. Most insist on hosting the site themselves, and have functionality they don't want others to know about.
Following reading this SO post and this, I've created a means for MVC Multi-tenancy, which seems to handle most scenarios.
As I can't attach to Stack Overflow, I have posted it here (no need to read it all - it's mostly screenshots!).
The basis is to have a generic project, referenced by several client projects. The client project can then have a similar structure to the generic and take precedence when I wish to use overriding code/controls/views.
As it's the foundation of the whole thing, I don’t want to implement something only to find everyone else does it in an easier/ better way.
My question is a bit wooly, but simple - Is there a better way?
Your architecture seems about right. I would just say that you have to be really careful about the generic thing and how the client's addons will talk to the core application.
I would do that by having a base project in the CVS with client's specific branchs referencing it (as in git submodule) so everyone can beenfit from the core.
Rolling out production and QA versions are also something that must be dealt with caution as you can end up with different version far from each other depending on the client.
I have a specific case and I want to know the best practice way to handle it.
I make a specific .NET framework (web application). This web application acts like a platform or framework to many other web applications through the following methodology :
We create our dependent web applications (classes for the project business, rdlc reports) in a separate solutions then build them.
After that we add references to the resulted dll in the framework.
And create set of user controls (one for each dependent web application) and put them in a folder in the framework it self.
It works fine but any modification to a specific user control or any modification to any one of the dependent web applications. We have to add the references again and publish the whole framework !!
What I want to do is make those different web applications and the framework loosely coupled. So I could publish the framework one and only one and any modifications to the user controls or the different web applications just publish the updated part rather than the whole framework .
How to refactor my code so I can do this?
The most important thing is :
Never publish the whole framework if the change in any dependent application, just publish the updated part belongs to this application .
If loose coupling is what you are after, develop your "framework(web application)" to function as a WCF web service. Your client applications will pass requests to your web services and receive standard responses in the form of predefined objects.
If you take this route, I recommend that you implement an additional step: Do not use the objects passed to your client applications directly in your client code. Instead, create versions of these web service objects local to each client application and upon receiving your web service response objects, map them to their local counterparts. I tend to implement this with a facade project in my client solution. The facade handles all calls to my various web services, and does the mapping between client and service objects automatically with each call. It is very convenient.
The reason for this is that the day that you decide to modify the objects that your web service serves, you only have to change the mapping algorithms in your client applications... the internal code of each client solution remains unchanged. Do not underestimate how much work this can save you!
Developing WCF web services is quite a large subject. If you are interested, a book that I recommend is Programming WCF Services. It offers a pretty good introduction to WCF development for those who come from a .NET background.
I totally agree with levib, but I also have some tips:
As an alternative to WCF (with its crazy configuration needs), I would recommend ServiceStack. Like WCF it lets you receive requests and return responses in the form of predefined objects, but with NO code generation and minimal configuration. It supports all kinds of response formats, such as JSON, XML, JSV and CSV. This makes it much easier to consume from f.ex. JavaScript and even mobile apps. It even has binaries for MonoTouch and Mono for Android! It is also highly testable and blazing fast!
A great tool for the mapping part of your code is AutoMapper, it lets you set up all your mappings in a single place and map from one object type to another by calling a simple method.
Check them out! :)
Decades of experience says: avoid the framework and you won't have a problem to solve.
Frameworks evolve like cancer. The road to hell is paved with good intentions, and a good portion of those good intentions are embodied in a colossal tumour of a framework all in the name of potential re-use that never really happens.
Get some experience and knowledge when it comes to OO and design, and you'll find endless solutions to your technical problem, such as facades, and mementos, and what have you, but they are not solutions to your real problem.
Another thing, if you are using MS technology, don't bother with anything beyond what .NET offers. Stick with what the MS gods offer because as soon as you digress and become committed to some inhouse framework, your days are numbered.