在Laravel 4中构建SAAS的正确方法 [英] Right approach to building SAAS in Laravel 4

问题描述

好吧，所以大约一年前，我写了一个网络应用程序来帮助安排我父亲公司的约会。他现在没有它就无法开展业务。我已经决定要构建一个SAAS订阅模型，并向公众开放。

Ok, so about a year ago I wrote a web app that helps organize appointments for my dads company. He now "couldn't do business without it". I have decided that I want to build a SAAS subscription model out of it and open it up to the public.

它目前基于codeigniter和php构建，我认为这不是非常适合SAAS版本。我打算在laravel 4中从头重新构建它，并使用Stripe作为支付网关。

It's currently built on codeigniter and php which I do not think is a good fit for a SAAS version. I am planning on rebuiling it from scratch in laravel 4 and using stripe as a payment gateway.

我的关注点是如何最好地处理多个数据库/应用程序结构客户。目前，它仅服务于一家公司，并且非常抽象，并且专门针对我父亲公司的需求。我需要它能够根据使用它的业务用途来处理不同的数据。

My concern is how best to handle the database / application structure for more than one client. Currently, it just serves the one business and is very un-abstract and is specific to my dads companies needs. I need it to be able to handle different data depending on what the business who uses it does.

我已经研究了多租户，但是我不确定这是为此。我认为采用 gmail样式的方法会更好。一个应用程序/域，在登录后用户将看到他们自定义的仪表板，并且仅显示他们的数据。

I have looked into multi-tenancy but i'm not sure this is right for this. I am thinking that a 'gmail' style approach would be better. One app / domain that after login the user will see their customised dashboard and only their data.

在坚持编码之前，我需要确定如何做到最好在一个数据库上处理多个帐户。我不想为每个用户创建一个表，也不想为每个用户创建一个数据库。

Before I get stuck in with the coding I need to work out how best to handle multiple 'accounts' on the one database. I do not want to create a table for each user, nor a database for each user.

我想我的问题是，有人可以指出正确的方向以达到最佳效果吗？在Laravel中处理每月付款订阅？并不是我在努力处理的代码，而是我需要构建什么来处理每月向客户收费以及在计费失败等情况下拒绝他们访问的需求。

I guess my question is can anybody point me in the right direction for how best to handle a monthly payment subscription in Laravel? It's not so much the code that I'm stuggling with, rather what exactly I would need to build to handle charging the customer each month and denying them access if billing failed etc.

谢谢

推荐答案

您需要大量的阅读和大量的工作！

You are in for a lot of reading and a ton of work!

首先，让我们暂时完全忽略它的计费方面-在一天结束时，应用程序的那一部分确实相当琐碎。从 37signals Rework （第93和94页）中取出一个页面，并以30天免费试用期启动产品在您甚至没有开始实施它之前（您应该那时知道如何实现它）。

First of all, let's completely ignore the billing aspect of this for now — at the end of the day that portion of the application is really fairly trivial. Take a page out of 37signals Rework (page 93 and 94) and launch your product with a 30 day free trial before you even begin implementing it (you should know how to implement it by then).

第二，为什么您认为 gmail不使用多租户，URI结构不会说明基础数据库的结构。我相当有信心他们不会为他们的每个客户克隆数据库架构。因此，您可能已经回答了自己的问题-您要实现多租户。

Second, why do you think that "gmail" doesn't use multi-tenancy, URI structure tells nothing about the underlying database structure. I'm fairly confident they aren't cloning a database schema for every one of their customers. Therefore you've probably answered your own question — you want to implement multi-tenancy.

您将要抽象数据库（和应用程序体系结构），说实话，没有比Taylor Otwell（Laravel的创建者）的书 Laravel：从学徒到工匠 。他的书不适合初学者使用，到您读完这本书时，您也许应该可以自己回答这个问题。

You're going to want to abstract your database (and application architecture), and honestly there is no better resource to help you on your way to doing that than Taylor Otwell's (creator of Laravel) book Laravel: From Apprentice To Artisan. His book is not for beginners, and by the time you're done reading it you should probably be able to answer this question for yourself.

您不会为每个用户创建一个表或数据库，您甚至都不会为每个组织创建一个表或数据库。取而代之的是，您将在代码中创建抽象的数据库结构，这会将您的用户数据从数据库中拉出。

You are not going to be creating a table or a database for each user, you aren't even going to be creating one for each organization. Instead you'll be creating abstract database structure in code, which will pull your users data out of the database.

考虑检查访问组织作为另一层的权限用户身份验证。根据每个请求，您将检查该用户是否可以访问特定组织。您可能还会检查以确保组织仍处于活动状态（因为他们没有付款而过期了吗？），每次请求都会再次发生这种情况，并且可能使用 laravel中的过滤器。

Think about checking for permission to access an organization as another layer of user authentication. On every request you'll be checking to see if that user can access a particular organization. You'll likely also check to ensure that organization is still active (did it expire because they didn't pay?) this will again happen on every request and likely with a filter within laravel.

这确实导致开发SaaS应用程序的下一个非常重要的因素。

This really leads to the next very important factor of developing a SaaS application.

我不了解您，但我很偏执，如果不确定用户编号 4506，我晚上无法入睡无法看到他不属于的组织的数据。确保这一点的唯一真正好的方法是通过单元测试，我强烈建议您学习是否还没有。

I don't know about you, but I'm paranoid, and I couldn't sleep well at night if I wasn't sure that user number 4506 couldn't see the data of an organization that he doesn't belong to. The only really good way to ensure this is through unit testing, which I'd highly suggest learning if you haven't already.

在Laravel中做到这一点的最佳方法4是阅读Jeffrey Way的书 Laravel Testing Decoded 。本书非常先进，但是如果您对基本原理有很好的理解，还是很容易理解的。

The best way to do this within Laravel 4 is to read Jeffrey Way's book Laravel Testing Decoded. This book is extremely advanced, but still easy to understand if you have a good grasp of the fundamentals.

最后但并非最不重要的是，第一件事涉及社区-我建议这样做的最简单方法是在 #laravel IRC频道（freenode）上闲置。问一些问题，也许回答一些问题，频道中的每个人都非常友善且反应迅速。

Last but not least, the number one thing is get involved in the community — the easiest way I'd suggest doing that is idling on the #laravel IRC channel (freenode). Ask some questions, maybe answer some questions, everyone in the channel is very nice and responsive.

您肯定会冒险的，不要害怕提问并犯错误。祝你好运。

You are definitely in for an adventure, don't be afraid to ask questions and make mistakes. Good luck.

这篇关于在Laravel 4中构建SAAS的正确方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！