3 ms·

Has anyone tried to develop anything with MSFT's Fluid Framework [1], which is used to build Loop? I have not got a chance to check details. But it seems quite

by helixc 5y ago

Has anyone tried to develop anything with MSFT's Fluid Framework [1], which is used to build Loop? I have not got a chance to check details. But it seems quite nice. Any general remarks are welcome. Particularly, I'm interested in understanding customizability of Fluid components, integration with React, and any concerns about Azure service lock-in. [1] "The Fluid Framework is a library for building distributed, real-time collaborative web applications using JavaScript or TypeScript." https://github.com/microsoft/FluidFramework https://github.com/microsoft/FluidFramework

arendtio 5y ago
I just took a look at the FAQ: https://fluidframework.com/docs/faq/#can-the-fluid-framework-be-used-in-a-situation-without-access-to-the-internet https://fluidframework.com/docs/faq/#can-the-fluid-framework... I think you have to consider your use case. If you want to build pure online collaboration tool it is fine. But if you want to build something that supports offline collaboration it seems not to be ready yet: > Clients do have to be connected to the Fluid service. Fluid can tolerate brief network outages and continue operating but eventually the promise of being able to merge local changes weakens. We are investigating ways to improve this using other merging techniques designed to reason over large deltas but no final solution is in place today. However, what I do like about their approach that they support multiple modern front-end frameworks from React to Vue to Web Components.
bragh 5y ago
Usually projects like this are meant to be used together with Office 365 or for extending Microsoft ecosystem. Straight from the README, but maybe there are other limitations: "This project may contain Microsoft trademarks or logos for Microsoft projects, products, or services. Use of these trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship."
- vanattab 5y ago
  I don't get your point? Doesn't that just mean if you fork the project you can't imply that it is sponsored by Microsoft? I have seen similar clauses in most open-source projects. This seems even more generous in that they don't demand you remove all the trademarks and logos just that you can't use the logo in a way that implies endorsement.
  - bragh 5y ago
    I am not saying whether you should or should not use this product. My point is that before using such products, you need to read really carefully where and how you can use it this product because of the included resources or intended purpose for using this. It is not sufficient to only read the README file and decide based on that. The key part here is the second sentence "Use of these trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines.". But there can be other such limitations also, just hidden somewhere else.
- crandycodes 5y ago
  (Disclosure: Work at Microsoft, but I work in Azure and some open source stuff, not on or directly with Fluid/Office/etc.) That's just a trademark clause for Microsoft logos and brands. The Fluid Framework itself is MIT licensed [0] and doesn't require exposing any of those logos/brands when you use it, so the framework itself is fairly open for usage. I think the main thing that would slow down adoption for Fluid is that the only "production" backend is an Azure service, which isn't part of the open source Fluid Framework. Other open source backends[1] aren't recommended for productions. Until there are some open source ones, I'd assume adoption will be limited to folks in the Azure ecosystem. [0]: https://github.com/microsoft/FluidFramework/blob/main/LICENSE https://github.com/microsoft/FluidFramework/blob/main/LICENS... [1]: https://fluidframework.com/docs/deployment/service-options/ https://fluidframework.com/docs/deployment/service-options/
btown 5y ago
I haven't used it, only read through documentation, but IMO Fluid's problem is not so much lock-in as an embrace of old-school columnar storage and handle-based object manipulation. An experienced Windows developer or game dev might feel entirely at home with the tradeoffs/footguns implied by https://fluidframework.com/docs/build/dds/#picking-the-right-data-structure https://fluidframework.com/docs/build/dds/#picking-the-right... ... but show that to a junior React developer and they're likely to be fundamentally confused, or worse assume that the only code example shown is a valid code example. (People writing documentation: please do not make one of the most prominent code examples in your Getting Started an example of what not to do!). And on the handle front, https://fluidframework.com/docs/build/data-modeling/#using-handles-to-store-and-retrieve-shared-objects https://fluidframework.com/docs/build/data-modeling/#using-h... is similarly counterintuitive, to say the least. Comparatively, I'm much more excited about Automerge https://github.com/automerge/automerge https://github.com/automerge/automerge, which promises much friendlier developer ergonomics as simple as: doc1 = Automerge.change(doc1, 'Mark card as done', doc => { doc.cards[0].done = true }) Contributor Martin Kleppman (of Designing Data-Intensive Applications fame) has great overview slides here: https://martin.kleppmann.com/2021/06/04/craft-conf.html https://martin.kleppmann.com/2021/06/04/craft-conf.html . If anything, Automerge suffers from a "there's multiple ways to have a server backend, including P2P and centralized, and no one right way" anti-lockin problem, which is refreshing and also frustrating for people who just want to try something out. This is a solvable problem though!
- helixc 5y ago
  Thanks for introducing Automerge, and pointing out the pros/cons! Will dig deeper.

