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
Related
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.
I am new to WebJars and so far have failed to see any real advantages that they bring to the table compared to simply using Bower for example. What justifies the idea of putting frontend JS into backend JARs?
Please name at least one or more "objective" advantages to using WebJars.
WebJars are useful when you have a JVM-based project and you want to use only one dependency manager / build tool.
We use a mixed OSGi and non-OSGi environment.
Therefore all our produced JARs are Bundles, to enable deployment and runtime both inside and outside of the OSGi container. Therefore, all our are written without any OSGi API integration, and we use a single OSGi extender bundle to register all services as OSGi services.
I would like to use a single DI solution (i.e. the same configuration file(s)) when wiring the system together both inside and outside of the OSGi container. This, rather effectively, prevents me from using simple blueprint DI.
What would you recommend here?
Is there any best practices collected for this kind of scenario?
I suggest looking at pojosr
A service registry that enables OSGi style service registry programs without using an OSGi framework.
The idea is to create something that would make the service and parts of the life cycle layer of OSGi available in environments where it typically isn't.
This allows you to use the normal OSGi Service Registry and Declarative Services, even outside an official OSGi framework, unless you need more than what is offered by Declarative Services
A couple of options;
Google Guice will work both inside (implicitly and explicitly using Peaberry) and outside.
Apache Camel - Camel's bean binding will work in OSGi, spring, (AFAIK) all EJB containers (even JBoss) and also will work nicely with Guice.
As it's likely you're running across multiple JVMs, with a mix of nice new OSGi and legacy, Camel's EIP might be a really good fit. But you can always get started with Guice and integrate Camel later.
Whatever you decide, it would be wise to ensure any Jars built include an OSGi manifest.
Use Spring.
It will obviously work outside of OSGi, and you can use Spring dm to adapt it to work inside of OSGi. It simply requires the addition of an osgi context file to bind beans to/from the service registry.
We have used it in multiple projects for several years for Eclipse RCP apps. It can be used to bind things at the UI level in this particular case as well.
It has been a long while since I have really worked with J2EE so please excuse my ignorance. My recent engagement in a Grails project has peaked my interest in Java once more and especially in Grails as it makes building web applications on the Java platform fun again. That being said, I would like an expert to comment on the following requirement that I have for an application built using Grails:
The Design Team (web designers) require access to the GSP pages and edit the view files (layouts, templates, etc.) without bothering the development team (software developers). This scenario can take place both during construction and after deployment into production.
The communication level between the Designers, Developers, and Business Users are not an issue here. However, about 40% of the time, the Business Units involved request changes to the front-end that have no impact on the Developers time but require the time of a Design Team member. Currently, the deployment workflow follows the Grails application through the deployment of a War file to a Tomcat server. I imagine there is a simpler way to allow the Design team to make UI changes without going through the build and deploy lifecycle.
Several of the Design Team members have had exposure to PHP in the past and at times miss the ability to just overwrite a template file to make a UI piece more functional or improve a layout template. I hope there is a similar way to accommodate such simplicity within Grails. I have been told that exploding the War file might be an option but that still requires the reload of the Tomcat hosted application.
If you believe that I looking at the desired solution the wrong way, please do chime in as I am more interested in a workable compromise for all the team members involved. Thank you.
You need to specify the following settings in Config.groovy:
grails.gsp.enable.reload=true
grails.gsp.view.dir="/path/to/gsp/views"
The 'grails.gsp.view.dir' is typically the path to your checked out SVN repo. You can then just 'svn up' everytime you want to update the views.
There is one caveat: When a GSP view is compiled it uses up permgen. Eventually you will run out and need to restart the server.
You could run a server with a version of the application via run-app in development mode. The designers can then make changes to the views and they will reload. They would need to be able to acccess the source code on the server via a share of some kind. As a plus, if you checked out the source the designers could then commit their changes from the server.
The downside is that if the reloading fails or you run out of memory (has been known to happen with lots of reloading) either a developer would need to stop and start the app or you could provide the designers with a script to run to bounce it.
You'd obviously take a performance hit by running in development mode and via run-app but it might a ok trade off in your case.
cheers
Lee
This may not be the direct answer for this question but since you seem to pay attention to designers' role in a project, you may also check my designer friendly GSP implementation which enables designers to view GSP pages even with custom tags thanks to the "tag declaration via attributes" feature.
I'm considering developing aspects of a website as Rails plugins for reuse. My question is about the development process. Since each of these plugins will provide a "slice" of functionality, should I develop each "slice" as it's own application and then extract the code from each application into a plugin? Or, should I write them as plugins right in an application? Ultimately I will be linking to these plugins from each site to keep it DRY.
I guess the main question is what would be the development process for creating multiple "Engine" type plugins?
Thanks in advance for any help.
Either approach is valid.
When writing a basic plugin I usually find it easier to write it in tandem with the application that will use it. Because I find it easier to design/test around something that already exists.
However, when it comes to Engine plugins, I prefer to develop them as a separate application and then rip out all the unnecessary bits when I move it into a plugin. They are in essence mini applications, and they should be completely functional when installed on a freshly created rails project.
By designing them as their own application I'm ensuring proper compartmentalization. This ensures that I'm not accidentally referring to code models/controllers/views/helpers that are not a part of the engine I'm developing.
If you're developing multiple engine type plugins this way, you might want to condense a few of the steps with a utility script. Such as one that streamlines the process of turning an application into an Engine plugin.
It should restructure your app as necessary and populate the files that plugins should have, such as init.rb.
You might want to give a look to Desert framework as well .