My main application is being built with Vue (mydomain.com), I also have a REST API (api.mydomain.com) and then my assets (assets.mydomain.com).
The API is unlikely to be used by other developers, and is only for my convenience when building the spa with Vue. Considering this: would it be better to build a single Laravel application that handles all three subdomains OR have a Laravel application that handles the API, a standalone Vue build for my main application and then serve the assets as a seperate build entirely?
What are the pros/cons for a single build vs three?
I haven't used Laravel in that context but I sure prefer the more modularized approach of having different builds for different functionality.
I normally use the approach with Node.js where I have both assets and api handled by the backend. (Express app etc) and then separate build fetching the data to render in the spa using React.
This build benefits scalability since you can easilly maintain, track and debug the code. Obviously it makes it also easier for unit testing. And the performance of the SPA isn't affected by the payload routing in the backend since it runs separately and only interact upon request (REST API in my case).
I hope I provided useful insight.
Related
I want to use laravel(as backend) and angular(as frontend).
As far as I know I can use 2 methods :-
1) I can integrate both frameworks by using API service or
2) I can use monolithic architecture style (using angular with blade template)
As per my requirements 2nd option is better because in it I can use laravel's default functionalities in angular like (Auth, user roles and permissions etc).
But I afraid that 2nd option makes the project complex and messy in future.
which is the better option?
I have used myself Laravel with Angular v2+, the way I did was to make two separate projects, one which creates the API's (The Laravel app) and one which consumes the API's (Angular v6 app). That is how it is meant to work and that is how you should approach it.
If you want to integrate the front with the back end, and still have a powerful SPA, then you can go with VueJS, there are vast resources when it comes to the Laravel Vue combination.
another thing to consider is what is this project about?
is it a client website? or just a web app? does it require SEO? beware.
make sure you fully understand (angular) universal and it's current limitations/problems.
UPDATE: I am currently using Angular 6 with with Server side rendering(universal) and a Laravel API as a Backend solution for a complex & highly ranked website in the UK.
You have API routes available which doesn't look for CSRF tokens. Use any JWT package for web token authentication implementation. Host your Angular app separately and send request to API routes.
Your Angular apps are standalone applications. They don't need Laravel for running on server. You just need to use API routes for working with data.
I am working in a project which will have a web, android and iOS application.I have decided using laravel 5.4 to create the web application and also there will the rest api to feed all these app. The api should also be secured so that only my app can access them.
Anyone please tell me from your previous experience what will be the correct way and the best practice to do this
You can use Node.js or Python on which you can develop rest API very easily.The framework like express in Node.js and Flask in python will let you get started with your API within 30 min.After that, you can deploy the API to Heroku to get secure access
If the web, android and IOS application relate to the same project / resources (e.g. database tables, etc.), the easiest way to do this would be a single Laravel project.
In your routes directory, you can have 3 different files (say web.php, ios.php and android.php) to define the routes. Similarly, you can place controllers in separate directories while keeping the Eloquent models/migrations, etc. the same for all three.
To use different authentication methods for all three, you can add custom guards in Laravel.
I would not build anything in larvel and run away form php as soon as possible. Go learn node.js or django. Death to php.
The best current framework to builds apis is Sanic.
Sanic 33,342 Requests/sec 2.96ms Avg Latency
https://github.com/channelcat/sanic
I also like python flask because it is very simple to understand and get something up and running quickly.
Your app currently does not need to be super optimal all you need to is getting working, But best practice wise i think the most important thing for building apis for mobile apps is backwards compatibility.
Sometimes your going to want to update the your app.
Users often don't update the apps. So if you build a new api all the people who dont update their app will get error messages. So just make sure you make a new route with the version name in the prefix in the app. There is alot of other things you can do like rate limiting,Salting your apis and ect. If you dont have that many users don't worry about this yet. Just build it and then latter learn when you need to learn in.
We are planning to develop a web application for job applications. In the first two years we expect the traffic to be about 3'000 - 6'000 visitors per day. At a later stage the traffic will grow up to 10'000 - 20'000 visitors per day.
Is there an advantage in separating frontend and backend (frontend standalone vue.js which calls the REST-API of Laravel) in compare to a all-in-one Laravel application which includes Vue inside the blade templates?
Thank you
If you plan on delivering your product in the form of:
a REST API,
and a frontend application
Then you should definitely come up with two different repositories/project.
Starting with an "all-in-one" application for both backend REST API and frontend application looks simpler, as Laravel comes with Vue.js out of the box. But even if it's helpful regarding frontend, it is focusing on backend, PHP, and Laravel. I bet on your developers mixing backend and frontend pretty soon :)
Consider bootstrapping your frontend application with vue-cli as a standalone project, to get huge benefits from its webpack configuration, and a top-notch (frontend) developer experience. Your frontend application will be better from day one, focusing on its prerequisites: delivering high quality user experience.
laravel is a very performant framework and if you use caching techniques with a good backend architecture it will support the load without issues.
That being said, a client/API will de facto be more performant, since the only thing that will occup the bandwith will be json object instead of full pages, and for the client side you rely upon the client hardware.
Another big win for a client/API approach is for when you will want to develop Ur Mobile/Desktop apps. The API will be ready and you'll be focus on just the new clients u'll have to develop. If u were on a server serving pages and a lot done within the controller/actions returning those computed pages, you will have to extract the API from those controllers and makes those calls the API instead.
I am building an application and currently focusing on the mobile part .
I wanted to use Lumen microframework for the server-side and Apis to connect to the mobile app.
However i also wanted to extend the application later on to build a website (Laravel)
They will both be using the same database .
I am wondering whether i should use Laravel directly and make it responsible for the apis too (albeit it would be slower for mobile apps)
Or i was wondering if i can use a combination of both.
Lumen - to deal with server requests e.g : api.site.com/...
Laravel - to deal with the website e.g : site.com/....
You could do either or, but I would suggest keeping the website and the API isolated.
I actually just finished up a similar project.
I have a mobile app built on Ionic, an API built on Lumen and an admin CMS built on Laravel. The CMS updates content in the API via authenticated API calls and then the app pulls from it.
If you take this route, you could make API calls from the CMS/Website using client side or server side requests. My CMS uses server side calls leveraging Guzzle.
I would suggest looking at sharing models between the two applications such that you don't have to update content via API calls. Here is a nice article on how to do so.
I have a ZF1 project that was developed used the lean startup approach. I'm now ready to move into a more evolved project as I know what my users want, but I really want to develop using better techniques. I've decided to move from ZF1 to ZF2 for support reasons and this is where I'm at:
API(Client) - I have a "push only' API that users use to send me data
API(Admin) - The admins can consume the data pushed using a variety of metrics and aggregates
The API for clients is restful but just pushes into a Redis job queue currently and is processed via cron. This removes the need for clients to wait for their data to be inserted and their requests are returned immediately.
The API for admin is currently not restful and is actually consumed inside of the application only. I think that this is okay as I don't want to have a single page frontend or API consuming front end. I would rather data be returned immediately by the server.
This leaves me with the question of whether I have an API Service Module which provides all of the Models (Doctrine2 ODM POPOs), mappers, filters, and a service layer to access it all and then the controllers that need it can consume the API without making HTTP requests (via service calls).
Is this the proper way to structure or is there a more refined and acceptable approach? I like the service layer in general as testing will be more accurate and all clients / admins are using the same API (if it updates it is essentially updated immediately across the board as there are not separate projects).
I think the module you think of doesn't need to have an own built service layer which only forwards to another service (like Doctrine entitymanager or something else), it rather should only provide the other modules the required services by configuring the DI and encapsulate the required classes (like models, mappers, filters, ...).
In my company for this purpose there is always an 'Application' module (like it was in the early tutorials of ZF2). I dont know if this is still best practice, but there are some serious benefits regarding maintainance and structure.
You should consider defining a module dependency in the 'consuming' modules (like Client-API or Admin-UI).
It is also worth to take a look at the Doctrine library and DoctrineModule implementation, to get a feeling what a module should provide and where it makes sense to only provide a library.