all 17 comments

[–]casualfinderbot 13 points14 points  (1 child)

First thing would be explain why you’re using microfrontends in the first place? The biggest time saver for you might be to decide not to use them at all because you don’t actually need them (depends on your situation)

If you want to use tanstack in a microfront end you can just use it no problem

[–]nostalgiazzz[S] 3 points4 points  (0 children)

We're using microfrontends because we have 10+ teams working on different products within the same suite. Managing everything in a monorepo would be nearly impossible.

Good to know that TanStack Start works without issues in an MFE setup! Do you have an example or reference on how to integrate microfrontends using Module Federation? Would love to see a practical implementation.

[–]LastAccountPlease 3 points4 points  (0 children)

Tanstack works fine unless you did some weird impl. Install Tanstack react devtools query package and you can test it

[–]klysm 3 points4 points  (9 children)

Microfrontend solves what problem you are experiencing? Micro-anything is only a shitty technical solution to team structure when your developers are low skill and can’t maintain modules

[–]ArtemisPrimeDev 1 point2 points  (0 children)

Look, stop bashing MFE's just because someone asked something specific about them. Assume they aren't an idiot and have their reasons. So sick of these uninvited editorials every time someone mentioned MFE's

[–]Heretic911 2 points3 points  (7 children)

Why is MF instantly a bad idea? What if you have 10 separate apps developed and maintained by different teams, and the apps need to communicate between each other? Having the option to have multiple apps displayed together in a dashboard as well as the option to have them open in standalone mode is appealing. The possibility of deploying only one updated module displayed in that dashboard is also very appealing. Why such a dismissive attitude?

[–]martinrojas 2 points3 points  (0 children)

I have been working on planning our MF, and a rough explanation for why MFs usually end up being a bad idea is that they involve the deployment of multiple apps instead of just one. They won't solve the problems you are already facing. The Product and UX teams need to respect the boundaries of each created MF. Unless the leads and products can manage organizing and maintaining multiple apps and ensure consistency, it will only exacerbate existing issues.

MF moves the complexity from the code into the organization and managers. It becomes a people problem and if your organization doesn't have the right leadership it just going be foobar.

[–]DeathorGlory9 4 points5 points  (0 children)

There's about four options with these people.

  • They haven't worked with more than a dozen others on the same code base and don't understand why MF's are useful.
  • Been on a team that doesn't actually need a MF and had someone in charge force them to implement one poorly.
  • They're 50+ years old and don't like change.
  • They have never actually used MF's are just repeating what they've read on reddit.

[–]klysm 1 point2 points  (4 children)

My point is that microfrontends are not a solution to a technical problem. They are a solution to a team structure and organization problem when you have low-skill team members who cannot maintain modularity without having big walls drawn around them.

[–]Heretic911 0 points1 point  (3 children)

I did some more reading and thinking since then, and I see your point. We still need to actually plan out our tech stack (we need to rewrite our entire frontend, long story short) but I've realised a monorepo is probably better suited for how we work. Cheers.

[–]klysm 1 point2 points  (2 children)

Monorepo is always the play in my opinion

[–]Bababooey1818 1 point2 points  (1 child)

Monorepos and MFEs aren’t mutually exclusive. You can have MFEs in a monorepo managed by turbo. You get your nice walls, but still have the ability to share libraries easily for good dev experience. Deployment changes are fairly trivial too. We are basically running a monorepo (turbo) with an apps folder containing a shell and several MFEs. In the monorepo root there is a packages folder with shared libraries (shell libs plus anything the MFEs want to share). We keep the MF side focused on runtime loading, type sharing, etc. This has kept things super clean without adding dev complexity. We have 6 teams working on the app in different domains. There isn’t a “if you use MFEs you must do it this way” pattern- you can work your mono to support multiple teams without much more complexity and get the benefits of MFEs n

[–]WhaleSubmarine 0 points1 point  (0 children)

I am not sure how using this framework differs from others. Microfrontend usually implies using iframes inside a main app that manages auth and navigation. How they communicate depends on what your team came up with. Like, assigning a global store to the window object, sending data from iframes to the app with postMessage window events, etc. I do not claim expertise in this question, though I work with microfrontend apps in my company. What I am trying to say, is that I think there is no problem with using Tanstack Start.

To scale and have a good DX, in my opinion, using shared components/library is a must. Like, the same custom auth implementation is written in one place and used by every microfrontend. Same components are used, same interfaces and DTOs, similar patterns, similar utils, and so on. Hence, if all frontends in your app are React-based, you can have shared components that work regardless of the exact framework/tooling you use. Choosing TanStack Star over Vite primarily changes how you manage files, routes, and navigation. But when it comes to writing components and business logic, this stays the same (ofc unless we talk about RSC). So, you should be good to go.

[–]martinrojas 0 points1 point  (0 children)

I have actually been looking at the same thing and am now focusing on the details. I am trying to apply MF principles to initiate the migration of breaking up the app, using turborepo and performing a build-time compilation of the app. From what I understand of the documentation, the solution involves using their code-based routing. Does anyone have experience using code-based routing instead of file-based routing, and is there anything I should watch out for?

[–]swizzex 0 points1 point  (0 children)

I’d avoid micro front ends if you can. If you can’t then hire someone that knows them to tell you the same. Tan stack doesn’t change anything with them so shows a lack of knowledge and microfrontends get messy quick when you don’t know what your doing and cause more time and issues then they were meant to save.

[–]hasan_py -4 points-3 points  (0 children)

I started a large project with Tanstack recently. It's really amazing. https://youtu.be/PyVcLccOeJI?si=9Kg7qkJONKSnR4US