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, <[email protected]> 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 >> [email protected] 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/ > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
