When modularizing a grails application, when does it make sense to add the module as a plugin vs gradle dependency?
For Example:
akaDomain contains all the domain objects.
akaWebsites contains all the presentation logic.
akaService1 contains some services.
akaService2 contains some other services.
All the websites and services share akaDomain.
Can the domain classes present in akaDomain be used for scaffolding controllers and views in another application like akaService and akaWebsite?
Can this be achieved using plugins or dependency or both.
Please explain what am I missing if I don't make a plugin of akaDomain.
This answer uses plugin to explain how to modularize grails app.
You can definitely use the domains defined in one plugin as the basis for scaffolding in another plugin or in a main application. There are several practical considerations when doing so however:
If you choose to implement UI in a plugin, then you are committing to a UI look and feel that is to be shared across multiple applications. This is often very difficult when doing custom / contract development where every customer wants their own personal look and feel. You will want to think about selecting a UI abstraction as well that allows flexibility on theme support at least. We use Twitter Bootstrap for this purpose but there are several others that fit the bill.
You must manage the dependencies between the "domain/service" and the "UI" plugins. This is true of any plugin ecosystem, but once you commit to abstraction, this discipline is very important or you end up with dependency dead ends or cycles. It is a lot of work, but the pay off for productivity is very high.
As for the question on Grails Plugins vs Gradle dependencies:
Plugins are in fact Gradle dependencies (in Grails 3.x at least). That is, plugin dependency management is implemented on top of Gradle. Plugins provide additional support for integrating into a Grails application that include things like:
Automated spring bean registration and initialization at startup.
Participation in application component reloading.
Artefact definitions and initialization at startup.
So, implement using plugins and you get the best of both worlds.
Related
I am working on a POC where I had to containerize a part of application for eg - I need to containerize "add to cart" functionality in an e-commerce website, I see a various example https://dzone.com/articles/docker-for-devs-containerizing-your-application to containerize whole application,but how to do for a part of it where my functionalities has dependency on other code parts as well.
Any pointers will be very helpful as I am totally stuck and don't see similar query anywhere else.
Thanks
IMHO, the first thing you need to do is read more about the concept of microservices and how it works.
Basically, the idea is decouple your monolithic application into as many services as your want and deploy it separate of each other. Each of this parts will comminicate with other parts by API calls.
There are a lot of benefits of using microservices architecture, and there is no the "better way" to do this, it will depends of how your application works and how your team is engaged.
I can recommend you a couple of link about microservices:
https://medium.com/hashmapinc/the-what-why-and-how-of-a-microservices-architecture-4179579423a9
https://opensource.com/resources/what-are-microservices
https://en.wikipedia.org/wiki/Microservices
If the application is not build as microservices, it wont actually work. The POC you should be striving for is to decouple it in another seperate application.... Which I guess its much harder and larger scope of the original POC
This is how I'd do it:
create a new java/gradle module called "addToCart"
extract all functionality related to "add to cart" functionality to this single gradle, spring boot module (add relevant dependencies to build.gradle and update settings.gradle to include the new module. And use compile("module") to have dependencies on existing modules brought into your new spring-boot module (note: you can't depend on a module that is a spring boot application - this will fail because spring-boot modules are compiled differently to lib modules without the spring boot plugin).
extract any dependencies this new module has on existing code out to another new library module that can be pulled in using a gradle dependency (you're aiming to end up with a Gradle multiproject build). This is required so that existing projects/modules as well as the new one can maintain the same dependencies.
use a gradle docker plugin like https://github.com/palantir/gradle-docker OR https://github.com/bmuschko/gradle-docker-plugin to create a docker image/container for you (instructions on website). You can do this part manually also.
If you're feeling particularly adventurous you could look into building GraalVM "native images" that are container friendly. Native images start incredibly fast. Because they start so fast you don't actually need to have them running all the time, which can lower your costs. There are trade-offs though. There's a talk from Devoxx Belgium 2019 that goes into details about it here: https://youtu.be/3eoAxphAUIg?t=978
I have a bunch of utility classes, that have nothing to do with web requests, database etc. Very similar to POJOS, except they are never persisted.
I want to make these classes available to a number of Grails applications and plugins.
At the moment, I putting these classes in their own plugin. It just seems like overkill. In the java world they would just be one package that was jar'ed.
I want to use some of the Groovy annotations such as #immutable etc so I want to stay in Groovy. But, I was wondering do I have any other options because a plugin, because that seems like overkill.
thanks
technically seen, this would be a bit of overkill indeed.
On the other hand, you just need a single repository and build process to deploy your app. I think, a single dependency resolution system which in integrated in Grails is better than 2 or more, unless you have them already.
You could make a plugin, or compile the Groovy into classes and make a jar that you share. Using annotations like #Immutable will work in classes from a jar or as source from a plugin.
Is there a way to check which Grails plugins are active and used durring application runtime?
I want to remove a plugin but I want to be absolutely sure that it is not used anymore...
Well, a brute force way would be to copy your Grails project (preferably using a source control tool like git's branching feature), remove the plugin, and make sure that:
No exceptions on a grails clean, grails compile, and grails refresh-dependencies.
All unit and integration tests pass (your team is writing those, right? ;) )
You can run the application and use it fairly normally; warning, this is the worst test, and by itself isn't sufficient, as you could end up with a BOMM.
If you're familiar with the classes in the plugin, but there are way too many Grails files to look through manually, you could use code search tools like those found in GGTS whatever IDE/text editor you're using. Even grep could be handy for finding references to those classes or some distinctly named methods.
Conversely, if the plugin is basically a black box, and your Grails app is small enough to get around, check the import statements at the top of your Controllers, Domains, and Services. If the plugin provides more client-side technology (like the jQuery plugin) check your GSPs and various items in the web-app directory (like Javascript files) for references to it.
I'm creating a new Grails project. I decided to split it in one application and several plugins. Now, plugins and main application need to access each others classes.
In the main application I can access plugins classes thanks to this edit in my BuildConfig.groovy file:
grails.plugin.location.'plugin1' = "../Plugin1"
But, how can plugins access classes from the main application?
Plugins cannot access main application. Plugins are meant to be stand alone, having no dependencies to specific main application code, but can only have dependencies to other plugins.
You need to find a way you can split your application into parts, which are independent of each other.
How come it is good practice within Grails to place classes in packages (e.g. mycompany.Book)?
I know it is a prerequisite in order to deploy Grails solution to the Google App Engine (using the plugin), but other than that and a well structured code library for large projects, what other benefits are there in describing packages for classes within Grails?
Another good reason, as mentioned by Marcel Overdijk in this blog post, is if domain classes has the same name as classes within Groovy, it is not possible to distinguish the two.
Grails runs on Groovy, which has a strong heritage with Java. Java encourages packages for well-documented reasons and Groovy/Grails follows suit. I think the main benefit stems from your description: a well-structured code library for large projects.
The most valuable reason that I've seen, is that you cannot "import" classes without a package into a class that DOES have a package. that means that you can't access any domain/service/controller/etc classes that don't have packages from your utility code that you might put a package on.