I wonder about the possibility to use Vapor for an API (which will be called from a separate web app) and Nova. But I wonder if Vapor is made for that given that there is a limitation on the number of concurrent calls and also that Nova seems to make many calls. I don't want to start on a solution if I'm blocked afterwards because too many lambdas are executed due to a too big number of users.
I would have liked to know if there is something which escapes me about Vapor or if it is not the adapted solution and that it is preferable to leave with Forge for example.
Related
I have an API in Laravel that only consume in my frontend. The problem that arises for me is how to authorize the use of the API to a single application without revealing information that other applications may apply to make use of it (an example of this would be sending a header, which can be obtained and replicated).
I understand that with Passport I can get it but it seems to me to be a very sophisticated solution for a case where I will only need an authorization and I would just like to know where to look since I can't find anything. Sorry for my bad English.
Developing a SPA in the frontend (with Vue.js) which consumes endpoints from a (Laravel) API in the backend introduces some challenges that need to be tackled:
1. How to sync deployment when introducing new backend/frontend code
If the code is separated in two VCS repositories (frontend/backend) it can be challenging to sync deployment of both frontend and backend making sure that both finish at the exact same time. Otherwise this can lead to unexpected behaviour (e.g. calling endpoints that are not yet deployed or have changed). Anyone came up with a great solution for this? What is your best practice to tackle this problem? What if versioning every little change is not an option?
2. How to make sure that the frontend code of the SPA is being refreshed after deployment?
So you managed to keep your deployments in sync (see problem 1.), but how do you make sure that the SPA code of every currently active end user is being refreshed? With webpack code splitting enabled, the application might break immediately for users that are currently using your app in between a deployment.
How do you make sure that your users are being served the latest JS without having them reload the entire application on every request? What are best practices (besides forcing the user to refresh the entire page via websockets)? Are there solutions that allow currently active users to keep using the application without being forced to refresh while they might just finished something that's ready to be saved?
I am very interested in your findings, learnings and solutions!
1. How to sync deployment when introducing new backend/frontend code
The best practice here is to keep the backend and frontend in the same repo. You can, of course, extract some reusable code out of them to use in other projects but the code base should ideally be in the same repo or you will keep facing these frustrating code sync issues. Even if you look at popular Laravel libraries - they all have the frontend and backend in the same repo.
If that's not option, I would suggest that you use a versioning system that can link the versions of both repos. Yep, that means versioning every little change!
2. How to make sure that the frontend code of the SPA is being refreshed after deployment?
Usually, I'd avoid doing stuff to force a refresh on the client codebase but if you have long user sessions, it may actually make sense.
To do that, you can use any web socket implementation (such as Pusher) and have your CI notify the frontend through web sockets of any deployment. The frontend can then queue a page refresh. Check out this article on how to implement.
The two questions are tightly coupled and can't be answered separately in my opinion. I have some possibile strategies to deal with such a scenario:
1. Never introduce breaking changes in the API
API deployments should be incremental without breaking anything for users using the previous version. In this way you can simply push the changes on your backend and when the backend deployment is completed you deploy the frontend. Easily achieved if you have separate projects.
This can be performed for major releases by prefixing the API with the version:
https://website.url/api/v${version}/${endpoint}
while minor deployments should only be minor adjustments/bugfixes that do not break frontend functionality.
This approach is the best because it ensures absolutely no downtime in the user activity, but requires additional work and may not be feasible in many projects. If the backend does not introduce breaking changes, you can implement a simple polling system (with a long timespan, such as minutes) from the frontend that detects if a reload in necessary to load the new frontend deployment.
2. Standard response for outdated requests
Each request from the frontend includes an information about the version in use by the frontend. It could be a standard header, a param, whatever. You should wrap your requests in a function that add the information before sending the request itself.
If the server detects a request from an outdated frontend, it returns a standard response, such as:
{
"error": "update required"
}
The frontend detects the error and reload the page
I honestly don't like this approach, because the request may be a POST request with some form data and a page reload may lose the user all their input, which is annoying.
1. How to sync deployment when introducing new backend/frontend code
With a staging environment where you run both test suites before pulling on production.
2. How to make sure that the frontend code of the SPA is being refreshed after deployment?
Don't just break your API. Implement a grace period. For example, you could check for updates on every request, then notify the user that a new version is available so that they have to click a button at their earliest convenience. Record the used client version in your DB. Once all your users are updated, you can delete the old endpoints.
Our company is about to start a real estate project and have decided to go with the laravel 5.3 framework. The first phase is to write the apis and then these apis will be consumed by the mobile team and the frontend team to build the official mobile app and the web portal respectively.
Now I am confused whether to use laravel's built-in Resource controllers (as instructed in this tutorial http://www.programmableweb.com/news/how-to-build-restful-apis-using-php-and-laravel/how-to/2014/08/13) or use the Dingo Api framework.
Could you please help me which one should I go for and why as per the requirements i mentioned above?
Thanks in advance
Since, Laravel 5.3 comes with Passport (for api authentication), I would suggest you to use Resource controller, which is very simple and easy to work with, and also it create a meaningful end points
Route::resource('post','PostController');
GET /post/{post}
POST /post
EDIT /post/{post}/edit
DELETE /post/{post}
I'm currently developing a web application and I expect a lot of visitors (potential thousands of concurrent visitors). For this reason I prefer the Lumen Framework over Laravel because of the size and better performance. But I miss some things that are excluded from Lumen since the last version, like sessions, views and session authentication.
So I have a choice: using the heavier Laravel framework, or use Lumen and add some Laravel components I need. My question is: what is better?
I know I can test some things on my own but I'm not that experienced and I'm wondering if anyone has some good pros or cons (or if you have another alternative I'm curious too).
I recommend you use Laravel for your purpose. Lumen 5.2 doesn't have views, sessions and can be a bit frustrating create a big website. And since the new version, not her philosophy. Lumen is now focused on JSON API's.
Only Stateless APIs
Lumen 5.2 represents a shift on slimming Lumen to focus solely on serving stateless, JSON APIs. As such, sessions and views are no longer included with the framework.
If you need access to these features, you should use the full Laravel framework.
https://lumen.laravel.com/docs/5.2/releases#5.2.0
If you need an API, is the perfect place to use Lumen. Share the database with the Laravel app (that will contains all the business logic) and you will have a fast API
Taylor Otwell recently released a new framework called Lumen. I am a big user of Laravel.
Can any one point out the difference between Laravel and Lumen micro framework.
What is micro framework all about and when should one use it.
Laravel is doing quite a lot of initialization during each request. With Lumen processing each request is much faster so it is supposed to be able to handle even more load than Laravel with all its caching.
This means that Lumen is less configurable but is able to handle more requests per second.