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 <[email protected]> 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujirgPjFnGzPGKKp5zUB497mZko%2BTzKMsAAbYOSaLBRJNTw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
