I'm building an SaaS application in Laravel-5. Basically, I want our client to be able to point their domain to our name servers and effectively the application will load their website template (which will vary from client to client). It will also allow our clients' members to login to their account through their website and load all of their personal details.
Is this possible in Laravel-5 and can anyone point me in the right direction?
There are several ways to support multi tenancy in laravel.
Using middleware you can dynamically mutate the request object to modify behavior of the application.
By modifying the path locations you can then change where views and almost anything else is loaded from.
Landlord, a single database multi-tenancy package for Laravel & Lumen 5.2+.
Another proven package is Tenanti which handles custom database connections and even observes models to track changes to different database connections.
I'm currently maintaining a multi tenancy package for Laravel that allows complete division of responsibility for databases, files etc while maintaining a system connection for system wide settings and hostname setup.
Deprecated:
If you only want to have one database that stores all tenants, you might be interested in AuraEQ, I'm not sure there should be others. Is now Landlord.
Related
I am new to microservices, I only know the theory, developed some local examples, and also deploy them to AWS, but just that, and I have a project that has to be done with microservices, but my question is about the structure.
For example, I am planning to do the following:
Vuejs SPA for the frontend store in AWS S3- this will make the request to the Main Laravel app
the Main Laravel app to manage the authorization(login, register, password recovery)
When the user is logged in, is redirected to the "posts" page and that page loads all the posts, you can create new posts, delete them, add comments, etc. This would be another Laravel app, another microservice
Then I have another Laravel app for the user profile, where the users can update their information and also monetize their posts with given options
So, this is my plan:
a SPA stored in S3
a microservice for the Main app that handles authorization, this will be stored in lambda
a microservice for posts, this will be stored in lambda
a microservice for monetization, this will be stored in lambda
I am planning to use serverless so I am a little bit confused.
Where should be the AWS API gateway in the SPA or Main app? or how can I configure it
Should I use only one database and each microservice connect to it?
Should I use different databases? if so, can I how can I synchronize them
If a user logs in to the Main app, it generates a token with sanctum or passport, then this token is sent in the header request to the posts or monetization microservice, is ok this approach?
Should I install a Sanctum or passport?
Should I install Sanctum or passport in all the microservices or only in the Main app?
What can I do? thank you.
If I understand correctly you have one UI communicating with multiple microservices in the backend.
Since you are using serverless, a microservice is probably a set of functions around one functionality that are deployed together. That is totally fine.
In general you will want to have a separate storage area for each microservice. If they are physically different databases or not does not make the big difference in cloud environments because you can always change it according to your needs. The important point is that the storage area is encapsulated by the services. This might mean each microservice has an area within a database that noone else has access to.
This also means you have to use interfaces to get data of other microserivces. There are basically two ways to do so:
synchronously API use of other microservice to retrieve data.
asynchronous data replication via a message bus (event-driven architecture).
For token-based auth: your Main app will create an encrypted JWT token using a private key including user information like email, etc. This token has to be stored in the client and sent to other microservices via a header with every request. They can use decryption mechanisms to ensure the validity of the token and need the public key of the Main app for this. You might consider enter link description hereAWS Cognito libraries because they to that job for you
In general, you should overthink using microservice since they are no silver bullet. You should ask yourself the following two questions:
Do I need to scale development? (e.g. 50 developers +)
Do I need independent deployment/service evolution?
If the answer is "no" to these questions you might consider using some best practices of microservices, but I'd advice against introducing the full overhead of microservices. You could also just have some serverless functions working on a common database.
I'm new to Laravel.
I'm working on a project which involves a public facing website and back-office application. Both are web applications and suppose to be hosted on different domains.
Website - the Public facing website using the database to pull data.
Back-Office - Backoffice or Admin app to create/update/delete stuff again using the same database should have it's own RBAC.
The reason for keeping these two apps separately is so that on the public facing website we don't push unnecessary code and keep it lean and clean. However, both of them are using the same database so I want to create a module/app/plugin (Not sure how to name it in Laravel) which can be shared among both applications for database models or any other business logic which can be shared between both apps.
Any idea how to achieve that with laravel framework?
Based on my experience, the most obvious approach would be to have one backend (API) used by the two frontends.
API : Exposing REST endpoints, configured with proper authorizations (some endpoints would only be for admins users).
Website : A classic website (SPA or not) interacting with the business logic through the API.
Back-Office : Same story as the website.
It's somehow a microservice architecture. There is a lot of pros and cons for it, but considering you don't want to push unnecessary code, spreading into different apps seems like appropriate.
If you want to keep one code base, I would consider having a load balancer (like HaProxy or Nginx) in front of your Laravel app to handle requests from configured domains to appropriate routes. For example :
acme.com root would be / for Laravel
bo.acme.com root would be /admin for Laravel
I'm developing a system using Yii framework and mysql
and after finishing it i'm going to develop another one.
Those two systems should be shared with the same authentication module.
And maybe there are more systems coming up.
But I don't want to have two separate module for each project doing the authentication and authorization and I don't want to assign each user two passwords.
I'm searching for a mechanism to make the A&A process done with one external and shared system and let those two systems communicate with this system to get the rights for the current logged in user.
You need to implement SSO (Single Sign On) or to use some other method to overcome this.
Check here for a simple guide on how to implement SSO: http://merbist.com/2012/04/04/building-and-implementing-a-single-sign-on-solution/
Also check some enterprise implementations like http://www.onelogin.com/
Finally some open source implementations will probably help you like https://github.com/jasny/sso
This will look like range of questions but all are related to SaaS and PHP based application we have been building. We are conscious about our application architecture and studying it so that we ensure to encounter all essential techniques before we move to production and do not face any failure.!
To support SaaS we have decided to make our database multi-tenant where each customer will have its own database. My mind is boggling around following list of questions further.
How to provide ability to customize a SaaS multi-tenant application to suit individual tenant needs?
How to ensure security of each tenant database so that they do not access each other's data accidently?
What are clusters and how do we add new instances of application and database to them in case of increasing no. of customers?
What do we do to ensure performance and scalability of SaaS website?
How do we handle failures of SaaS application, especially when we launch new versions and updates, (continuous integration)?
Any special solutions for handling subscribers/customers and permissions of activated and deactivated modules in SaaS application?
I have attached block diagram of DB we have decided to go with
I have written a good article with many of the items which we need to consider while developing a SaaS application in PHP. Check the SaaS application development using PHP in Zend Framework
Answers to some of your questions are below:
How to provide ability to customize a SaaS multi-tenant application to suit individual tenant needs?
Its like a normal site development. Suppose you have resources A to Z then you need to keep the assigned or accessible resources of reach Tenants inside database. Then while accessing you can simply check the permissions.
How to ensure security of each tenant database so that they do not access each other's data accidently?
The database design on SaaS application is a topic which is discussed lots of times on Stack Overflow. You can go with Single database or unique database for each Tenants. For Big Projects the second one is suitable.
If you are going with Single Database, simply store the TENANT ID in all tables. And then while Authenticating the Tenant, keep the TENANT ID in SESSION based on the Sub Domain which the request coming from. Then pass this ID in all database operations and thus, it doesn't affect the data of any other Tenants accidentally.
My company creates a lot of applications that have very similar functionality, with a few differences between each one. For example, some sites have a group creation feature, others have user profile pages, and yet others allow users to accumulate achievement points and such.
Our clients want users to be able to log in to each application with the same username/password, since it doesn't really make sense for the user to have to register a different account for each site.
How do we design our database? Is it better to have a single central database for all of our applications, or separate them into individual databases and do JOINs across databases? Which is better performance-wise and design-wise?
Thanks for any insight!
Just go with OpenID. Simplest to just use Facebook Connect as a provider. They let you get to all of your user's data (like name etc.) so you can identify and data mine them if need be.
If you don't want to rely on an external provider to handle your user accounts, then become your own OpenID provider.
I would have a central server, which hosts a user db and web services to access that user db.
That way you can use the same DB, and perform logins over web services to that system from your front end.
This is also scalable and can grow in complexity with your applications.
I would take the other two answers and combines them to make a private OpenId Provider.
This way you can use the standard OpenId clients for your developments, and possibly even open your applications up for external OpenId providers if you developments need them.
This gives scalability and open standards for other applications within the organisations to use the same provider.
In a general way I would develop tables that would be Master Data, they will be single version of the truth application wide. Each and every application will access the same "clients base". In your case it seems that the concept of Master Data can be applied to your applications database.
If the applications are hosted within the company you can use active directory.
You can access active directory from php with the ldap functionality. You can than add users to groups in active directory to give them access to various functionality within the application.