Hi, On Tue, Oct 18, 2016 at 2:25 AM, fzb <[email protected]> wrote:
> Hi > > > Here are few UI snaps of the application we had built using wicket. > > <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/Artboard.png> > <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/ > 2016-10-17_08.png> > <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/ > 2016-10-18_08.png> > > The stack we had used to build this app are .. > > Wicket - Client > Hibernate - Persistence > ehCache - Caching > Spring - to glue all pieces together > MySql (AWS RDS) - Database > CXF - REST > Jasper - Reports > Open Flash Chart - Chart (Pending Migration to JS based) > DropWizard Metrics - to collect metrics & report > Jetty in dev & Tomcat in live server > > The Pros.. in this app > 1. Easy to maintain > 2. Easy to write custom components. > 3. Not much of browser issues since we don't use JS much except for those > which wicket does. > 4. Use heavily Ajax via Wickets approach. Nothing on our own. > 5. Consistent look n feel, since developers use pre developed with css > built in components for new screens. > > Overall meets the current requirement. > > The Top 3 problems we want to address are .. > > *1. Do not have URL for any document .. say Purchase Doc.. because it is > nested inside component hierarchy. > * > > We designed only the top level icon based navigation as Page based. Which > means to navigate from one page to another we use > setResponsePage.(newPage).. For these pages we have URLs. For the second > level menu (black bar - below the icon menu) & internal tab navigation, > going from list view to detail view etc we had use component replace .. by > repainting the container with the new content. > > cntr.addOrReplace(newComponent); > target.add(cntr); > > 90% of user interactions are via this method. Hence we are not able to > generate URLs for these internal UIs. If user needs to traverse to any of > these, then they navigate to the page.. click menu.. click tab to navigate. > Take a look at https://github.com/martin-g/blogs/tree/master/ajax-history This project shows how to use HTML5 History API to manipulate the url even for Ajax interactions. If you need deep linking since the beginning you will have to put the menus ids/names in the mount path. E.g. /level1/#{level2}/#{level3} where - level1 is the icon menu. It links to a page, as it does now. - level 2 and level 3 are optional parameters. If they are available in page.getPageParameters() then initialize the TabbedPanel active tab to match the provided value > > *2. We are using single server. We want to use a load balancer and > increase > the servers to be able to meet scaling requirement. > * > Currently we just store the user details in session, after authentication. > We need to be able to identify each request and associate session details > (from cache) to the request, so that the request can be served by either > servers.. > Normal Session replication should work just fine. But you can also take a look at https://github.com/magro/memcached-session-manager and/or https://github.com/wicketstuff/core/tree/master/datastores-parent > > > *3. Move all static contents out of war file. * > To reduce the traffic coming in to application server, we intend to move > the > static resources out of appl war file to CDN. > We have used a custom IRequestMapper that wraps Wicket's ResourceMapper that in Production mode produces CDN urls instead of .../wicket/resource/com.example.Scope/css/some-123456.css. This way all the traffic for static resources goes directly to the CDN. > > *4. It is getting bigger n bigger.. Need to avoid making it monolithic * > We wanted to develop new features as micro services and slowly break the > whole app in to.. For service layers we understand how to group > functionalities.. for UI how to we break it in to multiple ? how to regroup > them as single app for the user. > Here are some options: 1) micro services == several small apps Here the question is whether you need to share the user session between those apps. Most probably - yes 2) I think you really need build (Maven, Gradle) modules Each "microservice" lives in its own module. This module provides everything specific to this functionality. The module depends on at least to other modules: - common - provides common "glue" code - components - provides smaller Wicket components re-used in other modules and base pages Each module could register itself in the Application e.g. by using Wicket's IInitializer, or Spring's component scan, or anything else > > Addressing these 4 will take our app to the next level. Please give your > suggestions on these .. > > - fzb > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > View this message in context: http://apache-wicket.1842946. > n4.nabble.com/Wicket-Appl-Cleanup-Scale-tp4675820.html > Sent from the Users forum mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
