I find most of our customer base uses GWT RPC. The story on using this may make using gwt feel complicated.
If we can just compile into the web app directory for the entire process, then there would be no need for a proxy. From what I could tell it would be 3 args, -war, -browser (or maybe some user agent) and module. I'll see if I can prototype the service this week and provide it for chewing on. Do you think this is even possible? -Brandon On Monday, October 24, 2016 at 7:40:48 AM UTC-7, Daniel Kurka wrote: > > I am seeing a lot of arguments pop up about GWT RPC, but I think it should > not be considered for this discussion at all. In my mind GWT 2.8 will be > the last release that has GWT RPC and people should start migrating. I > think its perfectly fine do design a replacement to devmode without GWT RPC > support. > > On Mon, Oct 24, 2016 at 4:18 PM Jens <jens.ne...@gmail.com <javascript:>> > wrote: > >> Well it is just what I would ask for in order to replace local apache / >> nginx on developer machines with GWT devserver. It's not a problem to >> simply continue using a dedicated proxy either with CodeServer or a "no-op" >> devserver. >> >> Basically our setup is more a less the result of two decisions: Not >> serving static content from servlet containers (instead it's severed by >> load balancer/proxy) and using GWT-RPC. We need to be in control of which >> app version a customer gets served, even before logging in, and that >> backend requests will be redirected to a matching server app version >> (because of GWT-RPC policy files and rolling updates). Thats why our >> production mapping is https://app.example.com/<customer>/ => >> <private-backend>/<app>_<build>/ for backend requests and the load >> balancer does the mapping using URL rewriting. >> >> During development we just have a single app so the rewriting is a lot >> simpler but it still exists. Given that our server code sets cookies for >> the production domain only (I guess some paranoid security decision), the >> cookie domain needs to be rewritten during development to a local ip / >> localhost. >> >> Given that static content is served by the load balancer / proxy itself, >> all caching headers (*.nocache.*, *.cache.*) are configured outside the >> servlet container. For consistency cache headers for dynamic host page are >> also configured outside the servlet container. So we don't have any >> ServletFilter doing it. >> >> >> >> Hey, this is a currently just a prototype coded over the week-end ;-) >>> I'd personally prefer not writing anything to the webapp, but as >>> acknowledged in the OP we could have a -launcherDir option for >>> serialization policies and possibly public resources >>> >> (but then why not just use CodeServer with -launcherDir directly? one >>> difference could be that devserver would never overwrite a file for >>> example…) >>> >> >> Well I could also ask: Why not just having a single solution that simply >> works? Personally I don't like having different "entry points" for >> development. IMHO its more straight forward (especially for beginners) to >> just have CodeServer or just have devserver, but not both (even with >> different behavior for stub.nocache.js !). >> >> Adding gwt.codeserver.host and renaming -launcherDir to >> -publicResourcesDir would be fine I guess. >> >> >> >> Next there are people embedding the module.nocache.js file directly into >>>> their host page (like me ;-) basically our host page is a servlet) and >>>> that >>>> should work also during development. >>>> >>> >>> I can't think of any other way to make it work (I did that too in one >>> app) than having a way to switch from inlined *.nocache.js to external >>> *.nocache.js on your server. There's absolutely no risk shipping that in >>> production (it's only a network optimisation to avoid one HTTP request) so >>> it looks like an acceptable compromise to me. >>> >> >> Well devserver could special case host page loading ("/" or a >> configurable host page url) and inspect the result of the backend server to >> decide wether or not some inline *.nocache.js file needs to be replaced. To >> keep it simply I would require special enclosing start / end comments in >> the dynamic host page to make it compatible with devserver. Then the >> content in between these comments will be replaced with the stub.nocache.js. >> >> >> >> >>> …or you could just continue using CodeServer with -launcherDir. >>> >> >> Single solution preferred ;-) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "GWT Contributors" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-web-toolkit-contributors/361aafb5-d40d-433c-a6ba-6209069e5550%40googlegroups.com >> >> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/361aafb5-d40d-433c-a6ba-6209069e5550%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/803664ba-a362-44cc-9578-bcc3a331186a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
