Skip to content
This repository has been archived by the owner on Dec 5, 2022. It is now read-only.
This repository has been archived by the owner on Dec 5, 2022. It is now read-only.

Rewrite fragment response to prefix resources #291

Open
kevinsimper opened this issue Feb 28, 2019 · 9 comments
Open

Rewrite fragment response to prefix resources #291

kevinsimper opened this issue Feb 28, 2019 · 9 comments

Comments

@kevinsimper
Copy link
Contributor

If you try to load a fragment where scripts and css are loaded with ./ or even /, the assets will not load since the ___domain where tailor is hosted on is often not the same as where the fragment is fetched from.

I then often help teams organize the app so it responds with the absolute path to the application.

Would it be an idea to parse the response and then prepend the hostname that it was requested from? Or would it make sense to add a variable to the document that contains the hostname where it was fetched from, so that the page can do TAILOR_[NAME OF FRAGMENT]_URL + '/main.js' in their script when they know they are being loaded through tailor?

Obviously it is best to change the fragment app to load with absolute urls because that ensures fewer bugs with potential ajax request that can't be rewritten, but I see this could help new teams adopt tailor as tailor can take a application without the owners have to update anything on their end.

Have others experienced this? What are your thoughts?

@vigneshshanmugam
Copy link
Collaborator

The reason why we did not allow configuring the host URL's in TAILOR level and instead letting the fragments send the absolute urls is because

  1. Tailor templates can be modified on the fly (dynamic without caching) and having a global variable would be a footgun
<fragment src="http://a.com"/>

// few seconds later
<fragment src="http://b.com"/>
  1. Fragments endpoint might be hitting more than 1 load balancer at a time (DNS based weighted traffic switching). Two/three versions of fragment endpoint might be undergoing A/B testing changes or new feature releases and having a variable based on fragments would break the page.

The best case solution is to load the assets through CDN with different hash. We used to follow this approach in Zalando and has never dealt with any issues.

<https://cdn.com/<team-name>/assets/<asset-name-with-hash>.js/css

@kevinsimper
Copy link
Contributor Author

kevinsimper commented Mar 4, 2019

I think it is valid reasons, and thanks for listing the specific reasons 👍

From my experience, simple apps don't use a cdn from the start as it is another step to do, so it adds more work to adopt Tailor if that is a requirement even for the most simple apps that is just

<h1>Hello World</h1>
<script src="./main.js"></script>

which I have seen. When they ask: "Can i use this with tailor?" then the answer is "no", but I really want to say "yes, you don't need to do more to use tailor".

Does it make sense?

I will make a POC to make that app work in Tailor out of the box extending with another npm module.

@vigneshshanmugam
Copy link
Collaborator

Yeah sounds good to me. Do you think we can work around the problems i stated above?

I will make a POC to make that app work in Tailor out of the box extending with another npm module.

Yeah sure, Please do share it.

@Shwetha8990
Copy link

Is there any update on this issue? My team is also trying to use Tailor and we are running into this issue where the assets are not getting loaded.

Wherever there is a request being made using relative paths in the fragment apps, the request goes to the tailor server. There is no way to tell which fragment is making this request.

Also, we want to make minimal changes to the fragment apps, hence if there is a way to handle this on the Tailor side, it will be amazing.

@kevinsimper
Copy link
Contributor Author

@Shwetha8990 No I haven't gotten to making the plugin. Thank you for chiming in and contributing to the issue, it is the same experience I had so great to hear from others 😄

@vigneshshanmugam
Copy link
Collaborator

Sorry for the misclick. Eventhough adding this feature would be an amazing addition to the core, I cannot think of an ideal solution that would solve the pain points which is stated above #291 (comment).

I am open to suggestions on how we can solve this problem.

@vigneshshanmugam
Copy link
Collaborator

@Shwetha8990 In your use case, which server would be hosting the static assets(JS/CSS)? If it's going to be the fragment server it can be solved easily with a bit of change in tailor

Two scenarios i can think of when it comes to relative urls

  • Fetching from the fragment server itself (can be easily solved)
  • Fetching the assets from some other endpoint (This might be a broken build setup like not configuring the CDN output path when bundling). Can still be solved by using some attributes on fragment tag. But I am kind of hesitant to keep adding more attributes to the fragment tag.

@Shwetha8990
Copy link

Shwetha8990 commented Jul 3, 2019

@vigneshshanmugam Thanks for your reply.

In my case the fragment servers are hosting the assets. My application set up is somewhat as follows:

Tailor root is running at - localhost:9090
Fragment 1: localhost: 5055
Fragment 2: localhost: 5056
Fragment 3: localhost: 5057

All three fragments are present in index.html. Each fragment is a standalone application, that has its own assets. So there is no common place where I can have all the assets together.

When a req is made for an image from Fragment 1, it goes to the tailor server at 9090.
<img src="./garfiled.jpg" />
I would like this to be handled by the fragment server itself. Here there is no way to know if this req was made from Framgment 1, 2 or 3.

@iamsuneeth
Copy link

@vigneshshanmugam
Regarding your comment above if the static assets are loaded from fragment server itself,

Fetching from the fragment server itself (can be easily solved

Could you provide a small example how to achieve this ?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants