Bun / Performance

[PasVegan]

Hi,
Bun 1.0 got out and I thought that you could use it to speed up a lot streamsync ?

video about bun 1.0
their website

[ramedina86]

Hi, I'm not too sure how Bun would apply to Streamsync as the latter doesn't use a server-side JavaScript runtime. The backend is Python, and all the ui/ TypeScript code is transpiled to JavaScript which runs in the browser. JavaScript is only used in the frontend. Unless you're talking about something different?

[PasVegan]

You could use it instead of npm as a package manager for example.
here you talk about npm:
https://www.streamsync.cloud/custom-components.html#developing-templates

You could replace npm by bun. Maybe there are other use case but I am a low level developer so I don't know a lot about the world of javascript :)

[PasVegan]

Also instead of FastAPI/Uvicorn you could use:

• socketify.py which is 1931,85% faster than uvicorn (wow)
• Falcon which is 431,39% faster than uvicorn
• Robyn which is 416,39% faster than uvicorn
• Granian which is 303,15% faster than uvicorn

I think that could skyrocket the performance.
link to benchmark

[mzy2240]

dont think you are going to have that many throughput in your spa

[SurajRaika]

shifting to Bun for Streamsync won't really have any significant impact, at least for the next year or so. Streamsync mainly using it for building purposes, and it won't affect end users in the slightest.

[ramedina86]

Hi, yes I second what @SurajRaika regarding Bun.

Regarding alternatives to FastAPI, this can potentially be very interesting. Streamsync isn't tightly coupled to FastAPI so it'd be relatively straightforward.

[PasVegan]

socketify.py is the best alternative I think, If you want I can help :) !
Also, Is it a choice to keep streamsync in pure python and not another language ? Because you could do some parts in a faster, more robust language.

[Xynonners]

I wonder why most of the python web frameworks seem to use FastAPI. Sanic or Litestar seem to be faster (and don't have a pydantic dependency)

[FabienArcellier]

You can propose a design to carry out the replacement and show the benefit at least on an application like hello. You can also offer benchmarks on other applications you design.

The complexity will be to ensure support for the patterns described in Custom server. The architecture chosen must support the composition of other ASGI applications.

The choice fell on Fastapi because it meets the requirements of WF and it is a mainstream technology. People know how to admin that, ecosystem is huge, compatibility with asgi standard is excellent and allow to combine applications, it's heavily battletested on many ecosystem (linux, windows, macos, ...)

[FabienArcellier]

last discussion on this topic on discord : https://discord.com/channels/1154359809454379088/1154359809454379091/threads/1156879523141386270

[Xynonners]

You can propose a design to carry out the replacement and show the benefit at least on an application like hello. You can also offer benchmarks on other applications you design.

The complexity will be to ensure support for the patterns described in Custom server. The architecture chosen must support the composition of other ASGI applications.

The choice fell on Fastapi because it meets the requirements of WF and it is a mainstream technology. People know how to admin that, ecosystem is huge, compatibility with asgi standard is excellent and allow to combine applications, it's heavily battletested on many ecosystem (linux, windows, macos, ...)

yeah, I assumed the benefits would be due to the ubiquitous nature of FastAPI