Please help in understanding
1)Choosing Akka http vs Lagom for building a microservice
2)Is there any difference between REST API and Akka http/Lagom based microservice.
Thanks
This is a very broad question, but let me give you some pointers.
1) Akka is a library (or, as the Akka team calls it, a toolkit), while Lagom is a framework. What's the difference? To quote Martin Fowler:
A library is essentially a set of functions that you can call, these
days usually organized into classes. [..]
A framework embodies some abstract design, with more behavior built
in.
Akka gives you everything you need to write a reactive microservice if you know what you're doing. Lagom tells you, to some extend, how to write a reactive microservice. For example it prescribes a certain project structure, and provides ready-made implementations for common patterns in microservices, such as service lookup, circuit breakers, asynchronous messaging, and even event sourcing and CQRS. You can do all this with Akka as well (in fact, that's what Lagom uses underneath), but you'll end up implementing a lot if it yourself. If you're not very experienced with Akka (and you probably aren't, otherwise you wouldn't be asking the question), I would recommend you give Lagom a shot.
2) A microservice is an application that is concerned with one business capability, and interacts with other microservices to form a functional system. REST is an architectural style for accessing and manipulating resources. These are completely independent, you can do microservices without REST, and REST without microservices. But you can also combine them, i.e. build your microservice as a REST service. This, or more specifically REST over HTTP and using JSON, is very common for public-facing microservices that don't only interact with other microservices, but are called from web front-ends or arbitrary client applications. So yes, there is a difference, in fact they have nothing to do with each other, but you can use Lagom (or Akka HTTP) to build a REST API.
Related
I am new to reactive concepts and these terminologies are looking similar to me. Am I correct in stating that Spring Reactor, Akka, RxJava are similar but how is this different from gRPC. Can I use Project Reactor with gRPC and RSocket. This is getting overwhelming. How are these related? Any explanation on this will be very much useful to me.
Am I correct in stating that Spring Reactor, Akka, RxJava are similar
Yes, to a point. Reactor & RxJava are pretty much one and the same, conceptually (though I'm sure I'll attract some stick from at least someone for saying that...!)
Akka is a bit different - it's a more fully featured framework that uses reactive concepts. It's also written in Scala rather than Java, and while it works just fine in Java, it's a reasonably unusual choice in my experience.
how is this different from gRPC
gRPC is a completely different beast - it's a framework meant for connecting different services together. You can build your services in any number of languages, Java included, and then choose whether you make blocking or non-blocking calls to those services from the framework you've constructed (the non-blocking calls could then be trivially interfaced with a reactive framework if that was required.) It's much more similar conceptually to REST / SOAP than it is Reactor or RxJava.
RSocket is different again - it's more a competitor to HTTP for reactive service intercommunication than anything else. It's a communications protocol (rather than a framework) that services can use to inter-communicate, and it's designed specifically to be efficient while supporting reactive semantics at the stream level. RSocket can for example manage flow control, passing backpressure messages between services, to try to ensure upstream reactive services don't overwhelm downstream services - not something you can do with HTTP (at least, not without adding another protocol on top.)
Overall, if you're new to reactive generally and want to start somewhere (and keep in Java land), then my advice would be to stick with Reactor for the time being to avoid getting overwhelmed - it's probably the most used framework in that regard since it's built right into Spring. Once you're familiar with the fundamentals, other related components like RSocket will start to make a lot more sense.
gprc is not reactive it's basically http2 + protobuf
PROBLEM: Application uses Axon Framework and org.axonframework.eventsourcing.EventSourcingRepository and building _links in HAL format is needed in responses.
RESEARCH: Can be tuned with Spring Hateoas, but a lot requires to be handcoded in rest-controller. Spring Data REST offers autogeneration of links with an only annotation on CRUD repository. The project is not RDBS & JPA-based, so Spring Data REST is not an option.
QUESTION: Does Axon offer any RESTful solutions from the box, or is there a better autoconfigured alternative to Spring HATEOAS?
Gotcha, so you are essentially looking to expose a service's capabilities when it comes to which commands can be handled by a given Command Handling Component, disregarding whether that component is an Aggregate or an External Command Handler.
Note, that interaction between a component which dispatches commands and one which handles them resides within the CommandBus. When an Axon application starts up, it's the CommandBus which receives all the registrations for known command handlers.
That way, the CommandBus provides the location transparency for this part of the application. And it's location transparency which provides clear and cleanly segregated components; essentially what will help you to take an evolutionary microservices approach (as AxonIQ describes here).
I'd thus argue the necessity of sharing all known command handlers on a given service/aggregate through REST.
Regardless, whether it makes sense is always a question of "it depends". I for one have created a means to share the known commands a service could handle as JSON schema, as you can see here in a sample project I helped built between AxonIQ and Pivotal.
So, to come round to your question:
QUESTION: Does Axon offer any RESTful solutions from the box, or is there a better autoconfigured alternative to Spring HATEOAS?
No, Axon does not provide something like this out of the box, as it expect you use the CommandBus for communication. I do know you might need a starting point somewhere, for which REST makes sense, but even then exposing all known commands can be regarded as exposing your internal domain to the outside world. In the majority of scenarios, that would be undesirable, but as stated this highly "depends" on your use case.
What would be the pros and cons of these architectures?
By RPC I meant remote procedure call services like WCF, WebServices
etc.
Then on the other side, there's the more message oriented frameworks
such as MSMQ, NServiceBus, ServiceStack etc.
Then there is the hybrid approach such as WebAPI, which is some sort
of a remote Active Record Pattern (Out of the box it only supports a very
limited number of verbs such as "Get", "Put" "Post" etc.).
Disregarding, how it's actually implemented (aka. I don't really care about durability, transaction etc. because all that can be implemented regardless of the abstraction), what would be the benefits and drawbacks of these abstractions?
Again, no low level implementation details please, I just want the difference in terms of sound architecture, best patterns and practices, or even circumstances that would be most appropriate to employ each and why.
The only benefit of RPC is that it looks familiar and gives developers the illusion that a service call looks and acts just like a normal method call.
Otherwise RPC method signatures are tightly-coupled, fragile and brittle and ties the contract of your service to its single server implementation. Here's an earlier answer comparing the same WCF and Web API RPC services re-written in a message-based service.
For background reading I've described the differences between RPC vs Message based services in the WCF vs ServiceStack interview on InfoQ as well as what a message-based service is and their many advantages.
I've inherited this really weird codebase where they've built an external web service over a bunch of internal web services just to add authentication/authorization using WS-Security, WS-Encryption, et al. Less than a month into this engagement, I'm already feeling the pain of coupling volatile components through rigid WSDL, esp considering some of them use WCF and other choose to go WSDL first. Managing various versions of generated proxies and wrappers at various levels is a nightmare!
I'll admit the design is over-complicated and could have been much better, but my question essentially is:
Would you ever build a web service just to provide a cross cutting concern over a bunch of services?
Would this be better implemented as web service handlers?
and lastly...
Would you categorize this under the Web Service Gateway pattern?
I saw that very thing being built one year ago. I almost cried when the team took months to build 4 web services, 2 of which simply wrapped other internal ones, using WCF and some serious encryption. The only reason they wrapped the internal ones was to change the potential error numbers coming back.
So, would I ever intentionaly do that? Nope.
Would it be better implemented as almost anything else? yep.
Would I categorize it under the WTF pattern? absolutely.
UPDATE:
One thing I just remembered is that there is an architecture called "Enterprise Service Bus" It's purpose is to provide a common interface into other SOA systems. This way it doesn't matter what the different applications use for their end point mechanisms (WCF, WSE 1/2/3, RESTful, etc).
BizTalk is one example of an ESB and there are many other off the shelf programs that can be used. Basically, your app passes a message to the ESB and it handles sending that message, in a reliable way, to the other systems as well as marshalling any responses back.
This also means that you could insulate other applications from many types of changes to the end points. Of course, if the new end points require additional information, then you'd have to modify the callers. However, if all they are changing is the mechanism then a good ESB would be able to handle those changes without impacting your app.
I have seen similar implementations if you are exposing the services to the outside world and if you need to tighten down the security..check this MSDN column..
We are developing a middleware SDK, both in C++ and Java to be used as a library/DLL by, for example, game developers, animation software developers, Avatar developers to enhance their products.
Having created a typical API using specific calls for specific functions I am considering simplifying the API by using a REST type API (GET, PUT, POST, DELETE) or CRUD type (CREATE, READ, UPDATE, DELETE) interface.
This would work in a similar way to a client-server type REST API where there are only 4 possible API calls but these can take flexible parameters.
This seems to have the benefit of making the API stable in that new calls are not being added and old calls are not being removed. So a consumer of this API need not worry about having to recompile and change their code to suit any updates to our middleware.
The overhead is that there is an extra layer of redirection in the middleware controller to route API calls and the developer needs to know what parameters are available for each REST call (supplied of course).
I have not so far seen this system used outside of web type client server applications so my question is this: Is this a feasible idea?
I am thinking in terms of its efficiency as well as if for example a game developer would find it easy to use.
Yes, this is a feasible idea. But I'm not sure the benefits would justify the costs. REST is best applied to a networked application scenario, oriented around requests and responses. While there are definite learning curve advantages to a uniform interface, those advantages can be present in almost any well-designed API which provides reasonably abstract procedures.
You also expressed concern for whether a game developer would find a RESTful API easy to use. I'd be dubious. I've implemented many RESTful web services, and helped many developers get up to speed both building them and using them, and the conceptual leap required to grasp REST can be substantial for someone who has been steeped in procedural APIs for years. I'd think that game developers in particular would be very strongly connected to procedural APIs, to the point that attempting to adopt a different paradigm, whatever its benefits, might prove extremely difficult.
Remember that REST is not specific to HTTP, and does not rely on just the 4 HTTP verbs. The verbs you have and can use depend on what protocol you're using.