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

Около года назад я написал веб-приложение, которое помогает организовывать встречи в компании моего отца. Теперь он «не мог вести бизнес без этого». Я решил, что хочу построить на его основе модель подписки SAAS и открыть ее для публики.

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

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

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

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

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

Спасибо


person Chris Till    schedule 17.08.2013    source источник


Ответы (2)


Вам предстоит много читать и много работать!

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

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

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

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

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

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

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

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

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

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

person tplaner    schedule 17.08.2013
comment
Спасибо, какой блестящий ответ. Для меня этот проект - это не только развитие моих навыков разработчика, но и создание продукта. Я рассматриваю это как оправдание, чтобы использовать много вещей, которых у меня раньше не было, и своего рода игровую площадку. Ваше здоровье! - person Chris Till; 18.08.2013
comment
Отличный отклик от Evolve. Я бы добавил, что самый важный элемент любого SaaS - это структура данных. Это сделает или сломает Saas, если вы начнете интенсивно использовать и вам нужно будет быстро масштабироваться. - person Peter Drinnan; 16.01.2015
comment
@evolve, есть ли у вас новости по той же теме? Я просмотрел эти книги, но они устарели = / - person cbcaio; 29.12.2015

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

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

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

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

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

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

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

person MCannon    schedule 17.08.2013