0

I've seen this pattern pop up in a couple of different teams. They have a server with a REST API and a frontend web project.

What commonly happens is the frontend developer finds their requests are being blocked by CORS, and they create a REST API for the frontend that just passes requests through to the main backend. This API eventually catches some business logic and turns into its own server, handling half of the backend responsibility separate from the true backend server.

How can this pattern be prevented? It feels wrong to spread business logic across two API projects and to have to run two APIs to use the frontend. Is there a proper way to make a "set-and-forget" CORS proxy for the frontend, without creating a dumping ground?

  • 1
    None of those teams considered correctly configuring the backend? – jonrsharpe Feb 6 at 22:31
  • "They have a server with a REST API" <- Is "they" someone else? I would have thought there ought to be a separate rest service hosted specifically for developers. That service would need to allow CORS for the development machines. I hope you're not using a live service for development! – Dan Rayson Feb 6 at 22:31
  • 1
    @Dagrooms Having read it twice, it's clear it's someone in a team at your place, seems I jumped the gun. I would think that it's the person who designed the rest service's job to set up CORS to allow the domains that your front-end developers are using. Once it goes live, obviously swap around your CORS config to allow live front-end servers. I can't imagine there's a real requirement that there needs to be a proxy service specifically for CORS... – Dan Rayson Feb 6 at 22:39
  • 1
    enable-cors.org ...? – Dan Rayson Feb 6 at 22:44
  • 1
    @Dagrooms I would say so... I still can't quite believe that there's a need for a CORS proxy service... In my limited experience setting up CORS it's always been a simple server-client relationship. I think the answer to your question is simply "There shouldn't be a cors proxy service in the first place." I would consider chalking it up to the front-end developers not communicating well with the back-end teams? A simple "Can this developer have access to the service please?" would probably solve it? – Dan Rayson Feb 6 at 22:51
1

The only scenario where I can see that configuration is when main API is not published with a public subdomain, so you may mask it publishing an intermediate public “backend” to proxy requests to the API in the private network OR you have a front end-backend (Let’s say a CMS with a different ad-hoc front end in AngularJS, React or any other Client-Side technology ) that consume services from other API, so you have a mix of CMS functionalities and data coming from the other API, I have seen both cases.

Most CORS problems come from misunderstanding of this mechanism. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

If API is publicly exposed, then you just need to configure the Access-Control-Allow-Origin: For the calling subdomain (origin of request) so you only have to worry that nothing is changing headers when they’re sent.

Of course CORS serves for the purpose of safely sharing data between different servers, hosting different applications, as API may reject any request not coming from the subdomain specified at Access-Control-Allow-Origin:

Otherwise having two backends with different or complementary business logic may result on a disaster, as any change done to the front end may easily result in changing code in the two backends which makes it harder to maintain.

  • I misunderstood why the API was originally made, it was just a separate project. It wasn't made to get around CORS issues. And yes, it looks like it is entirely private. – Dagrooms Feb 25 at 19:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.