I am new in grpc i don't know how to use it with spring boot but using the below link
https://github.com/saturnism/grpc-java-by-example/tree/master/simple-grpc-server
https://github.com/saturnism/grpc-java-by-example/tree/master/simple-grpc-client
note* : - first is for server project and second is for client project.
i have created a project on grpc with spring boot but i can'nt getting understand one thing in this that in grpc client project how can i use classes which are generated by protobuf in the project of grpc server. because it is not creating any proto file in grpc client project then how can i use the classes of grpc server project in grpc client project or can we create one project for grpc server and client instead of creating a diffrent project for both.
I have two queries to ask related to this question one:-
1. How to use classes of grpc generated by protobuf compiler in another project like if client and server are two different project and only server have proto generated files and client wants to use same classes.
How can i create all these thing in a single project means client and server in one project and then how can i run this project with step by step demo.
There are two ways you can do this:
Copy the .proto files between the two projects, and have each one generate their own copies of the generated code. This is probably the easiest, and allows you to avoid checking in the generated code into source control. The downside to this approach is that the .proto files can get out of date if you modify one and not the other.
Keep the .proto in the same repository of both the client and server, and make both depend on the generated code. This allows the proto to be modified for the client and server at the same time, but requires the code to live in the same repository (this is sometimes called the "Monorepo" approach). The downside to this is that the client and server repos may get too big, and need to be split up.
Google (the author of Protobuf) typically uses option #2, but many users of Protobuf prefer option 1. I would highly recommend regenerating the classes each time, and not check in the generated code. The ABI of Protobuf classes can change occasionally, and you would lose the backwards compatibility of Protobuf.
I have created a sample spring boot grpc application and posted in here
https://javabelazy.blogspot.com/
use the dependency net.devh.grpc-server-spring-boot-starter in your pom
create a protofile (sample service code)
service PingPongService {
rpc ping(PingRequest) returns (PongResponse) {
option (google.api.http) = { get: "/v1/grpc/{ping}" };
}
generate stubs for proto file using io.grpc:protoc-gen-grpc-java:1.30.0:exe
use nettyserver
set the port to 9090 (default) grpc.server.port=9090 in application properties
I have used https://github.com/yidongnan/grpc-spring-boot-starter recently. You will get most of the spring features along with grpc using this library.
There is yidongnan/grpc-spring-boot-starter (DOC) which implement springboot autoconfiguration starter for both client and server.
It implements #GrpcServer and #GrpcClient.
#GrpcService, which will add service to grpc server and start server automatically.
Annotation that marks gRPC services that should be registered with a gRPC server.
If spring-boot's auto configuration is used, then the server will be created
automatically. This annotation should only be added to implementations of
BindableService (GrpcService-ImplBase).
#GrpcClient, which will create channel and stub for client automatically
Example: #GrpcClient("myClient") <-> grpc.client.myClient.address=static://localhost:9090
nils server sample
nils client sample
Based on these samples, I also implement my simple server and client sample:
ppdouble/springboot-grpc-server-sample
ppdouble/springboot-grpc-client-sample
You can based on those samples implement your project or implement a new springboot autoconfiguration starter.
Related
Spring cloud-config-server has a built in mechanism to communicate with git repository and read files which are stored there. Then cloud-config-server also has built in mechanism to expose endpoints to clients (normally spring boot apps) which can read those files and use them as configurations.
This is well documented in spring documentation as can be seen from bellow.
According to doc
Spring Cloud Config Server
Spring Cloud Config Server provides an HTTP
resource-based API for external configuration (name-value pairs or
equivalent YAML content).
Also as documented about the serving format
Serving Alternative Formats
The default JSON format from the
environment endpoints is perfect for consumption by Spring
applications, because it maps directly onto the Environment
abstraction. If you prefer, you can consume the same data as YAML or
Java properties by adding a suffix (".yml", ".yaml" or ".properties")
to the resource path. This can be useful for consumption by
applications that do not care about the structure of the JSON
endpoints or the extra metadata they provide (for example, an
application that is not using Spring might benefit from the simplicity
of this approach).
It can also support txt format
Serving Plain Text
Instead of using the Environment abstraction (or
one of the alternative representations of it in YAML or properties
format), your applications might need generic plain-text configuration
files that are tailored to their environment.
But considering that spring cloud config server has the built in mechanism to communicate with a git repository and also exposes endpoints to the clients to consume the delivered files, it would make sense for other type of files to be able to be served from those endpoints as well.
It could be for example .pdf , .xslx , or even .zip
For example let's assume that the configured git repository contains the file myFile.zip in featureA branch. Then the call under the exposed path of type /{application}/{profile}[/{label}] for example as
serverUrl:serverPort/myApp/default/featureA/myFile.zip is able to deliver the file but is always delivered as raw .txt file which then corrupts the content of the original file existing in git.
I have already found the solution, but invested many hours on it and it was strange that it was not documented in spring documentation. So it is probably good to exist here as well to spare some time from others having the same issue.
As discussed under this issue, spring-cloud-config-server runs under the hood with the help of a normal spring-boot app. Considering that spring-boot has built in content negotiation mechanism it is able to consume and produce different content as well.
As for spring-cloud-config-server it is possible to fetch binary files from git as well as other files (ex zip, pdf, word, xlsx ...) if the call is made with the header Accept: application/octet-stream . This way the call to serverUrl:serverPort/myApp/default/featureA/myFile.zip is able to deliver a copy of the original file myFile.zip without any corruption.
I can run a Spring Boot application and then use the springdoc-openapi-maven-plugin artifact to generate an OpenAPI spec.
However, is there also a way to generate the spec without running the application first?
I currently want to generate the spec in a GitHub Action and a direct way would simplify this a lot.
you can use swagger editor: https://editor.swagger.io/
It allows you to write a json/yaml with your specifications and at the same time you can view the result.
Also, in the upper part there are 2 features, which allow you to generate the code based on the json/yaml made.
For example you can create a spring application with all the endpoints you go to specify in your json/yaml ( server).
But you can also generate HTML. (Client)
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.
We have a Spring 4.0-based web application running in Tomcat 8 (alternatively we have a start-up script for Undertow). Spring MVC is handling requests. I am looking for a way to defer some of request handling code to Clojure library, with minimal changes to legacy Java code.
For instance, requests with URLs ending with .java would be handled by legacy Java, and requests ending with .clj would be handled by Clojure. For now, i see three options:
Include Clojure library jar in Java project's dependencies and use clojure.java.api to invoke Clojure code from Java.
Use some sort of RPC/RMI or message queues, e.g. Redis and Carmine's message queue processing capabilities. This way, Clojure would live in a separate JVM.
Use some sort of reverse proxy to perform URL routing.
Are above approaches actually feasible? What else would you suggest?
Thanks!
I've done a similar thing but on a DropWizard application rather than a Spring application. I went with approach #1.
I followed the example here - https://stackoverflow.com/a/2187427/827617
to create the library. That way you don't need to use clojure.java.api, your Clojure library compiles down into a jar that you can include in your Spring application and call directly from Java (the functions that you expose are static methods on a class).
Previously we were using the php framework Zend for the backend of our flash application.
We want to migrate this backend to our Java server.
We are using Spring so I guess the easy way to do it is to use BlazeDS since the integration with Spring is already done.
I am not sure but feel like BlazeDS is also a solution on the client side. My client is already done and send/receive specific objects at specific URL using the AMF format.
Is it possible/easy to develop a service with BlazeDS that have to respect this format?
I have successfully migrated a part of my service.
Actually, once Blaze DS is correctly configured it is pretty straight forward.
For the moment, the only differences I have noticed between Zend_AMF and Blaze DS is how the variable types are mapped (e.g for an integer Zend_AMF sends it as a Number while Blaze DS sends it as an int) and how the class names are sent (in Zend_AMF we use to have a mapping to map all classes names while Blaze DS sends the fully qualified name).
Hopefully it is not hard for me to modified the ActionScript code to map the java classes, so that won't be a big deal.