Keep separate layer for domain logic and presentation logic. Keep domain logic to domain classes and presentation logic in controllers/views
An application might be slow simply because its executing way more queries than it needs to. For that reason, you should always profile your application to find out what's happening
- Disable Open Session:Disable Open Session In View filter in production environment. This is convenient for the developer in developer environment but acts as a drag on the number of concurrent requests that can be processed as each Hibernate session fetches a database connection.
- Flash and sessions:As soon as you use flash scope, Grails creates an HTTP session. The lifetime of that session depends on what is configured in web.xml, but by default it's 30 mins. As you can see, if lots of people hit flash-enabled pages at the same time (or within a half-hour window), your application will end up with a large number of active sessions
- XML and JSON rendering:The markup builder syntax for generating XML responses is very convenient. But it's not terribly fast. The same goes for JSON. If you discover that the rendering time is proving a bottleneck, first try as XML and as JSON feature. If you still need improvements, consider using alternative libraries such as Jackson for JSON.
- Large Operation:Use the service layer when there is a large operation to be done that could be called from different front end (web usually, but it could be triggered by a scheduled job or other)
- Inheritance:When evaluating your inheritance options, understand the potential performance cost of using a one-table-per-class strategy, and weigh that against the relaxed validation constraints required when using the one table-per-hierarchy approach.
- Profiling:Do the proper profiling to identify the performance bottleneck e.g. P6Spy will give you good insight into your query timings. Combined with a load tool like JMeter, you can get pretty good simulations of how your app will perform.
- The Hibernate's legacy 2nd-level cache interface (cache provider api) is a source of monitor (thread) blocking. So for high throughput you should disable the 2nd-level cache completely unless you are using Grails 2.x+ with Ehcache. This is because those versions of Grails will automatically use a new Hibernate API that doesn't block. But this only happens with Ehcache.
- Use caching at the service and view layer via the Cache plugin.
- Design to share common domain/services that need to be shared into a plugin, and sharing that across your projects. It will keep complexity low, while allowing you to reuse the shared code from one maintainable place. Expose your business logic as RESTful web services, which would be language agnostic
- For the service which needs to offer to other Grails application if we have a number of services we want to offer to other Grails applications, it then a good idea to bundle them in a separate project / grails app?.
- Apply to the access-control rules you set up. A framework like Spring Security can make it easy to add access control to an application
- Know your trust boundaries. A trust boundary is a point of communication where one side is trusted and the other is not. It’s at these trust boundaries that you must be particularly vigilant, scrubbing data that comes in and making sure data going out is safe.
- Obfuscation isn’t a substitute for proper security. Hiding or mangling information can be useful—after all, there’s no point in advertising anything that might help an attacker. But if you rely on obfuscation, you run a high risk of compromise. It’s complementary to other techniques, not a substitute.
- Develop with security in mind. Remember that security is a process and a mindset. In order for your application to be secure, you have to consciously consider the potential effects of the code you write.
- Perform code reviews. Just as code reviews help weed out coding mistakes and movements in the direction of the “ball of mud” design pattern, they can also pick up security flaws. There’s nothing like a second pair of eyes when it comes to catching these things.
- Use existing tools and frameworks. No matter how vigilant you are, errors will creep in. Security tools and frameworks are battle tested and in wide use. That means vulnerabilities are quickly found and quashed. Why risk your application by using homegrown solutions?
- Make sure that the application isn’t susceptible to common types of attack by using functional tests and automated tools like OWASP’s Scarab.
- Use to get the right security framework to apply on your Grails application e.g Spring security.
- Grails IN Action by Glen Smith and Peter Lebrook