For a mobile application project I need a REST API that I'm going to do with FOSRestBundle and I need a backend website to manage the database (CRUD)
How can I do to have only one instance of each entity? should I create 2 projects or 2 Bundles?
It is better you create 2 bundles. and create all entity In one of them.
For example, create AdminBundle and AppBundle .use AppBundle for frontend .and AdminBundle for Backend and API.All entity creates in AdminBundle.
Even you can manage events or requests by building different controls. for example, you can have a bundle and create ApiController, FrontController,...
I think making two projects is the worst solution
I can say what i will do in this case.
Create 1 RESTFUL API project without any frontend part.
Create SPA (React.js, Vue.js, Angular) website for admin
Create SPA frontend website for users.
You can take a look at https://api-platform.com/ to get more understanding how it should be.
UPD.: If you think about splitting API project to microservice and can not make choice if you need it or not I can help you. You need it if you have many teams who need to deliver tasks in parallel. If you work alone or with small team you can work with monolith.
Related
I'm new in this area, however I would like to know, if it is better to put api inside my project, or create one back-end separate and pull into the project. I know if I use a separate back-end I will have to buy 2 hosting, if I use it within my project it would be one.
back-end integrated into the project
back-end separate
I tried to do both ways, and apparently it worked, but I would like to know if it is recommended to put the back-end inside the front-end
It depends on your needs and budget. if your project requires a lot of data processing or complex business logics it may be beneficial to separate your API from the front-end. However if your project is simple and doen't require a lot of data processing then it maybe more cost-efficient to host the API within your Next.js project with a single server.
This is a design related problem.
I have a legacy application in asp.net webforms which have 3 kind of users: Admin, Customer and Provider, which access multiple services like Product, Account, Sale, Purchase etc. All these 3 users share same set of class libraries for services, logic and database until now. And the deployment is single for all 3 users.
Now we are migrating this into .net core web api + angular. And I am thinking about the options. Till now I have figured out this is the best for our application:
Create separate web api for Admin, Customer and Provider. Then for any changes in Admin, the deployment will not impact Customer.
But the problem with this approach is the class libraries will be duplicated. Some common methods will be duplicated.
Is there any alternative/good approach for this?
My answer is too large, so I decided to add another answer.
To migrate your monolithic app into Microservice or Macroservice it should be better to follow below steps:
Identify all component groups, which means you should decompose your application into several small projects, in your example, they would be AdminPeoject, CustomerProject, and ProviderProject.
then define several endpoints and APIs for all your data access scenario. for example if you need to access or manipulate data located in AdminProject and your request source is other project, you would have an API for this purpose in your AdminProject, and from now on every request which related to data manipulation in AdminProject should be done by these APIs.
In the next step, every project should be deployable and independent of the deployment of other projects.
If your system is not complex, it does not need to migrate your Macroservice into Microservice because it will add so many complexities to your project.
it's better to use a single datastore. after a while, if there is a need for separation, you just need to separate the data stores.
The separation of projects can be beneficial in case of :
updating one project don't impact the others
release cycle can be very small in this approach which obviously results in faster development and deployment
but if you just want to separate your project and they still have a single datastore, this architecture is a Macroservice architecture and the communication between micros should be done by APIs
for your shared code, you can define a Nuget package and every project can add it into their project to prevent repetitive code
I want to make a quick, safe and nice application.
For many years I have been programming in PHP and regular ASP. But wanted to go on with .NET and vue.js.
So I have an idea, I wanted to create and plan to do it like this:
I was thinking of using hosting from an external service.
Then I would have three projects:
domain.com/index - Vue.js which will be a SPA, where the user can filter through a catalog, press like and send few api requests (mainly get-requests).
secure.domain.com - Here I will have a .net mvc project where I can use identity. This will make it simple to handle/register users. I will also give the correct session here for authenticated users. And it will affect domain.com/index, where they only are allowed to do some of the things if they are logged in
api.domain.com - This will be the webapi api. Only authenticated users will be allowed to send some of the requests.
I have used several weeks at looking into how to structure this.
But as I do not have much experience with this.
What pitfalls and bad consequences do you see in structuring it like this?
Are there any heads up you want to give me? Or any other recommendations?
I have been trying to melt all of this together in one project, but that has been difficult, because they operate in different ways. So now I have ended up with this, and look forward to
Size of project
It will be a relative small project.
People should be able to register/authenticate themselves (through facebook/google/server login).
Authenticated People should be able to add records(links) to a database. When adding this to the database they may also want to upload files, and choose some additional information.
All people should be able to filter through the catalog of records (5000+) ( Here I am using vue.js/vuex/axios). Here they should be able to comment too on links too.
Webapi will have 8 entities/tables and one view which will GET all the information. 3 tables should be able to have POST.
So it is more or less a catalog, where people should be able to add records and find new ones.
I was planning to use the identity from asp.net core 3.1. It is a "template" where I can easily add 3rd party logins. (https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-3.1&tabs=visual-studio)
Additional questions:
Can you tell me how request from SPA will be authenticated in your API? (Jwt or cookie)? Why would you like to have a separate identity service, also Why you would like to use asp.net identity (is it because of ease of setup)?
I have not been thinking about authenticating API requests. Was thinking to only have authenticated users who can send POST-requests. And the rest will be get requests. Limited only from the server. Should I have some additional authentication? Does JWT make web APIs safe enough for my use?
Was thinking of using .net identity because it is simple. And I don't want to use time on setting it up.
Since this is your first project of this type, I would recommend to keep it simple.
Just create one web site. Otherwise you might get issues with the cookies not working for subdomains and you will also get issues with CORS. That is, you will get all problems at the same to time (configuration issues, infrastructure issues and the pain from writing the application itself).
You can still have a clean separation by using sub folders (or Areas in MVC) and by using class libraries for the backend (API) business logic.
Once you have mastered the basics (i.e. writing the actual application) you can start looking at other means of separation etc.
Background: I'm working on a project to compare the different ways of building an api alongside the different ways to present views to the client. Namely, comparing a level 2 REST API, a level 3 REST API (with HATEOS), and a GraphQL api.On the client I want to compare a standard MVC web application, a Razor one, and an Angular one. You can see the current state of my project here. I used a couple of Pluralsight courses to configure identity server. Its nothing special and its mostly a bunch of random features for the sake of learning.
I dont want to duplicate a ton of logic and I enjoy the challenge. So I want to find a way to serve the different projects in the same sln. So far I've configured the authentication, data layer, and server projects.
The server is where the main and startup classes live.
Question: How can I serve views from controllers in different projects. In API. Authentication I want the Login views kept in that project.
I used this SO question to get me pointed in a direction:
How to specify the view location in asp.net core mvc when using custom locations?
In my Startup class I have this:
services.Configure<RazorViewEngineOptions>(options => {
options.ViewLocationFormats.Clear();
options.ViewLocationFormats.Add("/API.Authentication/Views/{1}/{0}" + RazorViewEngine.ViewExtension);
});
When I go to localhost:8000/login it errors but it says that its looking in the correct location.
How can I configure to point to multiple folders outside of the Startup Classe's directory?
I have started to work on a greenfield web project which will use ASPNET Core and Aurelia. I cannot find a definitive best-practice approach to structuring this on the client. My current thinking is that each app feature will be be a separate Aurelia application, i.e. when a visitor clicks on the link "Accounts" the browser will make a server request to https://example.com/accounts. This will return a single HTML page which bootstraps an Aurelia app just for accounts. All the accounts interaction will be delivered using Aurelia. Similarly, if the visitor then clicks on "Dashboard", another server roundtrip will bootstrap the "Dashboard" Aurelia app.
Is this a good way of approaching the problem? I have some concerns around application state - in that there will be cross-cutting concerns and data which I don't want to keep round-tripping to the server every time I need it, e.g. audit logs, user information.
I see that Aurelia has the concept of Features - semantically this is exactly what I want as each of these areas of the app will be delivered as a feature. However, I cannot find any good examples of the use of Aurelia features.
Any comments or experiences in similar projects most welcome.
I don't know if it's the 'best' way of doing it but a lot of the applications I build are user / admin type products.
Rather than building an application for each side I take advantage of child routers and structure my application with a page based convention as described here:
https://ilikekillnerds.com/2015/10/how-to-structure-an-aurelia-application/