I'm looking to recreate some internal systems using Laravel 5.3 as the internal systems need rebuilding. I am still fairly new to Laravel as we have used a bespoke framework based on PHP 4 for a few years, which is starting to show its' age.
The current setup makes use of having a users table for each application, which from my knowledge is not efficient as the userbase is shared (open to all employees).
Would I be right in thinking that I can set up a Lumen application, with a database of users, and then use Laravel Passport to make it an OAuth2 server? Say for example, passport.company.com and then new users are registered via this application.
Therefore, another two applications using Laravel i.e. CRM and CMS can then use the Passport system for authentication, rather than having to create users tables for each application?
If this is on the right lines, or there are better alternatives, I would be grateful to hear your feedback.
Thanks!
Edit: It appears that I'd need Laravel for all applications and not Lumen, after reading further into it.
I'm still curious as to know if I am on the right track however?
Related
I have been developing a website that uses Laravel (v6) on the backend, and Nuxt.js (v2) on the frontend. The idea was for laravel to act as an api & oauth2 server, that also server side rendered the Nuxt.js app. From my research, it seemed like this was not only a common route, but not too much hassle to implement.
While developing, I have kept the backend and frontend as completely separate projects with their own git repos and all that jazz. This is my first time deploying/developing a project like this, where there are two completely applications for the backend and frontend, so all this is very new and a little challenging at times. Now when it came time to deploy them, I always imagined that I would somehow merge the projects and that I would be able to setup Laravel to server side render the Nuxt.js app. However, I am now at that stage and trying to merge them with great difficulty.
Currently I am using the "laravel-nuxt" composer package and "laravel-nuxt" npm package in an attempt to connect the projects in one repo. However, I am having difficulty doing this. I've searched far and wide for a good resource on this process and have yet to find one that explains the process thoroughly. I even purchased a course on Udemy on the topic only to find out they didn't merge the projects! They deployed Nuxt to firebase and didn't even cover how the deployment of laravel.
Anyway, this is my question(s): should or could I keep the projects separate and have 2 completely separate deployments? Or rather, if I keep them separate, how do I deploy nuxt in a way that still gets server side rendered? To me it doesn't matter if they are separate or together, but the most important part is that the nuxt app utlitlizes SSR (server side rendering) for SEO purposes. So am I on the right track? Should I keep these projects separate or should I continue trying to merge them?
Sorry if this is unclear, I am rather frustrated and kind of losing my mind. I would really appreciate any feedback or point in the right direction. Thank you for your time in reading this, and I otherwise hope you have a good day :)
I recently developed something with a similar structure, Nuxt.js frontend and Directus CMS as backend.
I kept backend and frontend separated repositories and also deployed both separately. The reason why I decided to do it that way was because both need different packages on the server side and use different eco systems.
Frontend needs only Node.js backend needs a webserver, database and PHP. I think this should not be mixed.
For backend I used my existing server where I already have stuff running like Nextcloud or a blog behind a nginx webserver.
For frontend I used Dokku which I can only recommend for deploying Node.js apps. Nuxt.js has instructions on how to deploy to it.
Most important for you is that SSR is done by Nuxt.js, you don't need a separate webserver for that. Just build it and use npm start. Depending on your installation/deployment you have to use nginx as proxy to avoid calling the app with a port number. Another thing that Dokku does for me automatically, if the app respects the PORT environment variable.
I am a student and I'm making a project, an application which will show data to users on web end and also on android application. but I am confuse which one to choose for backend development, Laravel or Lumen ? My application will have signup function and displayed data from mysql against search queries. There will be 4 to 5 tables and multiple columns in each table. also images to show. So which one I should choose?
From what you have described so far Laravel seems like a perfect fit. Start off with laravel, if you need more speed and a framework focused towards building web services give lumen a try. If you haven't worked with PHP or any other backend app before, go with vanilla PHP.
Goodluck with the app!
If you only need to build an API use Lumen, otherwise Laravel
Well, I recommend Laravel rather than Lumen (Frankly speaking, CI framework may be more suitable, which is simpler and friendly to new user). About 1.5 years ago, I experienced the same dilemma, just like you. For lacking of enough document, I have to migrate my project from Lumen to Laravel when I came across some problems.
For an existing PHP application, that doesn't make use of any frameworks... is it possible to add/integrate Laravel based authentication to it without trying to convert the entire PHP into a Laravel application?
I am a complete PHP newbie, and was hoping for someone to point me in the right direction. Much appreciated.
Of course you can add JWT to your existing PHP app, it's not "locked" to Laravel, far from it. Most of the frameworks that have these capabilities built in are just supersets of various components to make life easier for developers. You can of course implement these on your own in your application, given that you have the knowledge how to do so.
Since this is a bit abstract question without any provided examples, some answers with code snippets might just confuse you. Instead here are some resources where you can read more on the subject and get going: Sitepoint, JWT in PHP App and PHPClicks Token Based Authentication.
Another approach would be to craft a new Laravel project (or Lumen project if it's only a API and you don't want to render views) and import the current codebase from the other application to it.
If you want to make life easier for you, you can use some SAAS alternative for Authentication like Auth0.
Our setup is this:
We have and API that feeds an iOS and an Android app
We have an Admin API that feeds an Admin web app
I'm developing the Admin, my colleague is developing the app API.
They both use the same database, and most of the same tables. Merging them into a single project is not an option as we will deploy to Elastic Beanstalk and the Admin doesn't need to scale, since it will be used by a small number of people.
The issue we ran into is handling migrations, and we've arrived to the following conclusions:
We can't both have our own migrations in our projects, as the versions would not add up
If we keep migrations on only one of the projects (we both have access to both projects), the project without migrations can't be redeployed without redeploying the other one
If we make a 3rd project that only has migrations, we are hosting an application that essentially doesn't do anything
While I can think of hacky ways of fixing this issue, we're looking for a best practices approach.
I would recommend the option of creating the third project that only has migrations. That way, you keep all the migrations in one place and avoid problems of inconsistency, and you decouple the migrations from the deployment of either app. The fact that the app doesn't "do" anything shouldn't matter; you don't need to deploy an extra app, just run the migrations from your deployment server. You don't actually have to create a whole Laravel project just for your migrations; it's fairly simple to use Eloquent outside of Laravel. This article gives an example of using the Eloquent query builder to run migrations outside of Laravel. You could also use a lightweight migrations tool like Phinx, which offers a similar feature set to Laravel's built-in migrations but with minimal dependencies.
I'm looking for a way to build a php application (in Laravel) that reuses the existing users we have in a Drupal installation.
I found two suggested solutions on stackoverflow:
1) include the Drupal bootstrap and use their user_authenticate() method.
One thing I suppose will be a problem is that our PHP application is running on a different server. This approach will probably not work in such a case or can that be fixed by pointing to the Drupal sql server?
2) use the Drupal services module to authenticate users over REST
This might work over different servers/domains I suppose, but there won't be a way to automatically login users in our php app that are already logged into Drupal, or am I wrong.
3) synchronise the Drupal user data to our own SQL server
This would be a final resort, since this won't solve automatic login.
Are my thought correct in these situations. What would you suggest doing when Drupal and the PHP app are on two completely different servers/domains?
I ended up writing a custom provider in Laravel.
If you're interested in doing the same thing, here's what I did: Create a custom Drupal 7 authentication driver/provider in Laravel 4