[coldbox:15227] SaaS Concept in ColdBox

Hi Mike,

I have a SaaS app underway in CB and it works very well. I have the module called SaaS which handles all non app specific stuff.

I use an on request start interceptor to pull the sub domain from the CGI and load the appropriate account into the request collection for use throughout the rest of the request.

Still early progress but seems to work well.

Robert

Thank you all for these responses and the assurances the thoughts carry. More are always welcome.

Jonathan, you mentioned:

" I’d build it as modules for maintenance purposes but really you should just use a pre handler to do permissions to access modules. You don’t really want to load and unload modules based on a site "

this suggests to me that I might be missing something about modules and their purpose in an application. In particular the pre-handler to access modules. Can you simply elaborate on what that means or point me to some documentation on the practical application of modules in a CB environment? I’m going to delve further into the modules documentation to find out more but perhaps there is something else?

Thanks,
Mike

He was speaking about two different solutions.

1 - Would be to develop each feature/package as a module
2 - Would be to simply have each feature/package as it’s own handler and use a preHandler() method to authorize access to the events in the handler (this is the simplest solution).

ah…I see. After reading some and looking at some module samples, I thought modules made the most sense because you could ultimately segregate all the code for an application feature. For example, this client wants to have several kinds of searches for data available to the hosted client and several of those search features could have some pretty custom ways of looking at the data (say mapped results via google maps) as well as ways of securing some options for authenticated vs. public users.

I think now what I’m seeing is that perhaps the search feature is a handler to manage the workload…of course it would likely be split into the view, handler and models directories and perhaps a module that could be created would be for the one that handles the google map. this way, if the hosted client bought the mapping service, the handler for the search could be designed to check to see if the module is available to the client and provide UI to access it.

One of the goals I think the client is thinking about in using the SaaS idea is that “core” code, once established will NOT have to change to add new features. I know this is not entirely realistic because the module cannot impose interaction to the handler feature, the handle feature has to request it…but it could at least minimize that kind of “core” change AND provide UI that would not have to mingle with core UI code.

This, then would bring me to what I see as the next most logical question…what are some best practices for what one should use modules for then? Security seems obvious, though not necessary and I don’t see anything that would be treated as a “module” being reused in other products…all features and product lines would likely be just in this one large SaaS application.

Thoughts on that?

Mike

Mike,

One of the things that one needs to take into consideration, is that SaaS (Software as a Service) is not reliant on any technology, in other words you can write SaaS with any language or framework.

With Coldbox, this doesn’t mean that Coldbox can’t do what you are looking at achieving.

What you need to do is sit down and work out how you are going to deploy this, and make it available to your clients. That means security, what is displayed if anything, or just returning data that the client will display.

Many factors are involved.

Modules in Coldbox do make SaaS easier because you can add modules to your SaaS, and then define who has access and who doesn’t with greater ease. Whether it is Coldbox or not, you still need to take the security and access into consideration.

So lets say hypothetically speaking, you create a module, which is just to provide map locations. Then you would design this to the technology and framework in question that you choose to use. Coldbox makes this easier, because you can before the module is called, see if the client has the rights or no longer have rights to use that service. How you do that is not Coldbox specific, but can be made easier because of the framework.

So in that example if you selected client A as having access, and client B doesn’t, then you need to know how you are going to handle that. What is provided back as a means of, whether the access has expired or they just haven’t purchased it.

The fact that you make reference to whether Coldbox is a good fit is not the solution you are needing, the solution is how you intend to secure the SaaS.

Hopefully this makes more sense, or if you have a specific question in how to secure the service then maybe we can help more. But the answer is anything that you can think of developing, can be achieved in Coldbox, it just boils down to implementation and requirements you need to secure the SaaS.

As for what you can use modules for, have a look at ContentBox. This made up of several modules that provide the final solution, but lets say you want to redesign the Admin section, then you have a module that could be easily modified to do this, without effecting the rest of the site.

Another good use of modules is portability, designed right, you can just copy and paste it to another Coldbox application with minimal changes and it should just work. But of course there are hundreds of examples on how you can use modules.

For example I designed one site 4 years ago, every single line of code to the application, was considered shared code. I wrote 15 modules for this application, in which around 45 domain names pointed too. The only difference was the code to change the datasource for ORM based on the URL, and the same code and modules could be used to service any one of the 45 domain names. In my case I added extra functionality, to switch on and provide security via interceptors.

Which made sense for this client, because they had many aspects that where identical, so modules and the ability to switch on or off per client was made based on who was viewing which URL.

The upside to this, was no duplication of code, no extra mappings or virtual host settings, instead all pointed to the same code base, and due to configuration options, then one module could be available or not.

What you are trying to achieve sounds identical to what I did 4 years ago.