neuland / micro-frontends

extending the microservice paradigms to web development
https://micro-frontends.org/
MIT License
4.57k stars 477 forks source link

Any plans on demo / template project? #4

Open AhtiAhde opened 6 years ago

AhtiAhde commented 6 years ago

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.

naltatis commented 6 years ago

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.

amazzoccone commented 6 years ago

@naltatis i have some doubts about this strategy for Micro frontends. How could be managed page transitions? Using a router in the front? Mosaic implements something similar. What are the differences? Thanks a lot!

naltatis commented 6 years ago

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.

amazzoccone commented 6 years ago

Thanks @naltatis ! 👍 UI Services have multiple Web Components and each one is responsable, is needed, of have their own State Management (Redux for example) and request API to get/post data?

Let's say the back system has an API Gateway built with GraphQL.. Some Web Components of a UI Service could use internally Apollo to simplify requests?

What do you think of StencilJS? If you like the idea, I could work to contribute with a 4 example that would have a more complete stack:

Thanks a lot!! 🙌

naltatis commented 6 years ago

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. Feel free to use the assets of the examples here. I could link or maybe integrate the example once it’s done.

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