Unfiltered on Finagle

[chris]

Hello list,

I wanted to get some feedback on an experimental module for using unfiltered as a frontend for finagle: https://github.com/chrislewis/unfinagled

We're evaluating tools to aid in building transparent network services on both ends of our stack, and twitter's finagle is a pretty attractive option. However, processing http requests for a non-trivial client-facing web application a'la netty primitives can be cumbersome, to put it mildly. On the other hand, unfiltered is awesome for this, never mind existing knowledge and code we have in house. It's early stage so there may be issues, but it is extremely small. Please share any feedback, especially if you are currently using or evaluating finagle (I'm new).

-chris

[Doug Tangren]

Very cool! Now I've seen unfiltered used both as a backend for scalatra and a front end for finagle. I've recently been embracing "the good parts" of the twitter scala ecosystem. This is a neat way of integrating with a core part of it. I'll definitely check this out. I would have called it "unfangled" :) Anyway, nice work. 

 

-chris

--
You received this message because you are subscribed to the Google Groups "Unfiltered" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unfiltered-sca...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[chris]

On Wednesday, July 24, 2013 8:18:46 AM UTC-4, doug wrote:

On Wed, Jul 24, 2013 at 12:58 AM, chris <ch...@thegodcode.net> wrote:

Hello list,

I wanted to get some feedback on an experimental module for using unfiltered as a frontend for finagle: https://github.com/chrislewis/unfinagled

We're evaluating tools to aid in building transparent network services on both ends of our stack, and twitter's finagle is a pretty attractive option. However, processing http requests for a non-trivial client-facing web application a'la netty primitives can be cumbersome, to put it mildly. On the other hand, unfiltered is awesome for this, never mind existing knowledge and code we have in house. It's early stage so there may be issues, but it is extremely small. Please share any feedback, especially if you are currently using or evaluating finagle (I'm new).

Very cool! Now I've seen unfiltered used both as a backend for scalatra and a front end for finagle. I've recently been embracing "the good parts" of the twitter scala ecosystem. This is a neat way of integrating with a core part of it. I'll definitely check this out. I would have called it "unfangled" :) Anyway, nice work. 

Thanks! Believe me, it took some effort to convince myself that giving finagle a go. We've had experience with past iterations of twitter scala libs which were then excised. I acknowledge that possibility now, but I see finagle a bit differently in that, more than a library, it's a framework for reliable, transparent and distributed service infrastructure. The ability to overlay unfiltered and get 100% transparency with existing code was the tipping point for me. Anyway, I hope to hear some feedback from the UF and finagled community.

[Dag Liodden]

This is great stuff, Chris!

We're using Unfiltered for many of our external APIs and are currently building an internal service back-end on Finagle. Being able to use Unfiltered for the service implementations and still get the Finagle benefits is perfect!

We've forked this and cut a release internally for some testing for now. It would be great if you'd cut an "official" beta release and get it published to a public repo. We'll make sure to send you pull requests if we have any updates / suggestions.

Thanks!

Dag

[Dustin Whitney]

ditto overhere 

--

[chris]

Glad to hear it! What I posted was a quick, personal PoC which has since been taken further internally. I expect to be able to open it up this week and will reply to this thread then. Thanks for the feedback!

[Dag Liodden]

Hi again,

I did a quick spike on allowing to respond with scala Futures. I like the Finagle concepts but the API is a bit messy and we try to avoid the Finagle APIs leaking into our code too much.

Basically, we want an our intents to be Reqeust => scala.concurrent.Future[Response]. I turned out to a bit trickier than I had envisioned, but I pushed a quick draft to https://github.com/daggerrz/unfinagled/tree/feature/scala-futures

The code needs some cleaning, but as it's been a while since I dug into the Unfiltered internals, I'd like to hear if there are any thoughts on the general direction.

A working spec at: https://github.com/daggerrz/unfinagled/blob/feature/scala-futures/src/test/scala/net/godcode/unfinagled/AsyncIntentSpec.scala

For the mapping, Intent => scala.Future => twitter.Future, see https://github.com/daggerrz/unfinagled/blob/feature/scala-futures/src/main/scala/net/godcode/unfinagled/UnfilteredService.scala#L48

Input appreciated!

Dag

[chris]

I'll take a look in the next day or so - busy week :-|

[chris]

All,

I have been given the go-ahead to open up the Novus repository; find it here: https://github.com/novus/unfinagled.

Sorry to any current forkers for the switch, but I want to make sure any momentum gained is directed at this project as it has resources behind it. It's pretty far along at this point, with server and test modules. There's a bit more cleanup to do, but it's in pretty good shape (I'll be implementing full plan, Pass and plan server support). Thanks for the feedback so far - please bang on it and submit suggestions, issues, and pull requests!

Also, I didn't mean to orphan the open pull but I didn't want top copy, paste, and lose its history. Dag do you mind submitting again against the new repo?

Lastly, I'm waiting on sonatype to get back to me about my account, so there aren't any artifacts available yet.

On Wednesday, July 24, 2013 12:58:19 AM UTC-4, chris wrote:

[Doug Tangren]

I did something a very small, very unfancy, project at work that used unfiltered for handling requests and twitters futures for doing work which may help to show you can can also use async intents and just map on twitters, or scalas, or whatevers futures and call respond on the async intents request with a normal response function ( its just a function ) -

  https://github.com/softprops/bowhaus/blob/master/src/main/scala/endpoints.scala#L37-L39

the request pattern for async requests is a little different from cycle intents in that is a partial function that returns unit but its up to the application for what to do with ( or how to write to ) the response. 

Not sure if that helps your designs but just throwing it out there that you don't have to use the cycle intent.

-Doug Tangren
http://lessis.me

--

[chris]

Snapshots for 0.3.0-SNAPSHOT are available at https://oss.sonatype.org/content/repositories/snapshots/. With the exception of the package change (sorry), versioning will follow apr/semver, so until 1.0, the goal is source compatibility.

[Dag Liodden]

Doug,

I wanted to make scala Futures "first-class" by allowing creating an intent type Request => Future[ResopnseF]. I.e, I don't want to add the completions handlers and invoke respond() manually - all of our responses are futures. Does what I did with FinaglePlan at https://github.com/daggerrz/unfinagled/tree/feature/scala-futures/src/main/scala/net/godcode/unfinagled make sense for that?

Dag

[Dag Liodden]

Chris,

Sure, just close it and I'll reopen it again later.

Dag

On Tuesday, July 30, 2013 10:04:26 PM UTC-4, chris wrote:

[Doug Tangren]

On Wed, Jul 31, 2013 at 11:58 AM, Dag Liodden <dagg...@gmail.com> wrote:

Doug,

I wanted to make scala Futures "first-class" by allowing creating an intent type Request => Future[ResopnseF]. I.e, I don't want to add the completions handlers and invoke respond() manually - all of our responses are futures. Does what I did with FinaglePlan at https://github.com/daggerrz/unfinagled/tree/feature/scala-futures/src/main/scala/net/godcode/unfinagled make sense for that?

cool. makes sense.

[Dag Liodden]

OK, good!

I think this abstraction might be useful for vanilla Unfiltered too. We'll put it to work internally and see how it pans out in practice and see if it makes sense to decouple it completely from the Finagle implementation.

Dag

[Nathan Hamblen]

On 07/31/2013 02:26 PM, Dag Liodden wrote:
> I think this abstraction might be useful for vanilla Unfiltered too.

Sure would, it's been on the back burner for a while. (The back burner
where nobody is working on it but everyone agrees it's a fine idea!)

[Dag Liodden]

Could it be as simple as this: https://github.com/daggerrz/Unfiltered/compare/feature;scala-futures ?

Not sure how to deal with passing here, though.

Dag

[Dag Liodden]

Back from my holiday and just submitted a PR to the new repo: https://github.com/novus/unfinagled/pull/4.

Let me know what you think,

Dag

On Tuesday, July 30, 2013 10:04:26 PM UTC-4, chris wrote:

[Nathan Hamblen]

On 08/16/2013 04:07 PM, Dag Liodden wrote:
> Back from my holiday and just submitted a PR to the new repo:
> https://github.com/novus/unfinagled/pull/4.

Cool, I'm on my way *off* to vacation but I'm planning to catch up on
unfiltered stuff in between canoe trips. No internet! So you won't hear
from me until after. :)

Nathan

[chris]

Thanks again Dag. I made the changes we discussed on the pull request, dropped 2.9.2 support, and published 0.3.0 snapshots to sonatype. Let me know if you have issues and please continue to suggest ideas and pulls as needed!

[Lee Avital]

Reviving this thread after finding it a month ago!

If anyone's interested, I (experimentally) started working on this:

https://github.com/leeavital/unfangled

It doesn't actually use unfiltered, but it uses the ideas of partial functions and filters and request matchers. The api is Request => Future[Response].