A very common practice on communication between frontend and backend of micro-service architecture is to use API gateways or adopt a BFF architecture.
However, backends of many modern sites consists of several domains.
What I mean is that they are actually using multiple public endpoints instead of a single one.
Thus, it seems that real-world practice is to use a combined method of a Direct-Client-Service method and an API-Gateway method.
Then how should we determine which service should be using a standalone endpoint while others should not?
Thanks.
Related
So I've been working on a microservice-based architecture in Spring and my prototype uses Spring's WebClient to explicitly send a request to a different service and await a response. Recently I've tried to migrate the project to some RPC-based service remoting technology, and I figured out that all the technologies that just work out of the box (Hessian, RMI, HTTP Method Invoker) are deprecated, and the ones that Spring encourages to use (JAX WS and Spring WS) require to learn multiple additional DSLs and spend a week trying to deeply understand their principles just to export a service to the web. Also, just using WebClient feels far more flexible and seems to leave a lot of room for further improvements. Will creating my own REST-like APIs for each of the microservices and then explicitly using WebClient to call them turn my code into instant legacy spaghetti mess or is it a normal thing to do?
P.S. By "more flexible" I mean, for example, an ability to set up a reverse proxy load balancer with caching and different actions for different methods in between the actual microservice nodes and the requesting service, etc.
I am trying to build a new application with spring boot microservice framework. I have tried some demo. The existing demo is too simple, doesn't introduce how to call another service from one service. Should still going through http, or should going through RPC? If going RPC, which RPC framework support?
The way of integrating among services depends on numerous factors, like synchronicity/asynchronicity, load that will be generated, etc. The most popular (I guess) way of integration is REST-based one. Because you tagged your question with spring I would recommend using declarative REST client - Feign that is very well described here. You can use message brokers as well, which are also very well abstracted by Spring Cloud Stream - you can read more here. I think that more in depth discussion should be based on your needs.
If another micro-services are exposing the REST API , then you can simple use jersey client
or httpclient to call them.
I have worked on RESTful Web Services at a high level (not very exhaustively), coded few REST based web services.
To begin my journey in RESTful WS, I read online articles (wiki, online tutorials etc.) and I came to know that it is an architectural style specifying constraints and when applied to web service induce desirable properties, such as performance, scalability etc. Ok, this is the theory part of this concept.
A simple example using JAX-RS:
#Path("/simple")
public class SimpleRESTService {
#GET
#Path("/{param}")
public Response getMsg(#PathParam("param") String message) {
String output = "Jersey say : " + message;
return Response.status(200).entity(output).build();
}
}
My doubt is:
If REST is architectural style (and using those guidelines build RESTful web services), what does JAX-RS do? To what I understood, REST is just architectural style and not any specification, what does JAX-RS has to do with this? I am having difficulty in understanding the relation between these two entities.
Can anyone help me understand this in simple words.
REST is indeed an architectural style of building web services independent of application-layer protocols (it could be implemented over FTP or HTTP as well).
JAX-RS is just a standardized API of Java EE with which you can easily implement RESTful services in Java. It is a toolkit for a developer to lift the burden off his shoulders, and as part of Java EE, it is implemented in application servers such as WildFly out of the box.
But note that it is just as possible to create REST services in frameworks like Spring using the Spring Web MVC and Spring HATEOAS modules.
Edit:
Although REST is a well-defined architectural style, it is (as you mentioned) not a specification so there is a lot of foggy areas about it among developers.
In a nutshell, all it states is "Hey man, if you use the communication protocol (say HTTP) this way and this way, it will be very convenient for you to change and scale and it will be very straightforward for the clients of your service to talk to you".
JAX-RS gives you the ability to define service endpoints with dynamic parts (eg.: /api/jediknights/{id}, so that the id could be anything), makes it easier to respond to the client in the format of your (or your client's) desire, like XML or JSON. It provides convenient wrapper objects to wrap your response body along with status codes and headers and many other things of convenience.
The catch however is: it is still your responsibility as a developer to adhere to the principles stated by the REST style. Nothing is really enforced upon you by JAX-RS.
To be fair, you could even achieve a RESTful web service by only using the somewhat lower-level Servlet API. JAX-RS just hides the unnecessary details from you and will make your life easier.
I hope it became a bit clearer :)
Java API for RESTful Web Services (JAX-RS), is a set if APIs to
developer REST service. JAX-RS is part of the Java EE6, and make
developers to develop REST web application easily.
You can read some more here: http://www.mkyong.com/tutorials/jax-rs-tutorials/
I am using vertx3.
As we know Vertx is very efficient handling many requests with it's reactor pattern.
The thing is that I have a second service which exposed as Rest-API on Spring-boot container(it was very easy for me to implement it over there).
I got two options: 1. Implement that logic on vertx and earn the api call.
2. Scale the spring-boot service to handle those millions rest api's reuqests from vertx.
Anyone had this dilema ?
will be easier to go with option two.
Any alternative how to scale the spring service ?
(I already aware to the physical solutions of adding many instances on diff machines and put load-balancers but than I am losing the power of vertx since the spring-service is a bottleneck
Thanks,
ray.
Usually service implementations are stateless, regardless from technology which are you going to use. So it means, that they are scalable.
Try to implement service logic, using spring, rest-api using vertx. Spring service service logic will be used from vertx.
And of cause do not block the threads in service implementation.
I have to implement a webservice which will be used by different clients written using several languages (e.g. Java,C#) and frameworks.
Because of this i decided to use JAX-WS and the Apache CXF Framework to create an WSDL first webservice.
Now my problem is that the webservice has to notify all clients whenever the user performed certain actions on one of them (like adding an element to the database).
After some research I found that the technique of long-polling might help me to get this task done. However I'm not sure that this is the best solution and that this one will work on all target plattforms.
Is the technique of long-polling suited in a Webservice (WSDL) context or is there another method widely used and supported?
Long polling or Comet techniques are best used for this scenario, Web services are stateless and don't support pushing data to clients without heavy modification of the hosting service, i.e. IIS, Apache... etc.