Isn't it true that your routes need to be in a trait t be able to make use
of the Routing Testkit?
On Fri, Oct 7, 2016 at 12:08 PM, <jpsteinm...@skydance.com> wrote:
> Thank you for the response Johan but I'm not sure that really answers my
> question but perhaps I can ask some other questions that may help to get
> what I need.
>
> So far I have been operating on the assumption that I can have only one
> route function at the top most level to define all of the routing
> information for my server. This is due to the Http object taking in a
> single route object during a bindAndHandle like so:
>
> ActorMaterializer materializer = ActorMaterializer.create(actorSystem);
> final Flow<HttpRequest, HttpResponse, NotUsed> routeFlow = new
> RestApiDirectives().createRoute().flow(actorSystem, materializer);
>
> CompletionStage<ServerBinding> httpBinding = http.bindAndHandle(routeFlow,
> ConnectHttp.toHost(httpHost, httpPort), materializer);
>
>
> This leads me to having a class that extends some directives class with a
> single createRoute() function that contains all of the routing logic for
> the entire server. Example:
>
> public class RestApiDirectives extends AllDirectives {
> public Route createRoute() {
> return ...;
> }
> }
>
>
> So if I want to break out my route implementation into further classes
> then how do I bring those new route functions into the main createRoute? So
> far I've done it by a crazy chain of inheritance similar to how Akka does
> it. However, just now I did try out simply calling *new *on the owning
> class and making the function call instead. Example...
>
> public Route create() {
> return route(
> new SubsystemA().createRoute(),
> new SubsystemB().createRoute(),
> new SubsystemC().createRoute(),
> new SubsystemD().createRoute()
> );
> }
>
>
> This actually seems to work but feels as equally terrible as the crazy
> chain of inheritance. Why? This is because any time I have an instance of a
> class I assume there is some state information being maintained that
> matters. If I need to instantiate an initial object to create a route it
> stands to reason that any further work done inside that route needs to pass
> along it's state to the next object instance to function correctly. The
> fact that I can arbitrarily instantiate new objects with route functions
> and call them means that there is no state being maintained across
> instances that are unique to the original routing object. So then why are
> the directives not simply static functions? It would be a whole lot simpler
> to understand, organizationally, that I can create as many classes with
> static routing functions as I want and simply chain them together. The
> current approach just causes lots of confusion and considerable wasted
> time, especially when there is no documentation or example code anywhere
> that clearly states that you can link routing functions in this way.
>
> So I guess I've found my own answer here but please consider fixing the
> documentation to make this information very clear and add some real world
> examples in how a complicated routing structure can be achieved that goes
> beyond a single class with one createRoute() function.
>
> Thanks for your time!
>
> On Friday, October 7, 2016 at 9:38:45 AM UTC-7, Akka Team wrote:
>>
>> In general, don't try to mimic the way it is done in Akka HTTP itself
>> unless you actually have the same requirements. (To support both mixin and
>> static imports, dealing with both a Scala and Java API etc)
>>
>> Modularising the routes is not different from modularising other kinds of
>> codebases, you have options ranging from classes and objects to functions,
>> each having their own pros and cons. If they have dependencies you have to
>> provide that in some way, which you can either do directly "hardcoded" or
>> by some form of injection (note that I'm using inject in the wider sense of
>> "someone else providing a thing I need" rather than "use a DI-framework"
>> here) depending on your needs.
>>
>> Think about how you would usually separate concerns (usually composition
>> over inheritance is a good idea here) and provide their respective
>> dependencies to them. Also, if you already do separate concerns in your
>> codebase, think about using the same way for routes rather than introducing
>> an entirely different way to do that.
>>
>> --
>> Johan
>> Akka Team
>>
>> On Fri, Oct 7, 2016 at 11:09 AM, <jpste...@skydance.com> wrote:
>>
>>> Yes I understand that much and I have broken up my implementation into
>>> various Route producing functions as you've suggested. The problem I have
>>> is that it appears for all of this to work I must have all of these
>>> functions described in a singular class namespace. This appears to be due
>>> to some inherent state being maintained that can't be easily passed from
>>> one class to another.
>>>
>>> Either you define all of the Route functions in a single class file or
>>> you end up with this massive chain of dependent classes which gets ugly
>>> really fast. For instance if I've broken up my routing functions based on
>>> subsystems I may have one or more classes per subsystem. In order to bring
>>> it all together at the route level I then need each of those classes to be
>>> included from one class I can extend. So I ended up with a class hierarchy
>>> like this...
>>>
>>> AllMyDirectives extends SubsystemAandBandCandDDirectives extends
>>> SubsystemAandBandCDirectives extends SubsystemAandBDirectives extends
>>> SubsystemADirectives ...
>>>
>>> This is a nightmare to maintain as any new subsystem that gets added
>>> requires modification to the chain and that has rippling effects. It also
>>> requires that each route function have a unique name in the entirety of the
>>> global set of directives. You can see this same behavior if you open
>>> AllDirectives and follow it's dependencies all the way down the chain.
>>> There must be a better way to organize these directives into classes that I
>>> can later aggregate in a more meaningful way that allows better separation
>>> of concerns. Something like...
>>>
>>> @Include(SubsystemADirectives, SubsystemBDirectives,
>>> SubsystemCDirectives, SubsystemDDirectives,...)
>>> AllMyDirectives extends AllDirectives {
>>> ...
>>> }
>>>
>>> This still wouldn't solve the namespace problem but it's at least a
>>> whole heck of a lot easier to maintain and glue together. But maybe
>>> there is something I am just missing from the documentation that does work
>>> more like this?
>>>
>>> On Friday, October 7, 2016 at 8:28:57 AM UTC-7, Rafał Krzewski wrote:
>>>>
>>>> I'm not familiar with Java API but my impression is that AllDirectives
>>>> is a device for bringing all pre-defined directives in scope of your Route
>>>> producing functions.
>>>> Routes themselves are values and you can combine them to produce more
>>>> complex routes. For example you could have several classes extending
>>>> AllDirectives containing methods that produce Route values.
>>>> Such methods could take other Routes as parameters, to support nesting
>>>> and references to "services" needed to implement route's functionality
>>>> (ActorRefs and so on).
>>>> Then you could have a function that constructs all the partial routes
>>>> and wires them together to produce the root route of your application.
>>>>
>>>> Hope that helps,
>>>> Rafał
>>>>
>>>> W dniu środa, 5 października 2016 18:11:17 UTC+2 użytkownik
>>>> jpste...@skydance.com napisał:
>>>>>
>>>>> Now that i'm finally getting the hang of creating routes for akka http
>>>>> i'm discovering that I need a good way to organize everything. What is the
>>>>> recommended way to organize custom directives for routes into different
>>>>> files (specifically in Java)?
>>>>>
>>>>> Ideally i'd like to be able to define custom directives that handle
>>>>> processing of my REST API in an increasingly more complex fashion. So the
>>>>> primary route will capture large buckets of url's based on a sub-system
>>>>> and
>>>>> then hand off the additional work to other directives defined in other
>>>>> classes for further processing. However from what I can tell this isn't
>>>>> possible, is it?
>>>>>
>>>>> If I put everything in one file I am afraid it's going to get crazy
>>>>> out of hand with thousands of lines of code and possibly hundreds (ouch!)
>>>>> of directives and the class structure of AllDirectives is a little
>>>>> unnerving since it's one massive chain of single inheritance. That means
>>>>> i'd have to constantly be refactoring my chain of inheritance in order to
>>>>> add new systems to the API (more ouch!).
>>>>>
>>>>> How does everyone handle this organization?
>>>>>
>>>>> Jean-Philippe
>>>>>
>>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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+...@googlegroups.com.
>>> To post to this group, send email to akka...@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.
>
--
>>>>>>>>>> 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.
