This is a question about designing API for frontend components.
For example: If there is any change in Model field in the backend then how can I propagate the same in frontend without changing anything else except model definition with additional field, in loosely coupled backend and frontend
And few more questions come in the same sequence are::
Will the suggested pattern work for the big project?
Is it a scalable solution for API driven micro-services based project?
Will there be conflicts if there are multiple teams working on this kind of project?
Is it good to cache APIs which are mostly frontend component definitions?
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
This buzzword is making me pull my hair... I have been asked to create
a microservice using .net core.
Googled a lot, different definitions and samples, but still, I don't know what makes a vs project a microservice / how can I create a microservice in VS. For example, I have asked to create a microservice where a user will input two latitude and longitude values and they will get the distance between them.
Cool, I can do this as a web project in no time. But here I need this as a microservice where the rest of the projects in our firm can use it.
What really makes a VS project into a Microservice or can I convert a project into a micro service? Microservice experts are welcome ...!!! I looking for that step by process in which a microservice is created in .net core.
A microservice is simply a concept. You won't find a "Microservice" template in Visual Studio. Generally, you're going to be implementing a REST API. A microservice doesn't have to be a REST API, but they most normally are.
You also generally won't just be making a microservice, but rather microservices. One of the core tenants of a microservice is that it should deal with just one discrete unit of functionality. Unless your application does just one very boring thing, you'll need multiple microservices. For example, for an ecommerce site, you might have a user service, a cart services, a checkout service, an order service, etc.
To coordinate the efforts of all these microservices, it's also typical to implement an API gateway. The application will work with the gateway only, and the gateway will proxy out the requests to each individual microservice to get the information or do the work that the application requires. In a sense, it acts as a conductor would, coordinating all the individual instruments to create the harmony.
Long and short, most likely what you want is one or likely more ASP.NET Core API project(s). You'll create controllers and actions on those controllers, where the latter of which will effectively become your endpoints, i.e. the functional routes your API exposes to do work. Since a microservice architecture is desired, these API project(s) should remain small and razor-focused, potentially only each working with just one entity class or maybe a very narrow slice of app functionality that involves multiple entities. You should strive to keep them as lightweight as possible, minimizing the amount of middleware and external libraries involved. When it comes to deployment, it's most typical to use containerization - Docker is a popular choice for that.
There's not really a template for creating a microservice in .NET, because any application that is deployable in a standalone way and that is reachable over some form of communication protocol (be it HTTP, message queues, or anything else) to perform some sort of action can be called a microservice.
See also Martin Fowler: Microservices and .NET microservices - Architecture e-book.
So to create your service that will "[accept] two latitude and longitude values and [return] the distance", you can simply create an ASP.NET Core Web API with one action method, and that's your microservice.
Another really good resources aside from what others have mentioned is: https://12factor.net/
It doesn't talk about any implementations (so you wont find references to .NET Core in there) but it does talk about how to design your application so it behaves more like a microservice - including dealing with scaling and processes that are stateless.
And to clarify a point of confusion: there's no special application type for a microservice. If your application behaves like a microservice, it is a microservice!
In Laravel I am used to define my models up front and to perform all actions on them.
However, it seems that most frontend frameworks just use whatever an API reponse provides and store the json data into simple arrays.
The only framework that I found using the model approach is Ember. I am missing this structure in the vue docs. I wonder why nobody seems to care about models. Are they just not that important in the frontend world?
Using models in frontend frameworks is not that common due to JavaScript as a language. There are many benefits to strong typing, which is why there are nowadays multiple ways to add typing to the language.
Vue has support for TypeScript which is a common way to define models in your JavaScript. TypeScript let's you define interfaces with certain types, so that you know that the data you have conforms to your model.
That's where TypeScript comes in handy, Vue supports it, I don't know much about ember but I've found this and Angular has it out of the box. As far as I know backend developers learning front end technologies like Angular and TypeScript over other options because of the coding style.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have an ASP.NET MVC 4 project and I'm stuck on an architectural decision on which JavaScript framework or library to use Angular.js or Knock.js. I am currently leaning towards using Angular.js over Knockout.js, but don't want to find out midway during project development I made a mistake.
Here is some background:
We need two-way model data binding
We need the ability to test views. I want to be able to do end to end unit testing. Also, we are using continuous integration.
"Save Changes" functionality. i.e. if a user makes changes on a page we need the ability to detect any changes and prompt the user to save their changes before they navigate away from the page
"Notifications" functionality. i.e. user will be logged on approximately 8 hours and will need to be notified and updated of changes made by other users (errors, data status changes and the like)
We need to "future proof" our application. Currently the business unit hasn't decided if we will need to support mobile devices, but I know it's just a matter of time.
Our team consists of developers with varying experience levels from very junior to senior developers.
Currently our models are complicated and may get even more so
We need to also consider RAD, code reuse, and maintainability
I have read the excellent answer here and watched Scott Allen's interview about Angular here
Since we are unable to change from our current ASP.NET MVC 4 architecture to use something on the server side like Web API I have some concerns in trying to implement Angular.js with MVC 4. Will this cause us to have two models one on the server and one on the client?
I am not looking for a "which is better" discussion about Angular and Knockout because I think they both have their pros and cons. I am looking for actual code on implementing a JavaScript framework or library in an ASP.NET MVC 4 application. I need a solution that I can live with 2+ years from now :)
Any ideas or suggestions? Maybe the answer is not Knock or Angular, but some other JavaScript framework?
my 2 cents worth.
preamble - i have worked with both angular and knockout.
I'm on my 3rd non trivial front end built with a MVVM/MVC lib.
I started with knockout because its MVVM is very similar to the wpf/silverlight mechanics. And it works well. The tutorials and documentation are top notch. All your coders will be able to work with knockout.js within days or if they have used mvvm under .net, then within hours.
However, these days I am using angular and will probably stick with it for the following reasons.
angular is a complete framework - knockout is really about just the 2
way binding. you still need other libraries like backbone.js/jquery
to do the rest of your work.
angular has dependency injection. which is perfect for adding
mocking for testing as well as giving structure to your code.
angular treats normal JS variables as observables within its $scope
object. that means you dont have to declare them in a special way
I'm not an angular fanboy, i still think they could move more over to the MVVM architecture instead of the "funky" MVVM/MVC hybrid architecture they currently have.
The biggest problem with angular is the documentation. Compared to knockout, it is woeful. It will add additional time and cost to getting your coders up to speed. Once they are there however, it is currently the best choice IMHO.
Glad to see this questions was of interest to the community ;) Just for completeness here's what I ended up doing:
I did go with AngularJS and ASP.NET MVC 4 and was glad that I did. Although, Angular has a steep learning curve but its worth it because of the power of directives.
We need two-way model data binding - On occassion I needed to set some initial values coming from the MVC controller. I used the ng-init attribute to accomplish this.
We need the ability to test views - I followed the AngularJS docs for testing
"Save Changes" functionality - I implemented this using a directive in Angular
"Notifications" functionality - I implemented this using toastr.js and and directives (schweet)
We need to "future proof" our application - I don't know Google's plans for AngularJS, but after working with AngularJS I can't see it going anywhere anytime soon and expected it to become more widely adopted :)
I don't have a lot of input on AngularJs, but want to provide some thoughts on Knockout.
Knockout is primarily a data-binding library to connect views to view model, but doesn't really provide a lot of capabilities beyond that. I wouldn't recommend using knockout alone as the main library to build a complex client-based web site.
You didn't mention whether you're implementing spa-like functionality (i.e. hash-tag navigation) or whether you're primarily using MVC server-side views (e.g. Razor). If you're just looking for quick data-binding on a per-page level, I would even reconsider that. To me, both of these (angular or knockout) are designed to enhance the client-side development experience - not so much a server-side approach such as MVC.
If you're considering an SPA approach, even in part, you'll likely want some framework that provides some level of control over the view activation life cycle.
As far as data-binding power and reliability, I believe in Knockout. I have been using it extensively, and have grown quite fond of it. If you like the feel of knockout, you may want to look into Durandal. Durandal is a decent framework is able to meet the needs of many "spa" web projects. It's a client-side framework built on top of several proven libraries, including Knockout. It's a little (lot) more light-weight than Angular, and possibly easier to user.
We are building a fairly large ASP.Net MVC web site using Durandal with Knockout in conjunction with an additional facade to tighten things up from a development standpoint, and the integration with ASP.Net MVC is straight-forward. I don't recommend trying to use the server-side knockout stuff that's out there; I just find that to limit the real power of the MVVM pattern.
I'm in the situation that I have to design and implement a system from the scratch. I have some questions about the architecture that I would like your comments and thoughts on.
Quick Info about the project: It's a data centric web application.
The application will be built on Microsoft .NET Framework 4.0 with MS SQL SERVER 2008 database.
Requirement:
Rich UI and robust
Multi-device support (every browser and on every device)
Loosely coupled
Below is the architectural diagram I have built:
Briefing of the architecture
Presentation layer : HTML5/ASP.NET MVC + JQuery (Web application for multi-device support in first version)
Distributed Services : WCF (XML/JSON/JSONP)
Domain Layer(Business Layer) : All business logic
Data persistence (DAL Layer) : Entity Framework 4.0 with database first approach. POCO entities are generated and separated out using T4 template
Infrastructural Layer: Contains common libraries like POCO entities, Exception Handling, logging etc
My Concerns :
As application is to be built loosely coupled so in future if business requirement grows new modules can be easily plugged in without affecting the architecture.
So I thought of using the Repository pattern along with IoC and DI (can be Unity/Ninject/Sprint.NET or any other)
WCF with both XML and JSON support
Distributed Service Layer to place IoC & DI
Exception Handling & Logging using Enterprise Library 5.0
Looking for valuable comments and suggestions.
If I am doing anything wrong please put me in right direction.
I would suggest the following comment: right from the outset your approach will create tight coupling. This goes directly against your requirement #3 "Loosely coupled"
In your diagram you have defined two modules. Main module, and Module 2. I would guess that these two modules are quite distinct from each other. What I mean by this is that you could develop them completely separately and then plug them in, because the business concerns they address are different.
However, your current architectural approach:
Couples Main Module and Module 2 data into the same database
Couples Main Module and Module 2 business objects into the same business layer
Couples Main Module and Module 2 services into the same service layer
Couples the deployment and management of Main Module and Module 2
What may be worth considering: Build Main Module and Module 2 as separate vertical service stacks.
What I mean is Main Module and Module 2 become Main Service and Service 2
Each service has it's own database, it's own business layer, it's own services layer and it's own UI components.
However, this raises the concern: how can Main Service and Service 2 both work together to create my product?
To address this:
At the UI end, you stitch your front end together by using client-side code to load responses from the Main Service and Service 2 into one view.
At the back end you use publish subscribe messaging to allow Main Service to subscribe to events happening in Service 2 and vice versa.
This will result in an application built from the ground up on top of loosely coupled vertical service stacks, which maintain consistency by the asynchronous exchange of messages.
If you then need to add in a new module to your application, you can create a new service stack which supports the desired capability and wire it up with little or even no change needed to the other stacks (ideally the only reason to change existing stacks would be that they want to subscribe to events from the new module).
It's a very different approach to the one you're suggesting, but one which allows you to meet the requirement for loose coupling better, in my opninion.
How come that the architecture diagram doesn't use the domain layer for ASP.NET?
It seems to me that you may be overarchitecturing your application. Also, while it looks great to support 6 (or so) different front-end technologies, the effort to maintain all of them will be horrendous. I'd stick to one technology for the front-end - most likely HTML5 with client-side MVC or similar.
It makes sense that the WPF, WinForm etc UIs should call the WCF layer. I'm assuming that it's a business requirement to have multiple UIs, otherwise if you can only have one UI a responsive web UI is the most flexible choice.
However, I don't think your MVC UI needs to use the WCF layer. It could call the domain layer directly. That would be faster and remove a pointless layer.
Obviously, that would only work so long as you don't put any logic in your WCF layer. And the WCF layer really shouldn't have any logic in it.
You also state that you want to place IoC & DI in the Distributed Service Layer. That doesn't make much sense in terms of your MVC UI. You'll need to use DI in the MVC project so you can unit test the controllers.
Looking at your diagram I have a couple of points I'm not clear on:
Where is the domain model? Domain Core or the 'model' in the persistence layer?
How does the domain layer interact with the data access layer? The interaction is not as clear as between the service/application layer and domain layer.
What the difference between a repository in the domain layer and a repository in the data access layer? I usually make the distinction of having 'model repositories' in the domain layer which act upon domain model objects, and 'data gateways' in the data access layer which act upon DTO's.
What is domain core? Is this the implementation of the application layer transactions?
Does there need to be a further abstraction of the persistence framework? (EF)
I'm having a hard time wrapping my mind around something and would appreciate some reading material on this concept.
I'm writing an application that relies heavily on providing API calls via a URI scheme. example.com/company/user/123123. The aspects of taking a URI string and converting it to an action makes sense.
But where I get confused is taking that process and utilizing within the MVC structure. Do I build calls using models or a library? My goal is to be able to do something like $this->company->user(12311), so that I can have the API functionality available externally and internally.
Also how do I make this functionality accessible without exposing core code?
One of the biggest problems with the word API is that it does not make a distinction between when you are making local in process calls and when you are making remote calls. This is the essence of the RPC style, using the same programmatic model regardless of where the code to be executed exists.
REST is explicitly about doing distributed computing and is optimized for those scenarios. Trying to use a RESTful interface as a local API is likely to produce something that is highly inefficient.
I would suggest not trying to use the same API internally and externally and I would go further and say try not to think of REST as a way of building APIs. REST is an approach to building distributed systems that requires consideration of the system holistically.
To address your question more specifically, I use an MVC approach to exposing Resources in my system. The Model is the Resource and the View is the Representation. The key to building a RESTful system is to identify the links between your models. These links are rendered into the respresentations as embedded links. Also, consider that your models should be more like Presentation Models than domain models as a RESTful interface is more about exposing the usage scenarios of a system than it is about exposing a domain model.