Your server as webpack-dev-middleware about sp-rest-proxy HOT 10 CLOSED

we run Angular with WebPack and sp-rest-proxy, the way we do it is via Angular's environment variables - when the env=local we run the angular app out of localhost, and sp-rest-proxy kicks in to reroute _api calls from localhost to Real On-Premises farm.

from sp-rest-proxy.

I've made some experiments and will try to produce separate module which acts as webpack SharePoint proxy middleware. It should help guys working with webpack-dev-server and SharePoint greatly.

from sp-rest-proxy.

Added repository just for reference. I don't have any plans on it yet, since there is sp-rest-proxy, but who knows :)

from sp-rest-proxy.

Hi Ofer,

Thank for the idea, interesting one.

To tell you the truth, I do not use webpack intensively, just for basic assembling and bundling .js, .ts, .jsx, .tsx.

A lot of folks, with whom I talked, run proxy in parallel with the local serve (gulp serve, grunt serve, whatever) with front-end app and executing CORS request to the proxy. They usually use concurrently module to start these in one npm run command.

The proxy itself also can host local static files, in other words, proxy's static folder path can be targeted to front-end app dist folder and proxy's web server lift both (front-end and API backend) on the same domain.

From the first glance at webpack-dev-middleware the idea seems to be clear, yet could you please elaborate your vision of the architecture of sp-rest-proxy potential middleware layer for webpack or webpack middleware for sp-rest-proxy?

Webpack-dev-middleware actually can be added as an optional middleware to the proxy. What is the benefit? Recompiling front-end on local changes? Is it the same result as pointing proxy's static folder to the disc folder and running webpack watch task in parallel with the proxy?

Will think it out more.
Will be glad to here some more input from you and other folks who might be using sp-rest-proxy and webpack simultaneously and miss some functionality or something.

from sp-rest-proxy.

from sp-rest-proxy.

It can be a single command, something like this:

package.json

  ...
  "scripts": {
    ...
    "serveApi": "node ./sp-rest-proxy-server-starting-script.js",
    "serveApp": "[your favourite local serve approach]",
    "startServers": "concurrently --kill-others \"npm run serveApi\" \"npm run serveApp\""
    ...
  },
  ...

Run

npm run startServers

webpack was that I can use it for developing with hot changes to the local site as I save the JS files

Do you mean hot reload of the locally served page?
It is independent of the proxy and in works in scenario described by John's if a hot reload is configured in webpack serve.

Or do you mean saving (publishing) asset files to SharePoint on save? This is also achievable with spsave or even spsave-webpack-plugin.

from sp-rest-proxy.

from sp-rest-proxy.

@s-KaiNet,
Over the weekend I checked proxy in create-react-app generator.
It uses something simple like this:

const proxySetting = require(paths.appPackageJson).proxy;
const proxyConfig = prepareProxy(proxySetting, paths.appPublic);
// Serve webpack assets generated by the compiler over a web sever.
const serverConfig = createDevServerConfig(
  proxyConfig,
  urls.lanUrlForConfig
);
const devServer = new WebpackDevServer(compiler, serverConfig);

And this provides proxying localhost requests (not CORS, but on a current local server) to sp-rest-proxy then in it's way to SharePoint. I guess proxy setting can be more advanced as I mentioned in the example.

from sp-rest-proxy.

As far as I can understand in your scenario there are actually two proxy servers. One is sp-rest-proxy which directs requests to real sharepoint and the other one is webpack dev server proxy, which points to your sp-rest-proxy.
Request flow:
Fires in broswer, say localhost:8080/_api/web -> captured by webpack proxy middleware -> redirected to sp-rest-proxy by proxy middleware -> sp-rest-proxy directs to sharepoint -> and the whole process back to the browser
What I don't like in this process that there are too many links in a chain. I've tried to shorten it by removing sp-rest-proxy and sending request directly to sharepoint from webpack proxy. It works fine, however there are a lot of issues applying it to popular libraries. For example angular-cli and creat-react-app don't expose webpack config by default. Only via eject command.
That's primary why my attempt failed.

However now I'm curious, why you have almost implemented real proxy instead of using something like http-proxy-middleware. It works perfectly fine.
Anyway it's time to sleep :)

from sp-rest-proxy.

As far as I can understand in your scenario there are actually two proxy servers.

Yes, they are.
One of them knows nothing about SharePoint just bypassing requests.
The second one knows everything about SharePoint and exposing it as an anonymous service for a developer.

These extra hops, while development, look nothing, IMO, over simplification and possible embodiment into any use case scenarios (React, Angular, dummy serve, etc.) without knowing these scenarios beforehand.

Only via eject command.

Yep, ejecting default tools is not sexy. ;)

However now I'm curious, why you have almost implemented real proxy instead of using something like http-proxy-middleware. It works perfectly fine.

Well... Good question!
sp-rest-proxy was created as a simple experiment over Friday night in one breath just on raw express and SP Auth/Request related libs. Showing that something similar should have been there in SPFx instead of artificial mockup data.
Just something dummy as forwarding GET and POST to /_api/* injecting auth headers.
Then some folks reported that they are using it in their flows. So some muscles were added to support documents upload, batch requests, JSOM, SOAP, some other situations with SharePoint.
Then some hidden features (no one I suppose is aware of) which I needed for some of my flows, like exposition SharePoint tenant sitting behind NAT via sockets to a public server (for a developer). O_o Sounds weird but tasty!

Anyway it's time to sleep :)

Anyway, it's time go office! =))

from sp-rest-proxy.