I am considering breaking my Grails app into two separate apps: admin and customer facing. The admin app would also do a lot of backend heavy lifting.
Has anyone done this? Lessons learned? I'm particularly wondering about the best way to handle domain objects as well as potential issues with concurrency.
You could run into race/locking conditions but I've seen this done on many occasions. My only suggestion is that you not maintain separate domain classes. Put common domain classes in a plugin and install said plugin in both applications.
If you really want to do that, the best way is to separate existing Domain classes too, instead of enable multiple direct access from all the apps. Keep each Domain class persisted by the app mostly closed to it. For other apps, they should access the data through RESTful service provided by the data-hosting app.
You might want to keep the domain classes exactly the same, therefore generating same db tables.
I don't think concurrency will be much of a problem, as modern dbms usually handle that really well.
Related
I'd like to make my usage of open-dolphin in grails sever as easy as possible. So, I'm looking for way to handle CRUD actions on domain classes(on the server side) automaticaly. In demos from open-dolphin project I havent found any idea how to achieve this(if I missed something, please point me where I should study). Instances are pulled from server on request and until it would be pulled/updated again there is no way to recognize changes that happen on server(I've been investigating mainly crudDemo in open-dolphin project).
Since CRUD actions can come not only from user via web or remote client, but also as consequence of other actions, cascade deletes, from services etc.(changes made to the database via sql, are probably untreatable), I thing that handle actions in classes controllers is not enough.
I came up with idea of handling CRUD actions using GORM events, with those I can keep dolphin models persistent with database, check PMs before update or delete, and probably handle all changes on domain classes instances that grails is doing. But, I have to write very similar logic to each class, be sure I havent missed any event on any class(scaffolding may help) and there are probably other consequences that I do not realize now..
So my question is: Is there any documentation, pattern, plugin, open-source code, etc., where open-dolphin is implemented into grails that way, that it autamaticaly propagates CRUD actions on domain classes instances to its presentation models? Or anything that aims to achieve this, using scaffolding, observing instances lists and properties, or something else?
Maybe, I misunderstood concept of using open-dolphin with grails, if so, I appreciate any good advice.
Thanks a lot!
for some reason I haven't seen your question before.
You can happily use Grails domain classes and GORM with OpenDolphin on the server side. The "CrudDemo" in OpenDolphin does exactly that.
Here are the domain classes: https://github.com/canoo/open-dolphin/tree/master/dolphin-grails/grails-app/domain/dolphin/grails
Here are the actions: https://github.com/canoo/open-dolphin/tree/master/subprojects/demo-javafx/server/src/main/groovy/org/opendolphin/demo/crud
Note that when we do testing and client and server-side actions run in-memory, there is no grails support available. Therefore, the server-side actions use service interfaces with DTOs instead of Grails domain classes. The implementation as a Grails service then uses Grails domain classes and GORM.
enjoy
Dierk
I'm still not used to the MVCS design pattern. I read in a book that if I was planning to create an app that gets information from an external source, it's better to use MVCS instead of MVC.
I'm currently working on an ios app that gets information from multiple external sources. For example, I'll be fetching info about the weather from a web service, driving directions/time probably from Google, and data from our database via a web service as well.
My question is, do I need to create more than one store object in this situation? Like create a store object for each of the external sources? Or do I just create one for all of them?
I think it really depends on your design approach as you can have dozens of different design approaches which all respect the MVC principles and that therefore are all correct.
Personally I would suggest to try to decompose the problem as much as you can in smaller problems, in order to get the most from the flexibility that a objected oriented environment gives you.
In this case, for instance, you could think about having an abstract store class in which you implement the common functionalities you need to have and then subclassing it for each different web service you need to use and implementing the other functionalities related to that specific service. It's just an idea! I hope this helps.
I want to build a RoR web application in SaaS architecture. Should I have a single database for every clients or multiple databases for each client. And also I wonder that each client should use the own separated application on sub domain or not. Although it depends on business logic but I want to learn how I can choose the correct way and what the best practice is.
Thanks,
There is no correct answer here. The first solution would be to have each client completely independent: their own application space and database.
However, you may want to design a framework which is common to all clients, and just change the branding for each client. The downside of this is the effort you need to keep them separated - for instance cross-contamination and security.
I'm building a new SAAS application and was looking for some advice on the most appropriate framework to use. I realize that no single framework will likely be able to do all this, but I thought I'd ask the community and try to find one that solves the hardest problems.
Requirements
Single code source. (each customer will have either a subdomain, or a distinct domain, but everyone should be running off the same code base and same servers)
Should be able to update the programming source once and have all the tenants pick it up
Session information should either be kept in a cached store, or just in cookies (no shared state)
Multi-tenant database functionality built in. (Based on the domain used to reach the application, the framework should automatically use the database connection information assigned to that domain)
Each customer/domain may have their own template for the web pages. Templates need to be assignable on a per-customer basis and kept outside the application code
Security and rapid prototyping is more important than speed
There will be a lot of CRUD type screens, so simple built in functionality for this is desired
I have pretty lengthy Java and PHP experience, but would only consider PHP as a last resort for this. My Scala, Python and Ruby experience is a bit rustier, but I would not mind coming up to speed if they offer a significant advantage. I've looked at the Play! Framework and like it (fulfills #1, #2,#6 very well), but the multi-tenant aspects are not very strong. I've done several projects using Grails and it handles everything except #3 and #5, and can be hacked to do the rest.
I would say that the third point is rather independent of grails/play/whatever in general. If you need a shared cache there is a multitude of providers for this and there are plugins for most of them in Grails.
The multi-tenancy in grails is pretty mature and much less intrusive than the solution from the blogpost in Sebastiens answer. Whether or not you use single tenancy (multiple databases) or multi tenancy is more or less transparent to your code and most of the headaches are abstracted away. Do be aware that you need to do some smart indexing (like including the tenant id in a multi column index etc) to not get very sad speeds when your data starts to grow.
As for externalized views, you can either slap them in the database or symlink them into your webapp and just keep them in separate numbered folders. Then from the tenant plugin, you can use TenantUtils.getCurrentTenant() and simply render from the appropiate folder "/" + (tenantID ?: "default") + "/whatever/view/path". This way, layouts etc can be shared across tenants if you so please and you simply put tenant specific stuff in the tenant specific folders.
You can probably do this in play too, or , but I don't see anything hindering you from doing this just fine in Grails.
My $0.02 on this question.
Actually Play! fits well to what you'r looking for.
Read this post:
http://www.lunatech-research.com/archives/2011/03/04/play-framework-writing-multitenancy-application-hibernate-filters
It works great. You can even make this filter work so that you can expose the crud module to customers and they'll only get their own data...
For very large applications, sharding seems not supported yet (no hibernate shards handled yet i think).
There's a multidb plugin to work with multiple db, but it seems not working very well yet...
I've heard that Grails' Multi-Tenant plugin offers some good tooling for several different methods of multi-tenancy.
"Each customer/domain may have their own template for the web pages.
Templates need to be assignable on a per-customer basis and kept
outside the application code"
I assume you mean they each have their own layout/skin. There are several techniques to execute this:
You could manually assign layouts based on tenant. <meta name="layout" content="${tenantName}/main" />
Write your own tenancy aware LayoutDecoratorMapper and override the default GrailsLayoutDecoratorMapper in sitemesh.xml
Figure out how to override and enhance Some internal tools dynamically resolve views(per tenant) or resources (GrailsViewResolver, GrailsConventionGroovyPageLocator, GrailsResourceLoader, etc.)
In PHP you can use Innomatic Platform for building multi-tenant (isolated databases) applications:
http://www.innomatic.org
Im building a Grails app that will have multiple similar websites (each it's own domain name) with the same code but different design and configuration. (think of blogger)
What is the best method for using different view and even some different logic on a single app without too much hacking?
I'm new to Grails and the method I have in mind is to check all the time to see what the domain name is and to serve the right controller/view. Is there a better way?
I would have a go with the MultiTenant plugin. You mention that views and logic differ, but I'm guessing what will differ most is the data? Use MultiTenant to cleanly separate the data for each site without too much hazzle, and if you store the configuration of views and logic in the DB you get that unique per site as well.
I think MultiTenant is being updated to the latest Grails release, at least I've seen that mentioned in the Grails mail list. I think you need to use an 1.2 release until then.
I'm doing something similar to separate data using the Hibernate Filter plugin. My views are the same but I have per-site texts and messages by looking up message "SITE-A.hello.world" first and if not found the default message "hello.world" is retrieved. Just to give you an idea how views may be customized, though you probably need to take it further than that for your system...