[akka-user] Re: Recommendations on a PoC for system migration from VB.NET to Scala/Akka stack

[Som Shankar Bhattacharyya]

The data we persist is table data. We receive serialized tables from the 
clients and save it to the file system. Then another set of services reads 
from files and persisists to the database.
Yes i too think Kafka will be an excellent fit here.
However i do not have much idea about deployments.
Can you please suggest me ,
  i. How to best showcase the advantages of this implementation ?
 ii. Example of a AKKA http application deployed in a web server ?

Much thanks.


On Thursday, January 25, 2018 at 8:26:37 PM UTC+5:30, Som Shankar 
Bhattacharyya wrote:
>
> I want some suggestions/recommendations on the following.
>
>
> Today we have a legacy .NET system that gathers information from customers 
> environment and reports back to our backend.
>
> Now this system is built the following way,
>
> The client is a VB.Net application.(Usually running outside our network)
>
> The back end is a combination of REST services and traditional web 
> services. All in ASP. These services have their database calls etc.
>
>
> *Motivations:*
>
>
> i. Migrating the legacy framework is essential simply because of 
> maintainace cost.
>
> ii.Our services are going to be hit very heavily this coming year with a 
> big increase in clients and reducing intervals of time between client polls 
> and i want to showcase how the Scala/Akka stack can provide better 
> performance in this regard.  
>
> Now i want to demo advantages of having this work done in the Scala/Akka 
> framework.
>
> I am wondering what approach should i take to best highlight the 
> advantages of adopting this stack.
>
> I already have a small REST service implemented that does a connect to a 
> database and get/set some data. I have implemented that as a Akka HTTP REST 
> service.
>
> But i haven’t mimicked the client or the other web services in question.
>
> With my limited knowledge of this stack i might still be able to implement 
> a client and a web service but i want to have a focused approach on what to 
> highlight and how to do so.
>
>
> *Initial thoughts:*
>
> i.Write a Scala program with Akka actors. I need actors to abstract the 
> different work the client needs to do in parallel. Today we do those using 
> a few windows services.
>
> ii.Have the already implemented REST service on a separate machine.
>
> iii.I need to write at least another web service(will it be a better idea 
> to write all services as REST ? )
>
> iv.Figure out a way to save data to the database from the services at 
> lightning speed. Today we have to write to the file system first and thena  
> different service slurps it up and persists to the database. Maybe we can 
> have some message broker here that can be used ?
>
>
> I need someone to discuss this with and come to a focussed work item.
>
>
> Much thanks !
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Swakka - a new extension to akka-http for Swagger/OpenApi

[Philippe Derome]

thanks!

On Sunday, January 28, 2018 at 4:34:37 AM UTC-5, Jeremy Townson wrote:
>
> Hi Phil,
>
> Sorry, I do not have much experience with REST books beyond having glanced 
> through "Rest in practice" and "the restful web services cookbook". These 
> are good resources. I have always tried to remain conscious of how your API 
> will appear to the user. It is easy to start with that mindset but lose it 
> over time. Of special importance is how easy your API is to pick up and use 
> for the first time.
>
> Good luck.
>
> Regards,
> Jeremy
>
> On Sunday, 28 January 2018 03:31:37 UTC, Philippe Derome wrote:
>>
>> It helps a great deal actually. Prior to reading your response this 
>> evening, I came to realize that indeed your solution is unique in type 
>> safety and avoiding annotations. I switched from C++ to Java 2-3 years ago 
>> and so never got into the world of Spring framework and annotations and 
>> didn't like the few annotations when dealing with Play or Guice. I haven't 
>> worked with Akka-Http yet but did work with Akka core and that went well 
>> enough. In short, I see annotations as stop gap measures and don't want to 
>> rely upon them. I also heard from the community (scala/fr in this instance) 
>> a strong reluctance to work with code generation, and your project avoids 
>> that as well. I read diagonally the description of your project and it does 
>> look very promising (support for Options and HLists, not just Products, and 
>> support for OAuth security).
>>
>> I also noticed some code generation project with Lagom/Swagger that does 
>> not build on CI, which was worrisome.
>>
>> If you have any insight on great book about web api design (principally 
>> REST based but not necessarily exclusively so), do you have 
>> recommendations? I see Irresistible APIs by Kirsten L. Hunter (at Manning) 
>> and two-three books by Matthias Biehl (API University Series) among recent 
>> contributions.
>>
>> Thanks much!
>>
>> Phil
>>
>>
>> On Saturday, January 27, 2018 at 7:19:35 PM UTC-5, Jeremy Townson wrote:
>>>
>>> Hi Phil,
>>>
>>> I would point out that:
>>> -- To support HTTP, Lagom uses *Play*. Currently, to create swagger docs 
>>> for APIs written with Play, you typically use Swagger *annotations*, as 
>>> supported by 
>>> https://github.com/swagger-api/swagger-play/tree/master/play-2.6/swagger-play2
>>> .
>>> -- Although the Lagom code generator is the start of another route to 
>>> Swagger docs, it looks very immature and poorly maintained. See 
>>> https://github.com/lagom/lagom/issues/280. (Apologies to Lagom if the 
>>> code is now maintained elsewhere).
>>> -- Lagom code generator is a *code generator*. That's to say, it is part 
>>> of your build pipeline.
>>>
>>> By contrast:
>>> -- Swakka works with Akka-Http (not play). And, as everybody on this 
>>> list will testify, Akka-Http is *much* better than Play:-)
>>> -- Swakka does not use the Swagger annotations. Instead, the API 
>>> metadata goes into *case classes*.
>>> -- Swakka is not a build-time code generator. It uses scala functions at 
>>> runtime, which are run when the akka-http server boots up.
>>>
>>> In my opinion (but only my opinion):
>>> -- Lagom probably makes a lot of sense for an architect in a large 
>>> organization with a lightbend support contract, trying to achieve 
>>> consistency of tech across a number of teams. But as a developer, I would 
>>> not use it. It makes more sense to pick and chose the tools you need on a 
>>> case by case basis (not to imply that Lagom's stack is poor in any way, but 
>>> why tie one's self to it?).
>>> -- a key decision for new web projects is often where to use Akka-Http 
>>> or Play. I hope that, from an API doc perspective, Swakka now makes 
>>> Akka-Http the better choice, but the overall decision is obviously wider 
>>> than just API docs.
>>>
>>> Hope that is of some help.
>>>
>>> On Saturday, 27 January 2018 17:25:06 UTC, Philippe Derome wrote:

 Jeremy,

 do you have familiarity with the Lagom Code Generator project 
  
 ? 
 I am interested in building web services using Lightbend technologies 
 (Akka-Http and/or Lagom) while leveraging Swagger documentation of APIs 
 for 
 external clients/consumers. If you have familiarity with stated Lagom 
 project, I'd appreciate your views on the two approaches, i.e. that and 
 Swakka.

 Thanks,

 Phil

 On Wednesday, January 24, 2018 at 5:18:59 PM UTC-5, Jeremy Townson 
 wrote:
>
> Hi Akka users,
>
> This is an update about Swakka, an addon for generating 
> OpenApi/Swagger docs with Akka-Http. I introduced Swakka in August last 
> year. Back then it was new, unstable and I recommended people not to use 
> it. 
>
> Yesterday, I cut a v0.5 release. Whilst the library does not cover 
> Swagger 100%, it does cover everything in the Swagger’s 

[akka-user] Re: Recommendations on a PoC for system migration from VB.NET to Scala/Akka stack

[Damian Blazejewski]

Generally, it sounds good.

i. -> you don't say anything about the deployment but I would think about 
Akka Cluster from the beginning.
iv. -> what data do you persist? You can do it asynchronously without 
blocking the rest api using Kafka. Or maybe Akka Persistence would work for 
you?

On Thursday, January 25, 2018 at 3:56:37 PM UTC+1, Som Shankar 
Bhattacharyya wrote:
>
> I want some suggestions/recommendations on the following.
>
>
> Today we have a legacy .NET system that gathers information from customers 
> environment and reports back to our backend.
>
> Now this system is built the following way,
>
> The client is a VB.Net application.(Usually running outside our network)
>
> The back end is a combination of REST services and traditional web 
> services. All in ASP. These services have their database calls etc.
>
>
> *Motivations:*
>
>
> i. Migrating the legacy framework is essential simply because of 
> maintainace cost.
>
> ii.Our services are going to be hit very heavily this coming year with a 
> big increase in clients and reducing intervals of time between client polls 
> and i want to showcase how the Scala/Akka stack can provide better 
> performance in this regard.  
>
> Now i want to demo advantages of having this work done in the Scala/Akka 
> framework.
>
> I am wondering what approach should i take to best highlight the 
> advantages of adopting this stack.
>
> I already have a small REST service implemented that does a connect to a 
> database and get/set some data. I have implemented that as a Akka HTTP REST 
> service.
>
> But i haven’t mimicked the client or the other web services in question.
>
> With my limited knowledge of this stack i might still be able to implement 
> a client and a web service but i want to have a focused approach on what to 
> highlight and how to do so.
>
>
> *Initial thoughts:*
>
> i.Write a Scala program with Akka actors. I need actors to abstract the 
> different work the client needs to do in parallel. Today we do those using 
> a few windows services.
>
> ii.Have the already implemented REST service on a separate machine.
>
> iii.I need to write at least another web service(will it be a better idea 
> to write all services as REST ? )
>
> iv.Figure out a way to save data to the database from the services at 
> lightning speed. Today we have to write to the file system first and thena  
> different service slurps it up and persists to the database. Maybe we can 
> have some message broker here that can be used ?
>
>
> I need someone to discuss this with and come to a focussed work item.
>
>
> Much thanks !
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka typed - first impressions

[Patrik Nordwall]

Hi Tal,

Thanks a lot for taking it for a spin and sharing feedback. Comments
inline...

sön 28 jan. 2018 kl. 14:10 skrev Tal Pressman :

> I finally had the chance to use Akka Typed, and wanted to share my
> experience. So basically, I took a small demo project that was based on
> untyped actors, and implemented it using typed ones. (This is based on
> 2.4.8, but I think most of it is still relevant)
>
> To start off with the good things:
> * Typed actors completely eliminated bugs involving mixing up `ActorRef`s
> - passing wrong refs, mixing up order of parameters, sending responses to
> the wrong place.
> * The functional approach taken for typed actors (behaviors returning the
> next behavior) also eliminated bugs that revolved around "doing stuff from
> `Future` callbacks".
> * The thing I was probably worried about most - not having `sender` any
> more - turned out to be a non-issue. In fact, because now it has to be on
> the received message, it makes it immutable, thus helping with the
> `Future`-related bugs.
>
> Now for the "annoyances" (in no specific order):
> * Using the various factory methods to create behaviors means you don't
> have direct access to "protected" behavior methods, most notably the
> ActorContext. If you need it, you either use `Actor.immutable` and get a
> "new" context with each message, or you use Actor.deferred which is a bit
> more clunky (you need a function that returns a behavior, which is itself a
> function).
>

That is “only” when you need the context when the actor is started. When
receiving messages the context is always there as a parameter.

One  perhaps related thing is that for a “more complicated” actor you
typically want to break it up in many methods/functions and you have to
pass a lot of parameters around to all. I’m not sure if that is only me
that see that as somewhat annoying. One way is to anyway create an
exclosing class and keeping such common parameters there. Especially in
Java I think that will often be used. (Or use mutable behavior).


> * This is more of a Scala type-inference issue, but having to specify the
> type when using `ask` is pretty annoying. What seems to work best for me is
> having utility methods
> on the "actor" that return `ActorRef[Response] => Message`, but it's a bit
> boilerplatey.
>

There is a new actor-to-actor ask. Would be interesting to hear what you
think of that.
https://github.com/akka/akka/pull/24335


> * Another issue related to asking is that there is no equivalent to
> untyped ask's Status.Failure. If the "request" can fail, this has to be
> modeled in the response (replying with a `Try`, or something equivalent),
> and means that now the caller has 3 cases to handle instead of 2. So now
> instead of ask-map-pipe in one line, it turns into
> ask-transform(3 cases)-foreach.
>

Failure case is only for timeout, and in the actor-to-actor ask that is
represented as a specific message that you define.


> * No "easy" access to logging - there's already a PR waiting for this, so
> not really an issue.
>
> Overall, though, I have to say it's shaping up real nicely. I'm looking
> forward to see what happens to it next.
>

Glad to hear that. Yes, we agree, it’s going to be awesome.

/Patrik

>
>
> Tal
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Play Controller/Akka Actor Ask Pattern Question

[Justin du coeur]

No, "ask" shouldn't have this problem.  Each ask() operation creates a
little pseudo-Actor under the hood, which is unique for this operation,
which will be the receiver of the response.  So long as the Actor is
responding to sender(), the response should go to the ask() that initiated
this message; cross-talk shouldn't be possible.  (This is actually a very
common situation.)

On Sat, Jan 27, 2018 at 5:56 PM, Joseph Mansigian <
joseph.c.mansig...@gmail.com> wrote:

> Hello All,
>
> I am making a Scala/Akka Actor based application.
>
> It is necessary for me to query an actor from a controller.
> The queried actor is always the same; only one of these exist.
>
> From the controller I am using the "ask' pattern to send a query message
> to the actor.
> The query message contains a unique key that the actor uses to lookup
> information which it
> formats into a response message and sends the message back to the
> controller.
>
> I have coded this and it seems to work fine; used it extensively.
>
> Here is my concern:
>
> Many clients can be making queries at once.  Let's say that there are two
> queries overlapping in time.
> One of the queries contains the key "abc".  The other query contain the
> key "xyz".
> Since this is async. can a race condition occur that responds to the "abc"
> keyed query with
> the "xyz" keyed data because "xyz" arrives first.  Maybe I am worrying
> about nothing.  Is this managed automatically under the hood?
>
> Thanks, Joe
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Graph materialized value of websocket upgrade

[Thai]

Hi Mathieu,

Sorry to re-open a quite old topic. I'm looking for an example exactly like 
this one "*a websocket server for which there is no 1-1 relation between 
incoming and outgoing messages. The client can send messages at any time 
which may or not have a reply from the server. The server can push messages 
at any time which may or not have a reply from the client*". It's really 
easy in non-Akka world (e.g. spring websocket, jetty websocket ...). Do you 
have any example (scala version is fine too) for me to follow?

Regards. 

On Tuesday, May 2, 2017 at 6:35:33 AM UTC-4, Mathieu Bruyen wrote:
>
> Hello,
>
> (this is more related to akka-http but there seem to be no dedicated group)
>
> I am trying to setup a websocket server for which there is no 1-1 relation 
> between incoming and outgoing messages. The client can send messages at any 
> time which may or not have a reply from the server. The server can push 
> messages at any time which may or not have a reply from the client. I 
> wanted to let actors handle and produce these messages. Following the doc 
> 
>  
> I am using Sink#actorRefWithAck to push incoming messages to the 
> entrypoint/router actor and let it do it's job. For outgoing messages in 
> the options suggested by the doc 
> 
>  
> I was planning to use Source#queue and give this queue to all the actors 
> which might need to push to the queue. I targeted this solution because it 
> allows for backpressure management.
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Swakka - a new extension to akka-http for Swagger/OpenApi

[Jeremy Townson]

Hi Phil,

Sorry, I do not have much experience with REST books beyond having glanced 
through "Rest in practice" and "the restful web services cookbook". These 
are good resources. I have always tried to remain conscious of how your API 
will appear to the user. It is easy to start with that mindset but lose it 
over time. Of special importance is how easy your API is to pick up and use 
for the first time.

Good luck.

Regards,
Jeremy

On Sunday, 28 January 2018 03:31:37 UTC, Philippe Derome wrote:
>
> It helps a great deal actually. Prior to reading your response this 
> evening, I came to realize that indeed your solution is unique in type 
> safety and avoiding annotations. I switched from C++ to Java 2-3 years ago 
> and so never got into the world of Spring framework and annotations and 
> didn't like the few annotations when dealing with Play or Guice. I haven't 
> worked with Akka-Http yet but did work with Akka core and that went well 
> enough. In short, I see annotations as stop gap measures and don't want to 
> rely upon them. I also heard from the community (scala/fr in this instance) 
> a strong reluctance to work with code generation, and your project avoids 
> that as well. I read diagonally the description of your project and it does 
> look very promising (support for Options and HLists, not just Products, and 
> support for OAuth security).
>
> I also noticed some code generation project with Lagom/Swagger that does 
> not build on CI, which was worrisome.
>
> If you have any insight on great book about web api design (principally 
> REST based but not necessarily exclusively so), do you have 
> recommendations? I see Irresistible APIs by Kirsten L. Hunter (at Manning) 
> and two-three books by Matthias Biehl (API University Series) among recent 
> contributions.
>
> Thanks much!
>
> Phil
>
>
> On Saturday, January 27, 2018 at 7:19:35 PM UTC-5, Jeremy Townson wrote:
>>
>> Hi Phil,
>>
>> I would point out that:
>> -- To support HTTP, Lagom uses *Play*. Currently, to create swagger docs 
>> for APIs written with Play, you typically use Swagger *annotations*, as 
>> supported by 
>> https://github.com/swagger-api/swagger-play/tree/master/play-2.6/swagger-play2
>> .
>> -- Although the Lagom code generator is the start of another route to 
>> Swagger docs, it looks very immature and poorly maintained. See 
>> https://github.com/lagom/lagom/issues/280. (Apologies to Lagom if the 
>> code is now maintained elsewhere).
>> -- Lagom code generator is a *code generator*. That's to say, it is part 
>> of your build pipeline.
>>
>> By contrast:
>> -- Swakka works with Akka-Http (not play). And, as everybody on this list 
>> will testify, Akka-Http is *much* better than Play:-)
>> -- Swakka does not use the Swagger annotations. Instead, the API metadata 
>> goes into *case classes*.
>> -- Swakka is not a build-time code generator. It uses scala functions at 
>> runtime, which are run when the akka-http server boots up.
>>
>> In my opinion (but only my opinion):
>> -- Lagom probably makes a lot of sense for an architect in a large 
>> organization with a lightbend support contract, trying to achieve 
>> consistency of tech across a number of teams. But as a developer, I would 
>> not use it. It makes more sense to pick and chose the tools you need on a 
>> case by case basis (not to imply that Lagom's stack is poor in any way, but 
>> why tie one's self to it?).
>> -- a key decision for new web projects is often where to use Akka-Http or 
>> Play. I hope that, from an API doc perspective, Swakka now makes Akka-Http 
>> the better choice, but the overall decision is obviously wider than just 
>> API docs.
>>
>> Hope that is of some help.
>>
>> On Saturday, 27 January 2018 17:25:06 UTC, Philippe Derome wrote:
>>>
>>> Jeremy,
>>>
>>> do you have familiarity with the Lagom Code Generator project 
>>>  
>>> ? 
>>> I am interested in building web services using Lightbend technologies 
>>> (Akka-Http and/or Lagom) while leveraging Swagger documentation of APIs for 
>>> external clients/consumers. If you have familiarity with stated Lagom 
>>> project, I'd appreciate your views on the two approaches, i.e. that and 
>>> Swakka.
>>>
>>> Thanks,
>>>
>>> Phil
>>>
>>> On Wednesday, January 24, 2018 at 5:18:59 PM UTC-5, Jeremy Townson wrote:

 Hi Akka users,

 This is an update about Swakka, an addon for generating OpenApi/Swagger 
 docs with Akka-Http. I introduced Swakka in August last year. Back then it 
 was new, unstable and I recommended people not to use it. 

 Yesterday, I cut a v0.5 release. Whilst the library does not cover 
 Swagger 100%, it does cover everything in the Swagger’s famous PetstoreV2 
 sample. Therefore it should document many real world APIs.

 If you are creating Akka-Http endpoints and have a need to document 
 them, I recommend you check out the project at