|
| 1 | +- Start Date: 2018-07-16 |
| 2 | +- RFC PR: [#41](https://github.com/SAP/ui5-tooling/pull/41) |
| 3 | +- Issue: https://github.com/SAP/ui5-server/issues/13 |
| 4 | +- Affected components |
| 5 | + + [ ] [ui5-builder](https://github.com/SAP/ui5-builder) |
| 6 | + + [x] [ui5-server](https://github.com/SAP/ui5-server) |
| 7 | + + [ ] [ui5-cli](https://github.com/SAP/ui5-cli) |
| 8 | + + [ ] [ui5-fs](https://github.com/SAP/ui5-fs) |
| 9 | + + [x] [ui5-project](https://github.com/SAP/ui5-project) |
| 10 | + + [ ] [ui5-logger](https://github.com/SAP/ui5-logger) |
| 11 | + |
| 12 | +# RFC 0003 Proxy capabilities of ui5-server |
| 13 | +## Summary |
| 14 | +Add proxy capabilities to the ui5-server module. It should allow to simulate an applications runtime on a remote system locally. |
| 15 | + |
| 16 | +## Motivation |
| 17 | +As an application or library developer, I want to be able to develop applications locally and test them in an environment as close to the production environment as possible. Meaning that resources that are not available locally are automatically retrieved from a given remote system. |
| 18 | + |
| 19 | +Such resources can be an OData service endpoint but also runtime artifacts like UI5 libraries. |
| 20 | + |
| 21 | +**Example:** I want to be able to test an application in a Fiori Launchpad environment without having anything but the application source code available locally. All other resources shall be proxied from, e.g. a NetWeaver ABAP system. |
| 22 | + |
| 23 | +## Detailed design |
| 24 | +### Possible use cases |
| 25 | +#### A: Use local resources but proxy specific requests to remote system |
| 26 | +- Everything is served from local resources expect requests matching a predefined list, those are proxied to a remote system |
| 27 | +- Possibly multiple proxies to different systems (if required) |
| 28 | +- Useful for |
| 29 | + + OData scenarios |
| 30 | + * Only requests for an OData service endpoint shall be proxied to a given system |
| 31 | +- Possible implementation in [PR #38](https://github.com/SAP/ui5-server/pull/38) |
| 32 | + |
| 33 | +#### B: Use remote system environment but serve specific requests from local resources |
| 34 | +- Everything is proxied from a remote system expect requests matching a predefined list, those are served form local resources |
| 35 | +- Proxy should probably work against a single remote system |
| 36 | +- Useful for |
| 37 | + + all development |
| 38 | + * Testing changes of a limited set of resources in any remote system environment |
| 39 | +- Could also be realized with use case C by facilitating the virtual FS of ui5-fs |
| 40 | + |
| 41 | +#### C: Simulate remote system environment |
| 42 | +- One or more local projects with dependencies maintained between them |
| 43 | +- Proxy shall forward every request that can't be fulfilled by the local resources to a remote system |
| 44 | +- Proxy should probably work against a single remote system |
| 45 | +- Useful for |
| 46 | + - application and library development |
| 47 | + + No need to maintain/update framework dependencies locally |
| 48 | + - framework development |
| 49 | + + e.g. test applications deployed in a system against a different version of OpenUI5/SAPUI5 |
| 50 | + |
| 51 | +### Rewriting request URL |
| 52 | +In all three use cases it might be required to rewrite some URLs. Examples are: |
| 53 | +- Application cache buster processed URLs (see https://help.sap.com/viewer/0ce0b8c56fa74dd897fffda8407e8272/7.5.9/en-US/d415dd8911a645759373dc1a70b93f3d.html) |
| 54 | +- Preloads (Component-preload.js, library-preload.js, library-preload.json) |
| 55 | + + e.g. when serving an application from local resources, a Component-preload.js request for it should be suppressed by responding with 404 - Not found. |
| 56 | +- Custom bundles |
| 57 | + + This is required whenever a deployed application or library tries to load a custom bundle which shall be served by local (non-bundled) resources |
| 58 | + + e.g. Fiori Launchpad has a custom bundle of the sap.ui.core library. When serving this library from local resources, a bootstrap-bundle needs to be generated on-the-fly (as there is no fallback logic) |
| 59 | +- Language specific i18n files |
| 60 | + + This depends on the project setup. I.e. whether all language files are part of the projects source or if some are only available in the remote system |
| 61 | + |
| 62 | +### Authentication |
| 63 | +The proxy shall be able to forward the following authentication methods: |
| 64 | +- SAML2 |
| 65 | +- Basic access authentication |
| 66 | +- ...? |
| 67 | + |
| 68 | +In addition, authentication for a transparent proxy (e.g. some corporate proxies) sitting between the local machine and the remote system shall be supported. |
| 69 | + |
| 70 | +### Configuration |
| 71 | +#### Project setup |
| 72 | +It is to be decided whether a proxy is to be configured within a single project or as a separate project. |
| 73 | + |
| 74 | +A developer might want to use a proxy across multiple projects (i.e. one or more applications and libraries). In a scenario where the main target of the proxy is to simulate the environment of a system (use case C), it might make sense to have a standalone project representing a system which then maintains dependencies to application- and library-projects that shall be served from the local machine. This allows for easy switching between system environments. |
| 75 | + |
| 76 | +It might make sense to have different types of proxy configurations depending on the use case (see above). |
| 77 | + |
| 78 | +To follow the [extension configuration proposal in RFC 1](https://github.com/SAP/ui5-tooling/blob/rfc-type-ext/rfcs/0001-type-extensibility.md#generic-handling-of-extension) a proxy configuration could look like this: |
| 79 | +```yaml |
| 80 | +specVersion: "0.1" |
| 81 | +kind: proxy |
| 82 | +type: simulate-system |
| 83 | +metadata: |
| 84 | + name: proxy-system-XYZ |
| 85 | +proxy: |
| 86 | + remoteRoot: "https://..." |
| 87 | +``` |
| 88 | +
|
| 89 | +This configuration could still be combined with that of a single project like this: |
| 90 | +```yaml |
| 91 | +specVersion: "0.1" |
| 92 | +type: application |
| 93 | +metadata: |
| 94 | + name: my.application |
| 95 | +---- |
| 96 | +specVersion: "0.1" |
| 97 | +kind: proxy |
| 98 | +type: simulate-system |
| 99 | +metadata: |
| 100 | + name: proxy-system-XYZ |
| 101 | +proxy: |
| 102 | + remoteRoot: "https://..." |
| 103 | +``` |
| 104 | +
|
| 105 | +#### Defining what requests should be processed by the proxy |
| 106 | +TBD |
| 107 | +
|
| 108 | +
|
| 109 | +## How we teach this |
| 110 | +TBD |
| 111 | +
|
| 112 | +## Drawbacks |
| 113 | +TBD |
| 114 | +
|
| 115 | +## Alternatives |
| 116 | +Custom proxy solutions using thirdparty software can achieve the same but may cause a setup and learning effort. |
| 117 | +
|
| 118 | +## Unresolved questions |
| 119 | +TBD |
| 120 | +
|
0 commit comments