Правильный подход к созданию SAAS в Laravel 4

Хорошо, примерно год назад я написал веб-приложение, которое помогает организовать встречи для моей компании-папы. Теперь он "не мог заниматься бизнесом без него". Я решил, что хочу построить из него подписную модель SAAS и открыть ее для публики.

В настоящее время он построен на codeigniter и php, который, как я считаю, не подходит для версии SAAS. Я планирую перестроить его с нуля в laravel 4 и использовать полосу в качестве платежного шлюза.

Моя забота заключается в том, как лучше всего обрабатывать структуру базы данных/приложения для нескольких клиентов. В настоящее время он просто служит одному бизнесу и очень не абстрактный и специфичен для потребностей компаний-папы. Мне нужно, чтобы он мог обрабатывать разные данные в зависимости от того, что делает бизнес, который его использует.

Я заглянул в мульти-аренда, но я не уверен, что это правильно для этого. Я думаю, что подход стиля "gmail" будет лучше. Одно приложение/домен, который после входа в систему пользователь увидит свою настраиваемую панель мониторинга и только их данные.

Прежде чем я застрял в кодировании, мне нужно разобраться, как лучше всего обрабатывать несколько "учетных записей" в одной базе данных. Я не хочу создавать таблицу для каждого пользователя, а также базу данных для каждого пользователя.

Я думаю, мой вопрос в том, может ли кто-нибудь указать мне в правильном направлении, как лучше всего обрабатывать ежемесячную абонементную оплату в Laravel? Это не столько код, с которым я запутался, а то, что именно мне нужно было бы построить, чтобы каждый месяц обрабатывать клиента каждый день и отказывать им в доступе, если биллинг не удался и т.д.

Спасибо

Ответ 1

У вас много чтения и тонны работы!

Прежде всего, позвольте полностью игнорировать биллинговый аспект этого на данный момент - в конце дня эта часть приложения действительно довольно тривиальна. Возьмите страницу из 37signals Rework (стр. 93 и 94) и запустите свой продукт с 30-дневной бесплатной пробной версией, прежде чем вы начнете ее реализовывать (вы должны знать, как реализовать он к тому времени).

Во-вторых, почему вы считаете, что "gmail" не использует многоуровневую структуру, структура URI ничего не сообщает о базовой структуре базы данных. Я уверен, что они не клонируют схему базы данных для каждого из своих клиентов. Поэтому вы, вероятно, ответили на свой вопрос - , который вы хотите реализовать с несколькими арендаторами.

Вы захотите отвлечь свою базу данных (и архитектуру приложения), и, честно говоря, нет лучшего ресурса, который поможет вам на этом пути, чем книга Тейлора Отуэлла (создатель Laravel) Laravel: от ученика к ремесленнику. Его книга не для новичков, и к тому времени, когда вы закончите читать ее, вы, вероятно, сможете ответить на этот вопрос для себя.

Вы не собираетесь создавать таблицу или базу данных для каждого пользователя, вы даже не собираетесь создавать ее для каждой организации. Вместо этого вы создадите абстрактную структуру базы данных в коде, которая вытащит ваши данные из базы данных.

Подумайте о проверке доступа к организации в качестве другого уровня аутентификации пользователей. По каждому запросу вы будете проверять, может ли этот пользователь получить доступ к определенной организации. Вероятно, вы также убедитесь, что организация по-прежнему активна (она истекает, потому что они не платили?), Это снова произойдет по каждому запросу и, вероятно, с фильтром в пределах laravel.

Это действительно приводит к следующему очень важному моменту разработки приложения SaaS.

Я не знаю о вас, но я параноик, и я не мог хорошо спать по ночам, если бы не был уверен, что номер пользователя 4506 не может видеть данные организации, которые он делает "Я принадлежу". Единственный действительно хороший способ обеспечить это через модульное тестирование, которое я бы настоятельно рекомендовал узнать, если вы еще этого не сделали.

Лучший способ сделать это в Laravel 4 - прочитать книгу Jeffrey Way Laravel Testing Decoded. Эта книга чрезвычайно продвинута, но все еще легко понять, если у вас есть хорошее понимание основ.

И последнее, но не менее важное: первое, что входит в сообщество, - самый простой способ, который я предлагаю сделать на холостом ходу на канале #laravel IRC (Freenode). Задайте несколько вопросов, возможно, ответьте на некоторые вопросы, все в канале очень приятны и отзывчивы.

Вы определенно находитесь в приключении, не бойтесь задавать вопросы и делать ошибки. Удачи.

Ответ 2

В качестве приблизительного обзора у меня будет таблица клиентов и таблица подписки. Любые другие данные, которые требуют хранения, такие как контакты или встречи, могут быть связаны с использованием внешних ключей в таблице клиентов.

В laravel вы можете использовать ORM для получения текущего зарегистрированного клиента, а затем через отношения, выбрать назначения и контакты, принадлежащие им.

Есть несколько полезных инструментов для laravel на cartalyst.com, в том числе часовых и сторожевых для пользователя auth, а также для интеграции учетных записей пользователей с facebook/google/twitter и т.д.

Stripe позволит вам настраивать повторяющиеся платежи и будет уведомлять вас через веб-крючки каждый раз при попытке платежа. вы можете зарегистрировать их в таблице платежей и связать их с пользователем/клиентом. вы можете использовать это, чтобы отслеживать, кто заплатил, и как недавно.

Кроме того, имейте в виду, что вы не можете немедленно отменить учетную запись при неудачной оплате.

Stripe повторит попытку, и может случиться так, что ваш лучший ответ будет после двух или трех дней опоздания или вы получите недопустимое уведомление о карте, чтобы связаться с клиентом и попросить их обновить свои платежные реквизиты.

Это может быть также возможность проверить, когда они в последний раз вошли в систему. Если это было более месяца назад, вы можете кредитовать их бесплатным месяцем и напомнить им, сколько для них может сделать ваше приложение. Делая это, вы можете заставить людей продолжать использовать (и платить) за то, что они забыли, на которые они подписались.