I want to spread my grails application into several modules.
For example,
i want to cteate one CoreModule it will has domain classes and
base services.
Then AdminPanelModule and RestServiceModule.
They will has own controllers and own specific services. But they
have to get access to CoreModule's domain classes and services.
Than I want to deploy 2 CoreModule apps, and 1 AdminPanelModule app on different hosts. Help me plz.
How can I organize dependencies with Idea?
What i need to do, to create correct run configuration?
Related
Need some best practice recommendations to a classic requirement around modularising Springboot application based on layers.
Some background info:
Small- medium size Spring boot project with less than 10 developers
2 different Spring-boot applications and shared Service, Repo layer and also shared models
Bit too late to go with micro service approach with full Model/ Controller/ Service/ Repo per API.
Currently there is just one web application exposing the APIs for a frontend application.
Requirement is to add new set of APIs which are used for B2B integration, so the request/ response formats will be quite different to the already available APIs. i.e. /webapi/v1/orders for frontend client and /b2b/v1/orders will need to return different response format.
The Service and Repository layer along with the models need to be shared among the 2 applications, so 3 modules identified as similar to how it's explained in https://stackoverflow.com/a/50352532/907032
-- Main app
-- Webapi (Got dependency to common, jar packaging)
-- b2b (Got dependency to common, jar packaging)
-- common (jar packaging)
The two applications need to be deployed separately and also separated from CICD perspective not to build all the sub modules every time (A change to b2b controller should not affect common/ Webapi)
A change to common module which is only required to the latest b2b module, preferably should not trigger a build and deploy of webapi. i.e. webapi uses common-1.01 and b2b module uses common-1.02. Understood the new version common-1.02 should not break any feature from common-1.01 but just trying to save unnecessary build & deploy for that module until required if that makes sense.
The challenge
Should the modules defined in the same Repo or 3 different Repos?
All the talks about mono vs multi repo is about whether to keep all different projects in same or not, but here as you can see these are modules which are kind of related to each other.
If we define these as sub-modules in same Repo, how versioning of the common module handled? If it's always triggering a build of all three sub modules, do we even have any advantage of modularising the code?
As per your description, the module named "common" is not not that comon to the other two. I'd go with the multi-modudle way by doing so:
first break that common module in three: common, utils-webapi, utils-b2b
The first will strictly contains the thing both webapi and b2b need at the same version. Utils-webapi will be dedicated strictly to the things in api. Same goes for utils-b2b
B2b depends on utils-b2b with depends on common. Webapi depends on utils-webapi with depends on common
Versionning of common module is always consistant, only utils-X module version change from the X module perspective
CI is thus independant for each build.
Note: You can go further and simply consider utils-webapi utils-b2b and get rid of common. At the cost of some deduped code.
I have an ear that contains three wars. war1 to use the user login, this works correctly. war2 with app1 and war3 for app2.
What I'm trying to do is share the session and apply the security filter with war2 and war3. As seen in the image. How can I do this?
First you need to understand that all three applications are independent and seperated by contexts and do not share any resources and cannot communicate with each other directly. For this you need to use an external authentication service like keycloak. Maybe a singleton EJB present in the EAR as an own module and used by all the wars works, whereby the EJB holds the security state.
In websphere there was an WebsphereApllicationSession or so which allowed to share state between modules but this websphere specific. Such a functionality depends on your application server you use and is not portable.
See the following links for further information but I recommend to use an SSO server such as keycloak.
https://technology.amis.nl/2012/01/18/sharing-session-state-between-jee-web-application-through-weblogic-session-descriptor-of-sharing-enabled/
https://www.google.com/amp/s/thewonggei.wordpress.com/2009/07/22/how-to-share-session-between-web-modules-in-websphere-6-1/amp/
https://softwareengineering.stackexchange.com/questions/178290/why-cant-wars-share-session-info
Wildfly share session between EARs?
https://forum.reportserver.net/viewtopic.php?id=173
https://www.keycloak.org
I am reading spring micro services for next project. Tut said that "The architecture style the main application divided in a set of sub applications called microservices. One large Application divided into multiple collaborating processes.". So already we have a framework maven multi module There I separated the project in my experience. even though it is. why do we need micro services to separate a project?. please differentiate it. thanks in advance..
Every service in the microservice architecture should be isolated which means that the team in charge of that service is able to put continuous deployment in practice without need to deploy other services. In practice, IMHO I think that we can use two approaches using our favourite build tool such as maven or gradle:
Monoproject: domain, repositories, services and controllers are all in the same project.
Multiproject: domain, repositories, services and controllers can be grouped in different modules. i.e domain and repositories are in repository module and services in another module with the same name and controllers in front module.
But, doesn't matter which approach you use the project (mono or multi) should represent one service.
I have started creating a project using springboot. There are multiple micro modules each having different controller. How can I expose all the controllers on a single host,port combinations. Also How can I make swagger to list all apis across different controllers.
The project is like
ABCD\
--\A\A Controller
--\A\build.gradle
--\B\B Controller
--\B\build.gradle
--build.gradle
Thanks for any pointers.
Is there a way I can make a collective war having all the controllers inside it
I am using springfox.io for the same. The challenge is I can get all the api listed in springfox/swagger provided if I jar all the modules and add to the modules with springfox config. But for this I have to create separate module and everything is running on one server. I want A controller to be running in one tomcat and B in another, and springfox on either C or any of A or B, but listing all apis of A and B. There might me some use case I am missing, please let me know.
I'm currently working laravel5 for CRM application with the help of Repository method under Provider Directory. But i'm totally look blind to understand Service Directory, and purpose of this directory.
And can anyone give me example to utilize these directories by differentiate difference.
Services
Services are re-usable classes that do not belong in a controller. For example, a service which is required by more than one controller such as class for building site navigation. It is a good place to put "global" classes (global to your app), which can be injected into a controller for use across your application.
Providers
Providers inject services into the dependency injection system, making them easier to access across the application. Packages which are Laravel specific usually include a service provider, which ensures that the packages classes are loaded when required and available to your controllers.
Services (http://laravel.com/docs/5.0/structure)
The Services directory contains various "helper" services your application needs to function. For example, the Registrar service included with Laravel is responsible for validating and creating new users of your application. Other examples might be services to interact with external APIs, metrics systems, or even services that aggregate data from your own application.
Providers
The Providers directory purpose is basically binding the custom files with app, for example if we want to work with the repository pattern and use eloquent instead of write queries in models then we need to bind our repositories with service providers and register service provider in to config/app.php file.