by helixc 5y ago

arendtio 5y ago

I just took a look at the FAQ: https://fluidframework.com/docs/faq/#can-the-fluid-framework-be-used-in-a-situation-without-access-to-the-internet https://fluidframework.com/docs/faq/#can-the-fluid-framework... I think you have to consider your use case. If you want to build pure online collaboration tool it is fine. But if you want to build something that supports offline collaboration it seems not to be ready yet: > Clients do have to be connected to the Fluid service. Fluid can tolerate brief network outages and continue operating but eventually the promise of being able to merge local changes weakens. We are investigating ways to improve this using other merging techniques designed to reason over large deltas but no final solution is in place today. However, what I do like about their approach that they support multiple modern front-end frameworks from React to Vue to Web Components.

bragh 5y ago

Usually projects like this are meant to be used together with Office 365 or for extending Microsoft ecosystem. Straight from the README, but maybe there are other limitations: "This project may contain Microsoft trademarks or logos for Microsoft projects, products, or services. Use of these trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship."

vanattab 5y ago
I don't get your point? Doesn't that just mean if you fork the project you can't imply that it is sponsored by Microsoft? I have seen similar clauses in most open-source projects. This seems even more generous in that they don't demand you remove all the trademarks and logos just that you can't use the logo in a way that implies endorsement.
- bragh 5y ago
  I am not saying whether you should or should not use this product. My point is that before using such products, you need to read really carefully where and how you can use it this product because of the included resources or intended purpose for using this. It is not sufficient to only read the README file and decide based on that. The key part here is the second sentence "Use of these trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines.". But there can be other such limitations also, just hidden somewhere else.
crandycodes 5y ago
(Disclosure: Work at Microsoft, but I work in Azure and some open source stuff, not on or directly with Fluid/Office/etc.) That's just a trademark clause for Microsoft logos and brands. The Fluid Framework itself is MIT licensed [0] and doesn't require exposing any of those logos/brands when you use it, so the framework itself is fairly open for usage. I think the main thing that would slow down adoption for Fluid is that the only "production" backend is an Azure service, which isn't part of the open source Fluid Framework. Other open source backends[1] aren't recommended for productions. Until there are some open source ones, I'd assume adoption will be limited to folks in the Azure ecosystem. [0]: https://github.com/microsoft/FluidFramework/blob/main/LICENSE https://github.com/microsoft/FluidFramework/blob/main/LICENS... [1]: https://fluidframework.com/docs/deployment/service-options/ https://fluidframework.com/docs/deployment/service-options/

btown 5y ago

I haven't used it, only read through documentation, but IMO Fluid's problem is not so much lock-in as an embrace of old-school columnar storage and handle-based object manipulation. An experienced Windows developer or game dev might feel entirely at home with the tradeoffs/footguns implied by https://fluidframework.com/docs/build/dds/#picking-the-right-data-structure https://fluidframework.com/docs/build/dds/#picking-the-right... ... but show that to a junior React developer and they're likely to be fundamentally confused, or worse assume that the only code example shown is a valid code example. (People writing documentation: please do not make one of the most prominent code examples in your Getting Started an example of what not to do!). And on the handle front, https://fluidframework.com/docs/build/data-modeling/#using-handles-to-store-and-retrieve-shared-objects https://fluidframework.com/docs/build/data-modeling/#using-h... is similarly counterintuitive, to say the least. Comparatively, I'm much more excited about Automerge https://github.com/automerge/automerge https://github.com/automerge/automerge, which promises much friendlier developer ergonomics as simple as: doc1 = Automerge.change(doc1, 'Mark card as done', doc => { doc.cards[0].done = true }) Contributor Martin Kleppman (of Designing Data-Intensive Applications fame) has great overview slides here: https://martin.kleppmann.com/2021/06/04/craft-conf.html https://martin.kleppmann.com/2021/06/04/craft-conf.html . If anything, Automerge suffers from a "there's multiple ways to have a server backend, including P2P and centralized, and no one right way" anti-lockin problem, which is refreshing and also frustrating for people who just want to try something out. This is a solvable problem though!

helixc 5y ago
Thanks for introducing Automerge, and pointing out the pros/cons! Will dig deeper.