Jump to content

SAAS strategy


spoetnik
 Share

Recommended Posts

I am building a SAAS solution based on Processwire.

For example it's an intranet hosted on the internet (just for example)

I have the following deployment strategies:

  1. 1 Processwire install per client. With separate Databases, Assets folder, and maybe ElasticSearch instances in the future.
  2. 1 Processwire install for all clients. A reference field on all templates to a "Client" field, so I can relate content to a client. Set the clientID in the $session for all loged-in users, so I can check their permissions.

I am considering the first option for the following reasons:

  • All results from a search action are for the correct Client.
  • Strong separation of confidential content

Arguments for the second option would be:

  • Maintenance is much easier

Any insights, tips??

Link to comment
Share on other sites

One consideration -- if you anticipate customized instances, with different fields or templates for the various clients, you may run into scaling issues as you grow the site with a single install. That said, if every client is on a unified template/field setup, this isn't an issue.

Link to comment
Share on other sites

Yup - the guys at Basecamp had an interesting thing in one of their books about doing customised work early on and eventually switching to the same features for everyone.

They said it hurt some relationships with earlier clients, but if you are expecting any decent numbers of signups to the SaaS offering then you will tear your hair out doing lots of custom work when you could be focusing on building features for all of your clients.

Doesn't mean you shouldn't have some sort of feedback system to gauge what's constantly being asked for - that's a good idea - but work out how popular you think it will be and make your decision from there.

You can do Option 1 but use symlinks (I think it's symlinks?) to only ever have one /core/ folder. I'm not sure, but you may even be able to do something with modules that you always want to have available in the /site/ folder too, but it's too early in the morning for my brain to be able to work out the mechanics of it :) Needless to say there will be some way of having their own assets folder but just one copy of everything else.

EDIT: In fact I think this is what you meant with option 1 already as you only mentioned separate database and assets folder.

Link to comment
Share on other sites

You can do Option 1 but use symlinks (I think it's symlinks?) to only ever have one /core/ folder. I'm not sure, but you may even be able to do something with modules that you always want to have available in the /site/ folder too, but it's too early in the morning for my brain to be able to work out the mechanics of it :) Needless to say there will be some way of having their own assets folder but just one copy of everything else.

The symlink options works fine. You just have to understand and configure your permissions accordingly. This is how lightning.pw works (We have a /wire/ folder for every PW version and a /site/ folder for every customer install). You can put modules in there too.

  • Like 2
Link to comment
Share on other sites

Thanks,

I think that I will go for option 1: A new install for each client. There will be no custom instances, so a deployment on based on a Git Pull will work nice.

Second question. How would you handle agile development?

Not all development takes place in File. Field are created, and added to templates. All in Database.

How would I deploy new features to running installs, and not destroy the data in the database?

Link to comment
Share on other sites

Not all development takes place in File. Field are created, and added to templates. All in Database.

How would I deploy new features to running installs, and not destroy the data in the database?

Not sure exactly what your needs are, but maybe take a look at Migrator - it might be able to do what you need in terms of adding newly developed features. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...