-
Notifications
You must be signed in to change notification settings - Fork 475
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Any plans on demo / template project? #4
Comments
Have you seen the product page example in the Repo? Up until now I only address integration on one page and data fetching/skeleton there. I’m planning to add more examples to show how page transitions (html app shell) could be implemented. This is the next topic I’ll address. After that I’ll go into performance topics, lazy loading, code splitting, bundling. And finally show a possible integration with a shared pattern library. I currently don’t intend to build a ready to use boilerplate, which is production ready. My main goal is to show one way how it can be done. I also haven’t decided yet if I want to add larger frameworks like Angular/react to the examples. I guess it might be helpful for some people, but for showing the mechanics I like sticking to simple plain JavaScript. Where are you giving the talk? Is it public? Like to see your take on this. |
Yes, if you want client side page transitions you would have to establish a shared top-level router. This could also be done in a way that works server-side. single-spa does a similar thing. They let the individual apps responde to url changes and let them take over control if they want to. |
Thanks @naltatis ! 👍 Let's say the back system has an API Gateway built with GraphQL.. What do you think of StencilJS?
Thanks a lot!! 🙌 |
Hi @amazzoccone, Yes I would give every fragment/component it’s own data fetching and state management and it’s totally fine if a team decides to use GraphQL internally. It would also be ok for a team to share state between multiple of its own fragments on the same page, but not across different teams. I really like the idea of stencil and played with their universal rendering feature a bit. I haven’t gotten the chance to use this in a bigger project yet. But it would be very cool if you could assemble an example with this. Same goes for universal routing. As I said, here I’m planning to build an example myself, but don’t let that block you. I don’t have a schedule for this yet. Thanks, naltatis |
Does anyone of us have ready made demo / template project about this?
It seems, that I am going to give a presentation about this architectural style and might want to create such project as a by product if one doesn't already exist. I do not consider myself as an expert on the topic (I prefer more Data Science and more back end stuff) so I would prefer using someone else's ideas / feedback on my thinking how this works.
So far, we are building something like this:
-We use LoopBack for MicroService backend.
-We use LoopBack Passport component for authentication.
-We use Nginx as a proxy, so that domain.com/api/ServiceA/ApiV/Resource.., domain.com/api/ServiceB/ApiV/Resource.. will match each LoopBack backend (this way we can later handle service registration and load balancing easily).
-(Each service has to have access to the authentication database, because LoopBack Passport works that way; I kind of don't like that, but it is how we do it now).
-We also use Nginx as a proxy for serving the front ends of each service like domain.com/web-component/ServiceA/component1.html, domain.com/web-component/ServiceA/component2.html, domain.com/web-component/ServiceB/component1.html etc.
-Then we have the main index.html, which has some ideas about the route, from which the "global single page app" -- which contains all the microfrontends -- was accessed. Then it uses SSI to load only what it needs, because the bundles can be quite big at times. It also loads the global dependencies and common dependencies, which are not component specific.
Would there be some aspects, which I have forgotten? Each component contains self contained assetts built by Webpack etc.
Simple TODO list with authentication might provide a nice demo application.
Thanks for this interesting idea.
The text was updated successfully, but these errors were encountered: