I need suggestion on how best we can implement APIs for large scale enterprise application has a couple of child web applications running inside root application. For example Root, Child1 and Child2
There are separate MVP projects for each application is hosted in IIS. MVC apps have only front-end logic, business & data access layer is hosted in another WCF projects(a separate WCF project for every child). Front-end MVC app only routes requests to target WCF application.
Now I'm planning to design APIs for each application. I'm not able to decide whether I should create a separate application which will hold APIs for all the child and root application or should add API in each application. Like front-end MVC projects, APIs will also redirect to centralized WCF application.
There is a common logic applicable to all the APIs(rate limiting, authentication etc...), if API is in each application then I would have to replication logic in all the three apps.
There are trade-offs either way.
The advantages of developing separate APIs include;
Isolation
Easier to change
Independently deployable I.e. Can scale independently
Might be easier if different development teams are involved in the different APIs
The disadvantages include:
Need to decide if you want to repeat common code in each API or extract a common shared module (this then reduces the isolation advantage)
More infrastructure / ops to deal with
If you want coordination in terms of rate limiting across all APIs this is harder than if they are a single API
My default position would be to develop separate APIs, but your particular use case (routing requests to other things) might be solved by some existing tool such a nginx - I'm not knowledgable about these so cannot advise
Related
net core mvc web application, it also has web api controllers layer. Since these controllers now also need to be used from another application we are thinking about separating API and exposing it independently.
I would like to understand how best to do it, what will be the different options with it specially considering authentication/authorization? Do I need to implement Identity Server or it is a nice to have?
I am launching my startup and i need to make a critical architecture choice.
I will provide a SAAS web application for my clients, they have different specific needs but the main purpose of the program is the same, automatically generating documents and pdf.
Technincally i choose ASP.NET MVC, WebAPI, EF Code First. Now I have a working proof of concept with only one project (1 db, 1 asp.net mvc client, 1 asp.net webapi, 1service layer + 1 repository)
I will have one database for every client (easier to maintain, scale ...)
One WebFront for each client with personalized html/css templates and of course specific data/menu
Only one WebApi service exposing all services for each client,
For example /api/client1/, /api/client2/ with almost the same api calls but not the same data returned.
For each client a service layer (Class library dll) that stores business logic, data acess, POCO/DTO.
Each Webfront shares reference to specific service DTO/POCO.
I need of course my solution to scale horizontally, not vertically.
So is it a good choice?
Do you have any recommendation/better solution ?
Can I put All this in the same visual project ?
I really would like to have the service layer(business) in only one project, and with good Object Oriented approach I can serve all my clients with common needs shared between all of them and specific one in derived objects.
Thanks for help
I am a bit confused on the difference between using Grails domain model/service to inlcude my biz logic or make my Grails controller/services to talk to my application server and make the web layer separate from the application logic layer?
When do I select which?
What are the pros and cons of each approach?
Any gotcha using the Grails domain stuff specially for scalability and what not?
If you already have a web service that handles your domain and business rules, you can turn off db support.
If you do that, your grails app is effectively a thin web layer on top of another service. In this case, if you are going to enforce business rules, you could still do it in service/domain layers. However, I would not do this, and certainly not any complex validation, because the service should be your single source of truth for the app, and you don't want to duplicate business rules in 2 apps.
I would still use controllers for handling web requests, and services for interacting with the other service. I would also have some sort of simple domain layer for passing data thru the sections of the web layer (i.e. services return anemic domain objects, controllers serialize them to the client however makes sense). The majority of the work would be in the service layer, which would serialize and deserialize the communication with the other service.
Based on your comment, Grails is a fine technology for building your server layer. Why would you think it isn't? Grails bills itself as a rapid development environment; it provides everything you need for all layers of a standard web-app. You don't lose anything; quite the contrary, you gain quite a bit, such a integration with persistence, spring, a robust testing framework, etc.
I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:
MyApp.Core - the app core, contains the domain models etc.
MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.
MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)
MyApp.Web.Infrastructure - web implementation
MyApp.Web.UI - ASP.NET MVC standard application.
This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.
When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.
I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
- Why should someone not just use the Services in the controllers and instead use an API?
- In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
- If I should use WCF, or ASP.NET WebAPI?
Thanks for any feedback and help!
First, regarding your projects, is there a need to split up MyApp.Web.Core, MyApp.Web.Infrastructure and MyApp.Web.UI? Sure they may be separate responsibilities, but sometimes dependency hygiene trumps encapsulation. You can always leave them in separate folders and namespaces. I wouldn't extract something into a separate project unless I needed to reference that as a library from elsewhere.
As far as the application service, that also depends on your needs. If the only place that would call that application service is the ASP.NET MVC app, then there isn't much of a need to extract an application service. There are some benefits however. One is that you don't have to worry about all of the dependencies required for a service - you just references it via Url. And of course you have the ability to call the service from places other than the controller, although the MVC controller can act as a pure HTTP service as well. You also have the ability to deploy updates to a specific service without releasing the MVC app. But you do have the burden of maintaining a separate service. If you do go that route, go with the WebAPI, WCF is just too much abstraction.
I'm developing a web app. This is more of a line-of-business app rather than a web site. I'm using ASP.NET MVC, SQL Server 2008, and I've purchased LLBLGen. I need to provide an some sort of API to third parties. For instance, if this was a medical app, third parties might need to CRUD patients, retrieve complex reports, engage certain kinds of workflows, etc.
What is the best way to do this with MVC without going to the architecture astronaut route. Do I need a whole "web service" type layer or can I re-use my controllers in MVC? Does it make sense to have this kind of API exposed through MVC? Optimally, I need a solution that involves the least amount of code repitition. I've found some stuff on doing REST with MVC but some of it is rather ambiguous and I'm not sure if it makes sense. I need a reasonable API but I'm not required to follow all the tenets of the REST religion or anything like that. I just need some sort of API in addition to providing the HTML front-end to the site, be it REST, SOAP, whatever.
Also, what are some options for dealing with URLs? Not everything in the app maps to something like site/products/product-id. Some of it involves engaging complex workflows, etc.
If you're going to have a web site and a web service then I would consider separating the data access and entities layers out from the MVC.
That way, your web service can do the same things that your website can. I would have a service layer that they both interact with. After which point the calls then go to the database and return the objects, and neither the web service nor the website should be able to interact with this layer.
This concept is also known as Separation of Concerns.
You can't/shouldn't reuse your MVC controllers in your web service. If they're so alike that they're indistinguishable, then consider writing your website to be a client of the web service, rather than being part of the same solution.