Closed amarinso closed 6 years ago
The deployment that we use to run MyThaiStar on an xPaaS mesh looks like this: Client and server are packaged as two individual Spring Boot applications and are deployed as two individual processes to the nodes of the xPaaS mesh. There is an ingress router in front of the platform that directs requests to URI's that start with "/restaurant" to the server that hostst the client and requests to URI's that start with "/mythaistar" to the backend. Of course the "client serving" Spring-Boot app needs to be configured with a corresponding base-URI. The backend server is identified by the client as "window.location" of the browser.
Let´ s not forget that My-Thai-Star not only serves as a reference application. First of all, it is a Showcase and example as well which should be easy to run and deploy. So any change which would be counter that primary requirement would not have my support
@andihess I don't really get anyway this client packaging in Spring Boot. We've been always using nginx as it is quite light and gives very good results. Also quite convenient for front-end apps and even more for Angular.
It really depends on your assumptions on a deployment / provisioning workflow of a web client. You can assume an approach where you deploy a bunch of individual JS files to a web-server. Or you assume that you want to deploy a self contained "package" (could be Spring-Boot or Dockerized nginx plus the JS for the client). My comment was NOT meant as a recommendation to do it like this, but just an information how it works if you want to host the client on an xPaaS cluster.
Having Spring Boot to serve static resources seems a bit overkill, embedded server is meant to deliver dynamic content and Angular files are all static, therefore something like nginx or Apache seems more appropriate.
Respect of the naming of the backend services I think having "/api" would more clearly show the intent of the server. It will be also more generic to use "api" instead of any particular name so templates and documentation is easier.
I think we should provide a "reference design" for deploying on a PaaS, and I see greater flexibility on deploying separatedly front and backend and a third proxy on front of them.
Hi, I think the simplest approach for small projects is to have frontend and backend in a single server. However, our best practice is to serve them separately. This is what we already do in MTS and what Andreas suggests for iPaas. Devon is all about patterns. Hence, IMHO we should also give defaults for the URL path patterns. As the frontend Path is what the end-user sees, it should have the natural name of the app (interface is the system). The backend path may by default be derived from the frontend path with a suffix "-api" (API is the system). Using analague convention for hostnames/IP or ports could reduce my configuration effort (convention over configuration). My learning from gateways/reverse-proxies in front is to put as little (business)logik and config into as possible.
BTW: Move discussion to Yammer?
Regards Jörg
Von meinem Windows Phone gesendet
Von: Andreas Hessmailto:notifications@github.com Gesendet: 08.02.2018 15:59 An: oasp/my-thai-starmailto:my-thai-star@noreply.github.com Cc: Subscribedmailto:subscribed@noreply.github.com Betreff: Re: [oasp/my-thai-star] Decouple Angular front-end from Java back-end in nginx (#75)
It really depends on your assumptions on a deployment / provisioning workflow of a web client. You can assume an approach where you deploy a bunch of individual JS files to a web-server. Or you assume that you want to deploy a self contained "package" (could be Spring-Boot or Dockerized nginx plus the JS for the client). My comment was NOT meant as a recommendation to do it like this, but just an information how it works if you want to host the client on an xPaaS cluster.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/oasp/my-thai-star/issues/75#issuecomment-364137576, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AB1YL816qcBc5P98RixqADO3w6i7V-mJks5tSwvGgaJpZM4R-Jf4.
Firma: Capgemini Deutschland GmbH Aufsichtsratsvorsitzender: Antonio Schnieder • Geschäftsführer: Dr. Michael Schulte (Sprecher) • Jost Förster • Dr. Peter Lempp • Dr. Volkmar Varnhagen
Amtsgericht Berlin-Charlottenburg, HRB 98814 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Added solution proposal in #77 @amarinso @ivanderk
Closing this as the solution was previously approved and merged in the #77 (totally based on this one) Therefore I'm closing this.
Thanks for your support @amarinso !
Cheers, Cristóbal
We should have a reverse proxy in front of both angular and Java (or other) backend
The same nginx that is serving the Angular resources shouldn't do the reverse proxy for the backend, as this couples too much the solution.
There should be a "parent" nginx configuration that does this match