Research the near-social-bridge approach

[ailisp]

Problem Currently, we are not able to use npm packages like css libraries and third party react compoents in near social viewer. The event handler also has some limitations that prevent us from implementing a better search bar experience, see problem 1 in this comment: https://github.com/near/neardevhub-widgets/pull/85#issuecomment-1501391631.

User Story As a developer, I want to use npm packages and reuse the react ecosystem's tooling.

Acceptance Criteria

• Research https://github.com/wpdas/near-social-bridge, which implements a mechanism to create normal ReactJS App and inject it in a controlled way into a Widget on Near Social.
• Experiment to ensure:
  • we can use npm packages, such as tailwindcss and nextjs
  • we can use the full apis of react-bootstrap-typeahead that was not available in near social widget. For example, feature in this comment blocked by this: https://github.com/near/neardevhub-widgets/issues/18#issuecomment-1510604454
  • above search bar problem can be solved by either use a form with submit button, or <input> with both onKeyDown and onChange event handlers
  • test whether we can access SocialDB / transaction committing functionality from inside near-social-bridge
• Also figure out an estimation of cost (performance, effort) to migrate entire neardevhub-widgets to a standard react app

If everything goes well, scope after this ticket:

• Re-architect the neardevhub-widgets to be standard react app, setup with standard tooling and common configuration
• Inject it to BOS, make sure everything still works
• Makes it run as a React App locally.
• improve the search bar typing experience.
• clean up and configure styles with proper css libraries and css files, adjust styles that more precisely follows the @Ori's design.
• Reuse the react-bootstrap-typeahead or some similar library to address https://github.com/near/neardevhub-widgets/issues/18#issuecomment-1510604454

[frol]

I just want to say that such an approach to components defeats the purpose of BOS as it would just store JS blobs that are not editable, but I see the benefits. I don't see an alternative solution to the limitations we face with BOS VM today.

[ori-near]

Hi @ailisp thanks so much for creating this. Can you please add a problem statement and acceptance criteria to this? What else do we need to move this from triage to the backlog?

[carina-akaia]

we can use npm packages, such as tailwindcss and nextjs

Speaking of nextjs, I would insist not to go with SSR solutions, since it almost kills decentralization; I think we should rather use PWA approach ( as much as it's possible ) along with Preact, and web4 as a hosting solution

[carina-akaia]

Summary for recent discussions within the DevHub team

Topic: using near-social-bridge as an application entry point and BOS functionalities provider, and web4 as the deployment solution

Pros

• This approach solves any issues caused by limitations of BOS component framework.
• It’s much easier to deploy and inspect feature previews.
• The opportunity to drastically improve DX.
• We’re not obliged to keep the whole codebase outside SocialDB, the proposed solution is actually flexible: it allows balancing between the two approaches depending on complexity of different parts of the system. Plus, near-social-bridge acts as a provider pattern, which means we can utilize any APIs available to BOS components.
• It’s possible to bring positive impact to BOS ecosystem, since we can standardize the resulting architecture over time.

Cons

• This approach makes it harder to discover and reuse parts of project codebase for less experienced in frontend development users, since it’s not enough to just press the “fork” button on gateway.

💡 Addressing security concerns:

near-social-vm was created as a sandbox solution with the goal to restrict the access to LocalStorage and Cookies. But most of the modern browsers already have the sandbox – it’s called WebAssembly. Moreover, WebAssembly allows using more than just one language and its VM unlocks near-native performance. It’s also worth noticing that WebAssembly is a widely acknowledged open standard curated by a huge community, with W3C in its core.

[carina-akaia]

Update: now the migration to this approach makes even more sense, as BOS moving towards embracing native JS, and we need to improve quality and Cycle Time metrics.

[elliotBraem]

@carina-akaia I support this idea of exploring near-social-bridge as we've talked about this in length, but I see it more as an application wrapper and should be coupled with near-social-vm being installed in the bridged application, in order to retain composability.

What specific features are you trying to achieve by using near-social-bridge? This is an important consideration, as well.

I would suggest refactoring DevHub into a more typical, native BOS application before embarking on this. I would not group the limitations of BOS with the difficulties of developing DevHub -- I think we can draw inspiration from other BOS applications for how to make the development experience easier. Then we can use the near social bridge to provide specific external libraries.

[carina-akaia]

@elliotBraem please read this document, it should make the topic more clear