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.
Related
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.
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.
So. I have embarked on the journey of learning Laravel in the last couple of weeks, and am thoroughly enjoying it.
It has come time for a site redesign and I thought it was about time to tighten up some of our functionality, so I am making the switch from CodeIgniter to Laravel.
I was wondering whether it is worth starting off with a RESTful API layer in Laravel (easy enough to create) and use it as a base even for the web application. In the future we are likely to build a mobile app that will need to use the API. So:
Is it worth having the web application connect to the API
and what is the easiest way/s to make calls to the API without having to write a bazillion
lines for cURL everytime I want to make a request?
It is definitely worth it.
I am currently redesigning a messy PHP code for an established hosting company turning it into beautiful Laravel code. I already have a mobile app working with it - Laravel makes it easy to return JSON data with one line -
Response::json('OK', 200);
or
Response::eloquent(Auth::user());
or
$tasks = Task::all();
Response::eloquent($tasks);
You don't need to use CURL as far as I know.
You can make all requests with simple AJAX, jQuery would simplify that.
Also using some MVC JS framework would help you make the application code structure more elegant for the client side, and the advantage is that you can easily package that into PhoneGap when you are ready to have your API take some real testing.
Today I posted on my blog about a simple example that you can try to see if this approach is worth your time : http://maxoffsky.com/code-blog/login-to-laravel-web-application-from-phonegap-or-backbone/
Check it out and accept the answer if you think it's on the right track.
As always, your results may vary, but this is exactly what I'm going through at the moment. I'm migrating a large .Net site with this API architecture and I've decided to keep it for Laravel.
I personally decided for this because:
More scalable. I can setup api.domain.com and then add additional
boxes/vm/whatever as our traffic grows. In fact, you could load
balance just the api by "round robin" or multiple dns entries for
that domain.
Future proofing for new sites and apps. Sounds like you're in the
same situation. I can see an app or two being added in the next year
or so.
Lost cost. You'll already be laying out your controllers, so really
it can be just a matter of setting them to RESTful and making small
tweaks to accommodate.
To be fair, some counter points:
Possibly additional load time, from processing through the API, though this should be minimal.
Additional security items to consider if you'd like to lock things down to just your app.
Either way, welcome to Laravel!
and what is the easiest way/s to make calls to the API without having to write a bazillion lines for cURL everytime I want to make a request?
#Sneaksta try postman chrome extension for calling rest services. you can create forms in this extension and pass data from these forms to you Rest services
https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?utm_source=chrome-ntp-icon
I am aiming to build a project using the Express.Js engine and ember.js for the MVC structure.
I would like to know if anyone has any tips, or links to resources that can help me with setting up the file structure and how to integrate routing with the MVC.
We are using ember/express/node backed by riak, and in our solution the ember.js app will be talking to the express REST server. We're using this: https://github.com/nathanaschbacher/chinood
Basically the ember app downloads once and runs entirely in the client's browser, making api requests for data (from your express app) whenever needed. You can read about how ember data works here:
https://github.com/emberjs/data
Depending on what data store you are using, you'll most likely need to have some representation of your models in both the express app and the ember app. Ember presents the models in a relational way, so the models that are built in the express app may be a bit different depending on the way you're actually storing the data.
Also, we're using iridium to keep our files separate and the project organized. Here's a link:
https://github.com/radiumsoftware/iridium/
You can also have a look at Charles Jolley's convoy, which really nice integrates with Node (Better than Iridium, allowing you to easily share code [models, ...] between server & client sides).
(Sorry for the delay, but I think I finally come back with a good news :-)