I am building a microservice architecture with different Spring Boot projects and two different repositories for each one of them:
One application is called project-api-1
The other one project-api-2.
Now, within the JUnit tests of project-api-2 I need to test some functionality that requires making a REST call to the API exposed by project-api-1.
Is there a way to link these projects together for testing purposes, in such a way that when I run the tests for project-api-2 I can also start the project-api-1 application at runtime, without having to create a mock API of project-api-1 from scratch within project-api-2?
What is the best practice here?
I ended up solving this problem by running a multi-module Maven project, and importing the REST API project with <scope>test</scope>.
In my tests, I then start the Spring Boot application with:
new SpringApplicationBuilder(RestApplication.class)
.profiles("test")
.run();
Related
I read spring source code to learn unit test. but confuse about testFixtures usage?
Test Fixtures is a feature of Gradle that the Spring Framework uses in its build. See Using Test Fixtures in the Gradle user guide for details.
Basically, the test fixtures are sample domain entities and sample Spring-based components that we (the Spring Team) use within our own test suite. We also place some of our common base classes for tests in "test fixtures". By making such things "test fixtures", we can reuse them across multiple modules within the test suite for the core Spring Framework.
Could anyone please explain the difference between application and integration service in IIB. I have referred through documentation but it was not clear. For example, if I have to create a service based on wsdl which has some 3 operations.Should I create it as integration service or application.Please suggest
So with an Application it's roll your own in that you have to build everything.
With an Integration Service you can import a WSDL and the framework of your flow will be generated for you.
So if you are being given WSDL's for the services you want to build then using an IS may be the way to go.
Personally I don't like some of the aspects of the generated code but that's me. I'm currently working on a project that uses REST API's and am using the REST API project option for my projects and it generates code.
I am trying to convert a normal monolithic web application into microservices structure using Spring Boot and Spring Cloud. I am actually trying to create Angular 2 front-end application and calls these my developed microservices in the cloud. And I am already started to break the modules into independent process's structure for microservice architecture.
Here my doubt is that, when designing the flow of control and microservice structure architecture, can I use only one single Spring Boot project using different controller for this entire web application back end process?
Somewhere I found that when I am reading develop all microservices using 2 different Spring Boot project. I am new to Spring and Spring Cloud. Is it possible to create all services in single project by using different modules?
Actually, it doesn't matter to package all those services into ONE project. But in micro-service's opinion, you should separate them into many independent projects. There are several questions you can ask yourself before transforming original architecture.
Is your application critical? Can user be tolerant of downtime while you must re-deploying whole package for updating only one service?
If there is no any dependency between services, why you want to put them together? Isn't it hard to develop or maintain?
Is the usage rate of each service the same? Maybe you can isolate those services and deploy them which are often to be invoked to a strong server.
Try to read this article Adopting Microservices at Netflix: Lessons for Architectural Design to understand the best practices for designing a microservices architecture. And for developing with Spring Cloud, you can also read this post Spring Cloud Netflix to know which components you should use in your architecture.
Currently I am working on microservices too, according my experience we have designed microservices as step below,
Maven
You should create the project with different project. But actually you can separate your project to submodule. So you will be easy to manage your project, the submodule you can use with other project too.
Build the Jar Library put your local repository. it can save your time, you have just find the same component or your functionality then build the jar file put in your local repository , so every project that use this function call point to download this repository, you don't have to write many project same same.
So finally I would like you to create different springboot project, but just create submodule and build local repository.
By creating your modules in different projects you create a more flexible solution.
You could even use different languages and technologies in a service in particular. E.g. one of your services could be NodeJS and the rest Java/Spring.
I am new to microservices and am learning Spring Boot
I have IntelliJ Ultimate and am wondering how best to structure my microservice code
For the system that i am building that will have a few microservices should I..
Open 1 IntelliJ containing a module for each Spring Boot microservice
Open multiple instances of IntelliJ and have one Spring Boot microservice per instance of IntelliJ
I think it will be tricky to do 2 if I have a lot of microservices but I do not know if IntelliJ is able to have multiple Spring Boot microservices running at the same time in one instance of IntelliJ
Any advice on how you work with microservice code / projects would be appreciated.
InteliJ is able to have a lot of Spring Boot microserices/application running at the same time. It have no impact on performance, even if you run all microvervices in debug mode. I would choose first option. This is an approach, we are using in our poject:
Start new project in IntelliJ.
For each microservice create new module in InteliJ.
Benefits:
If someone new want to work on that project, he can import one
project and have all microservices imported at once. Even if he would
work only in few of them, he can look how others are build.
in InteliJ you can create Run Configuration as "Compaund". So, when you want to run all your services at once, you can do it with just one click.
But, if you have 1500 employees, want go full netflix way and create 500 microservices, then better way will be to keep them separate :)
One of the benefits of microservices is organisational scalability. You have several teams working on different microservices at the same time. Also, it should be possible to develop, build and run each microservice on its own. If you don't have those goals, you get all the complexities of microservices and very little of the advantages.
In such a scenario, each microservice should live in its own version control. As long as this is given, if the IDE supports multiple version control sources per module, go for 2). Otherwise I guess you must stick with 1).
Just looking for some information if others have solved this pattern. I want to use Spring Integration and Spring Batch together. Both of these are SpringBoot applications and ideally I'd like to keep them and their respective configuration separated, so they are both their own executable jar. I'm having problems executing them in their own process space and I believe I want, unless someone can convince me otherwise, each to run like they are their own Spring Boot app and initialize themselves with their own profiles and properties. What I'm having trouble with though is the invocation of the job in my SpringBatch project from my SpringIntegration project. At first I couldn't get the properties loaded from the batch project, so I realized I need to pass the spring.active.profiles as a Job Parameter and that seemed to solve that. But there are other things in the Spring Boot Batch application that aren't loading correctly like the schema-platform.sql file and the database isn't getting initialized, etc.
On this initial launch of the job I might want the response to go back to Spring Integration for some messaging on Job Status. There might be times when I want to run a job without Spring Integration kicking off the job, but still take advantage of sending statuses back to the Spring Integration project providing its listening on a channel or something.
I've reviewed quite a few Spring samples and have yet to find my exact scenario, most are with the two dependencies in the same project, so maybe I'm doing something that's not possible, but I'm sure I'm just missing a little something in the Spring configuration.
My questions/issues are:
I don't want the Spring Integration project to know anything about the SpringBatch configuration other than the job its kicking off. I have found a good way to do that reference to the Job Bean without getting my entire batch configuration loading.
Should I keep these two projects separated or would it be better to combine them since I have two-way communication between both.
How should the Job be launch from the integration project. We're using the spring-batch-integration project with JobLaunchRequest and JobLauncher. This seems to run it in the same process as the Spring Integration project and I'm missing a lot of my SpringBootBatch projects initialization
Should I be using a CommandLineRunner instead to force it to another process.
Is SpringApplication.run(BatchConfiguration.class) the answer?
Looking for some general project configuration setup to meet these requirements.
Spring Cloud Data Flow in combination with Spring Cloud Task does exactly what you're asking. It launches Spring Cloud Task applications (which can contain batch jobs) as new processes on the platform you choose. I'd encourage you to check out that project here: http://cloud.spring.io/spring-cloud-dataflow/