Using streamlit for an STT / TTS model demo?

[snakers41]

Hi!

We are building an STT/ TTS dataset and STT/ TTS models.
Now we have open-sourced around 5k hours of annotation, and we are planning to release further 15k hours.

At some point in time, we would really want to produce some high quality public demos showcasing our STT and TTS models and some cool features that require interactivity. All of this can be done in a web-framework, but none of us are web developers, and as usual I will have to suffer (or my demos will be of low quality, as it usually happens).

Any such demo would require:

• Showing audio clips
• Recording short audio clips / uploading files (I saw that you will soon publish an upload widget)
• Sending such clips to be recognized to a local STT service running on a separate machine
• Text inputs (already covered)
• Showing images / tables (already covered)

I just learned about Streamlit, read some docs, looked through the examples. It is awesome! Actually it would work well for dashboards as well.

I found some boilerplate for such a demo, but this would actually require fiddling with web-servers and probably JS, and of course as it goes - it will slow down the development.

So, without further ado, I read this issue (number of links for a new user is limited) because there is a default wav HTML5 player that is very easy to use. I also looked at the docs, and have not found any dedicated widgets to work with audio!

(i)

From the first glance, it seems that the following set of widgets to work with audio would be beneficial:

• an audio_player widget to show an audio (maybe just a quick and dirty html-in-markdown widget and that’s it?)
• an audio_recoder widget

Thanks for any pointers and advice.

• I understand the the first MVP may be just done using HTML + file_picker widget, but nevertheless maybe anyone has better ideas?
• Adding an external requests call to a local API to get the STT model output also would not be an issue (for security / latency reasons I would not like to call my model from within the streamlit app directly)?
• Maybe I should open a feature request?

(ii)

Also we use this awesome HTML player hack in our notebook (we just embed an HTML player in the HTML code of the table).
Maybe it is possible to do this in streamlit as well somehow?

Alex

[DaniCaminos]

Hi @snakers41and welcome to the forum ,

Your STT/TTS dataset and models look awesome and should run well with Streamlit !

• an audio_player widget to show an audio (maybe just a quick and dirty html-in-markdown widget and that’s it?)

This is already supported in Streamlit. See st.audio(data). To use it, just pass any URL or byte array as the data argumnet. And if you put this widget in a loop you’ll get a list of audio players.

• an audio_recoder widget
  (…)
  I understand the the first MVP may be just done using HTML + file_picker widget, but nevertheless maybe anyone has better ideas?

We don’t have an audio recorder today, but:

• As you mention, a file uploader would do the trick for now. We’re actually implementing st.file_uploader() at this very moment, and should release it really soon (weeks). Here is a link to the GitHub issue if you’d like to follow it (https://github.com/streamlit/streamlit/pull/488)

• We’re also planning on adding plugin support to Streamlit, so people can write their own widgets. See Issues · streamlit/streamlit · GitHub

• Adding an external requests call to a local API to get the STT model output also would not be an issue (for security / latency reasons I would not like to call my model from within the streamlit app directly)?

That should work!

Streamlit by itself shouldn’t be less secure than, say, Flask + React. If anything, we try to err on the side of less customizability in order to provide APIs that help you not shoot yourself in the foot.

• Maybe I should open a feature request?

I’ve opened one for the audio recorder here: Audio recorder · Issue #643 · streamlit/streamlit · GitHub

But if you have any more requests, feel free to create them on Github.

---

Hope this helps and encompasses the different functionalities you need. If not, feel free to reach back out, we’d love to keep the dialogue going.
Cheers

Dani Caminos

[snakers41]

Hi Dani, many thanks for your replies!
They are really helpful.

(i)

st.audio(data) .

Cool, I totally missed it, because it was located in the charts section.

(ii)

I’ve opened one for the audio recorder here: Audio recorder · Issue #643 · streamlit/streamlit · GitHub

I will reply within the new ticket - Audio recorder · Issue #643 · streamlit/streamlit · GitHub, I have some ideas on how to do this really easily =)

(iii)

As you mention, a file uploader would do the trick for now. We’re actually implementing st.file_uploader() at this very moment,

Well, actually when researching this topic I kind of found the alternative that has audio recorder now:

• Use viola instead of streamlit
• Just use ipywebrtc to record audio
• Then you can hack anything - you just need a web developer to customize the look, because stock look of notebooks can be poorly met by the general public
• … profit

This snippet actually can be polished and made to work with viola

from IPython.display import Audio
from ipywebrtc import CameraStream, AudioRecorder

# actually I found this hack in some js code
# just pass mime type =)
camera = CameraStream(constraints={'audio': True,
                                   'video': False},
                      mimeType='audio/wav')
recorder = AudioRecorder(stream=camera)

# turn the recorder on
# still a bit rusty on whether I need to show it 
# in a separate cell later to make it work
recorder.recording = True
# say something
# turn the recorder off
recorder.recording = False
recorder.save('test.wav')
# enjoy your wav (a typical user will be happy with compressed sound ofc)

(iv)
Also what are your thoughts on viola vs streamlit?

Them seem to fill the similar niche.

I am not a web programmer, but on the surface streamlit seems to have more polish / more secure and viola seems to have many more capabilities - because if I can fit it in HTML5 + notebook => then I can fit it into viola (probably).

(v)

Also I wonder if you are planning to support a multi-page applications (I guess by hacking this you could achieve a look of a multi-page react app), i.e. something like this:

Best,
Alex

[Adrien_Treuille]

@snakers41:

Thanks for all the thoughts and suggestions!

(ii) + (iii) Thanks for bringing ipywebrtc to our attention. That’s a great potential solution!

(iv) Voila is fantastic. I suggest you play with both and see which flow you prefer!

(v) A number of people have created multi-page applications in Streamlit (see @Marc’s awesome-streamlit for an example). Is that what you had in mind? If not, please feel free to submit a feature request.

More generally, we are designing some exciting which will integrate Streamlit and React more closely, and we’re excited to release those in the coming months.

Thank you for using Streamlit!

[snakers41]

@Adrien_Treuille

(ii) + (iii) Thanks for bringing ipywebrtc to our attention. That’s a great potential solution!

Happy to help.

In case by the time I will be actually building my app (~start of December maybe), this will not will have been implemented, can you probably point me to some class / commit / doc line, so that if I add ipywebrtc to streamlit, I can do it effectively and then maybe just submit a PR? Necessity is a great motivation, you know.

(v) A number of people have created multi-page applications in Streamlit (see @Marc’s awesome-streamlit for an example). Is that what you had in mind? If not, please feel free to submit a feature request.

I am speechless.
Wow this is just awesome! A great starter!
Tried to find similar beautiful stuff using viola, but did not find it yet.
This looks like a proper interactive web application with all the perks of streamlit.
Also what is remarkable - I was able to find what is related to what immediately (!).
Obviously you can build your styles with viola, but this awesome app is just perfect …
Too good to be true, the best thing I saw since notebooks (+ extensions) and pytorch!

(iv) Voila is fantastic. I suggest you play with both and see which flow you prefer!

To be honest, I kind of leaned towards viola at first (you can just inherit all notebook ecosystem).
But now since you shared this example, I believe that the more optimal path would be to add a recorder widget by hacking streamlit!

[Marc]

Hi @snakers41

I’m the developer of awesome-streamlit.org. So thanks for your feedback above

I’ve am experimenting with both Streamlit and Voila because I can just see the potential of lowering the friction for creating (analytics) apps in Python.

There are a few comparison apps in the Gallery at awesome-streamlit.org. And I’m also trying to do a more general comparison here https://github.com/MarcSkovMadsen/awesome-analytics-apps.

For me the differences are really about the detail. Currently the main points are

• A hello world example is much, much easier to create with Streamlit for somebody new to Python. It’s just one package to install and a simple .py file. So it’s much easier to teach inexperienced pythonistas/ data scientists how to create simple apps. There is a huge untapped potential there.
• Streamlit comes with a working layout/ style out of the box. Voila does not. This is really important for development speed. For this reason alone I prefer Streamlit. As soon as advanced HTML and CSS knowledge is required, then from my experience I end up using a lot of time there. And I should not.
• Streamlit starts up faster than Voila. Because Voila needs to start a new Kernel per user. I’m in doubt whether Voila can scale to many users because of this “one kernel per user”
• Both Streamlit and Voila can provide a develop and test in your editor and not notebook experiense. For Streamlit it’s out of the box. For Voila you can set it up like that by having a simple notebook where you import and run your app.py file.
• Voila has a huge unlocked potential wrt. widgets and layouts. Everything is there. And it’s fast and performent. But nobody has put it together yet. So it takes a lot of time to put together. And the api is cumbersome because it really developed from many different packages that have been added “on top” of exising functionality over a long period of time. And you have to really spend time on Google in order to put things together.
• With Voila you can develop really advanced stuff using callbacks and jslinks. And it’s really fast. Maybe because you only run small pieces of code for each “call”.
• Deployment of Streamlit is simpler because it does not have a lot of dependencies. As far as I understand nobody has really described how to deploy voila apps yet. And I have a feeling it includes setting up a jupyter hub server which seems complex to me.
• With Voila you can serve a folder of apps. With Streamlit you cannot serve a folder of apps directly. You can serve one app.py file and then you have to select the app from a st.selectbox or st.radiobutton that you provide.
• Voila is a part of the Jupyter ecosystem with many users and contributors. That could be a huge advantage.

If Streamlit could provide something similar to the the ipywidgets including Layout and extensions like the qgrid and with the ability to setup callbacks it could be a game changer for me.

If Voila could simplify the startup time, api, layout and deployment story then it would be a game changer for me.

And then theres also Bokeh, Panel, Dash, Flask and Django to consider depending on your use case.

But Streamlit is by far the easiest to get started with and the fastest to get production with. It’s a huge advantage.

If you (yes you ) believe I’m wrong, then maybe it’s because i’m wrong. Please challenge or enlighten me. Thanks.

[snakers41]

@Marc
Many thanks for the detailed analysis.

First of all a couple of words about our background - we do ML, we know a bit of python and math, I used to code a bit using php + ajax years ago (using pre-built js modules), but anything js and / or callback related is a major pain (doable, but veeeery slow). Probably, this is an archetypical description of an ML team.

They key pain for us as a team is that we do not really need a dedicated web-programmer (and if we buy work from a freelancer, I will have to support it), but our market puts glossy marketing above proper models and datasets, and if we go public with our demos, they have to be perfect. Whenever I tried building web apps from scratch the looked horrible (for some reason people also find stock jupyter look not very appealing).

So maybe you will find the below comments helpful

• A hello world example is much, much easier to create with Streamlit for somebody new to Python. It’s just one package to install and a simple .py file.
• Streamlit comes with a working layout/ style out of the box. Voila does not. This is really important for development speed. For this reason alone I prefer Streamlit. It speeds up my development time. But also means it’s so easy to onboard inexperienced pythonistas/ data scientists.
• Streamlit starts up faster than Voila. Because Voila needs to start a Kernel. I’m in doubt whether Voila can scale to many users because of this “one kernel per user”
• Deployment of Streamlit is simpler because it does not have a lot of dependencies. As far as I understand nobody has really described how to deploy voila apps yet. And I have a feeling it includes setting up a jupyter hub server which seems complex to me.

All of these are game-changers / deal breakers.
Obviously it is naive to try to bridge a “valley of death” gap with a dedicated web team from day one, but “one kernel per user” is really “expensive”.

Prior to learning about viola / streamlit I built a crude annotation app and deployed it for 30+ people using jupyter hub. It was not a rough experience, but all in all - the deployment took 2-3 days. So, this app eats at least 100-200 MB RAM per user, which is ludicrous.

In case of a web demo - probably it will mean that during more popular phases / PR moments - it will become a bottleneck. I am not talking about real high-load here, but not being able to serve a web app (not the STT model itself, but just a page) during peaks to say 50 people at the same time is a recipe for disaster.

• Both Streamlit and Voila can provide a develop and test in your editor and not notebook experiense. For Streamlit it’s out of the box. For Voila you can set it up like that by having a simple notebook where you import and run your app.py file.
• With Voila you can serve a folder of apps. With Streamlit you cannot serve a folder of apps directly. You can serve one app.py file and then you have to select the app from a st.selectbox or st.radiobutton that you provide.

Both things are good enough here

• Voila has a huge unlocked potential wrt. widgets and layout. Everything is there. And it’s fast and performent. But nobody has put it together yet. So it takes a lot of time to put together. And the api is cumbersome because it really developed from many different packages that have been added “on top” of exising functionality over a long period of time. And you have to really spend time on Google in order to put things together.
• Voila is a part of the Jupyter ecosystem with many users and contributors. That could be a huge advantage.

This point is very interesting.
But I would argue that in this case the streamlit approach probably would win, because such apps are built for end-users.

Notebooks are so popular because of flexibility and lack of bells and whistles when you do not need them. Obviously, inheriting from a large ecosystem is very tempting, but I guess not only we have limited resources.

In a similar fashion - I tried jypiter lab. It was good, but not good enough and it added some complexity to the really simple notebook approach. Still cannot switch because it lacks a collapsible-headings plugin.

• With Voila you can develop really advanced stuff using callbacks and jslinks. And it’s really fast. Maybe because you only run small pieces of code for each “call”.

For teams like us … callbacks and jslinks are black boxes =)

And then theres also Bokeh, Panel, Dash, Flask and Django to consider depending on your use case.

I suppose that Bokeh, Panel, Dash are more like dedicated BI applications (ofc you can use bokeh just as a cool plotting library). You really need them in enterprise (but people tend to buy Tableau anyway, lol) when you have a billion charts.
In a fast moving ML team setting, whenever I was asked to build a dashboard … I ended up using SQL + Excel (I know what you are thinking) just to avoid the setup cost.
But with Viola or Streamlit - just write a plain .py data extraction script (or I just store data alongside and update it daily) and build a nice chart as I usually do.

Flask and Django

To be honest I would argue that an ML team would need django only when building some middleware.

All in all, looking forward to cues from the streamlit team on where to start with webrtc.
I hope hacking one plugin in will be easier than customizing viola.

[Marc]

Hi @snakers41. Thanks for providing really good insights and perspectives.

[Adrien_Treuille]

Really fascinating conversation guys. It’s shaping our thinking about the future.

@Marc: We are actively thinking about layout primitives and are excited to share a proposal with the community. There are a number of other big initiatives, e.g. a plugin architecture, and so we also need to think about sequencing among these features. Your perspective is always helpful as we think about these issues!

@snakers41: We definitely encourage forking Streamlit and playing with new features, so excited to hear what you learn from ipywebrtc. We haven’t had time to think about what a process would look like to integrate a contribution of the magnitude. Therefore, please allow me to share some preliminary thoughts now, and please know that I’m open to other perspectives here…

1. The ability to record sound in Streamlit requires careful API consideration because Streamlit has a rather unique event model and we want to make sure all the ideas flow well together! Prior to our accepting any PRs into mainline Streamlit, we would want to make sure we’d had a full discussion about API options.
2. Streamlit and Jupyter have fundamentally distinct architectures. (We considered unifying them at one point, but realized that that would prevent us from doing a lot of the cool features we planned.) As such, it’s not clear that the ipywebrtc path is going to be optimal for Streamlit, or even possible at all. Just a heads-up.

That said, we absolutely encourage forking Streamlit and seeing what you can do! If nothing else this (very ambitious) experiment could teach us a lot about where Streamlit needs to go over the next year.

Please let us know how we can help!

Adrien

[snakers41]

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

[snakers41]

Links I could not post

[snakers41]

@Adrien_Treuille

We haven’t had time to think about what a process would look like to integrate a contribution of the magnitude

Oh, I see now why you say so. I should have read this before suggesting ipywebrtc . Sorry for wasting your time here.

As far as I can see from their code, ipywebrtc is mostly based heavily modified jupyter widgets. Your model is very different. So joining them would require basically going up the stack to the jupyter itself, which probably I am not qualified to do =(

Also I see that you use tornado (which is another black box for me) and probably I am jumping over my head again … but tornado has this (I cannot post links for some reason):

Maybe this is just another dumb idea, but just consider this:

• If you load a webrtc recorder in JS, like here for example (I cannot post links for some reason)
• JS does its job
• Your app deals only with an audio file that js saves to a local folder
• Timestamp + some uid can be used to distinguish between files for several users

I am not sure if what I am suggesting makes sense though. Someone did this with tornado (I cannot post links for some reason) + web rtc, but I cannot tell if it is legit.

[snakers41]

I also noticed that in the charts section of the docs you provide some wrappers around js libraries
Maybe for webrtc that would also work?

[snakers41]

@Marc

I think I found a bit half-assed solutions to the problems stated above.

Please refer to my post here.

TLDR - ipyvuetify + voila-vuetify - this allows you to have viola demos with Vue UI Library, all in 100% python.

Some kind people had this problem, and they just found ipyvuetify and showed how to use it.

In the end - we fiddled with streamlit and had problems customizing it.
Our demo in Viola + ipywebrtc + ipyvuetify looks a bit trashy but does the job done, but I guess a full-time web developer will fix this once we hire him.

[Marc]

Thanks for sharing. I’m also keeping an eye on Voila. But it has the downside that it starts a kernel per session. Taking time and resources. In an enterprise setting with 5-100 users that might not be a problem. And it really has momentum currently.

I’m also experimenting with Panel. See awesome-panel.org. One strength of Panel is that it supports a reactive programming model based on the Param library. I really like that.

But I think and hope streamlit will support better layout and an api that supports more interactivity soon.

[andfanilo]

Really glad that discussion popped out again, as I had missed it I think in October I was exactly wondering about replacing my FastAPI + Vuejs front with Voilà + ipyvuetify and only tested Streamlit in December for a quick visual prototype.

I guess a lot of people are struggling to compare all the solutions, especially between Voilà and Streamlit. I’m also trying to wrap my head around this and maybe do a meetup talk on this (in french unfortunately ^^).

There’s this “trend” on having a page comparing the solution to its competitors, I like the Vuejs one and I discovered yesterday that Panel has one too with Streamlit in it. I know Streamlit is still in its “infancy” and we have the chance to be able to request new awesome features like layout and plugin, but is a comparison page planned ? Should we create an issue for this and put all our thoughts in there ? I’m pretty sure @Marc has already got a lot on this to share

[Marc]

Hi @andfanilo

Great reply. One of things I have been aiming to was actually to understand and be able to compare all the Python frameworks for Analytics apps. See

Add comparison of frameworks for creating awesome analytics apps in Python

And awesome-Streamlit.org vs awesome-panel.org

I just have not had the bandwidth to learn more than Streamlit and Panel yet.

I can see that Streamlit is helping a lot of people to communicate their work as small apps. The problem currently is they get stuck at some point because they cannot do advanced layout or get custom events like click events back from the front end. The template of Streamlit just works, it’s definitely very easy to get started with and to build small applications in.

With a framework like Panel you can do all the things that you cannot do in Streamlit. The problem is that it takes time to learn and the user base seems smaller. On the other hand the development speed is really impressive. Furthermore they support and document a reactive api based on Param which is so nice. And they have a lot of really advanced use cases in the scientific community.

With voila my impression is that a lot is happening and a big strength is that it is part of the Jupyter ecosystem. But panel and voila are actually working together. So you can use panel in voila now and soon the other way around also. The downside to voila is that you instantiate a kernel per session making it useable mostly in enterprises and smaller settings. It’s also a strength because it makes it very fast and you can use kernels in any language.

Both panel and voila can be used in a jupyter notebook which is also a strength. And they can be deployed via jupyterhub.

Dash I’m not following because I don’t like the api and it’s been slow when I’ve tried it.

But in the end the choice may be determined by where you work and who you are working together with. Not so much the technology.

[Marc]

@andfanilo

I would actually like to learn about your experiences with fastapi and vue.

I’ve been using Django rest api + angular. Angular because its the approved front end framework at work and django because some of my collagues where already using it.

But I can just see it’s not the right thing. I cannot work together with analyst, traders, data engineers, data scientists. It’s too advanced and the time to market is too high. I actually don’t need a rest api because I only delivering apps to be consumed on large desktop screens.

I was thinking about replacing django with fast api because it might reduce some complexity.

[snakers41]

@Marc

But it has the downside that it starts a kernel per session. Taking time and resources. In an enterprise setting with 5-100 users that might not be a problem. And it really has momentum currently.

@Marc
About the kernel, even more annoying thing is that it looks like it re-runs all the cells each time.

Ofc, you can do all the necessary caching behind the scenes, but that also takes time and Running Cell 1 out of 10 is shown to the user (our STT is in Russian, but say something, it will print some funny garbage). Which is ok, but probably not ok, if you need 100% polished apps.

experiences with fastapi and vue. ’ve been using Django rest api + angular. Angular because its the approved front end framework at work and django because some of my collagues where already using it.
I was thinking about replacing django with fast api because it might reduce some complexity.

@Marc

FastAPI is really awesome. Please use it!
I built my API based on this and it is great!
Auto docs are amazing! Also FastAPI supports websockets, if you need it.

The only real downsides are:

• The docs and issues are bit murky about handling custom “global” objects (i.e. some small local DB, external DB connection, rabbit MQ connections). There is a on_start and on_shutdown events for global object, but that is it. You cannot really handle the scope otherwise (or I am just not familiar enough with starlette). Probably you just cannot share scope between workers / API methods and thats is (except for the globals);
• 95% of docs are built towards b2c usage, which is understandable. Also some best practices like Oauth there seem a bit bloated for my taste, but again - it is meant for b2c usage;
• Very little control over auto-docs. It’s ok because you have a custom markdown field, but for example you cannot have HTML anchors from your markdown;
• If you goal is performance - they have a lot of examples with some aio libraries e.g. for databases, but most likely you will need to learn asyncio and maybe even use a message broker like rabbitmq. But those cases ofc are not really covered by the docs;

I can see that Streamlit is helping a lot of people to communicate their work as small apps. The problem currently is they get stuck at some point because they cannot do advanced layout or get custom events like click events back from the front end. The template of Streamlit just works, it’s definitely very easy to get started with and to build small applications in.

For all people in the Web who will be reading this - note, that in general - if you just need 2-3 radio buttons and some standard stuff - you can use ANY of these frameworks.

In Viola and Streamlit at the moment you can get away with ZERO JS / HTML knowledge.

Also now it looks like they only path to work with audio recording is via viola widgets. Most likely audio recording will not be a major feature for any of these frameworks =(

they cannot do advanced layout or get custom events like click events back from the front end.

It looks like the proper way of doing this with viola … is building custom jupyter widgets. Which is cool, but a bit steep. The advantage is that - you will be able to … use these widgets in your notebooks and probably they will work well without funny stuff as happens usually with js apps.

Also some advanced guys ipyvuetify, but there is no clear way of passing actions back to the python kernel.

Anyway - I set a deadline for myself to build a demo in 1 day with viola, and it took 1 day, but there is no table widget - so I had to half-ass my way with it using HTML injections with vue.js table classes.

And they can be deployed via jupyterhub.

@Marc
Well, hub is required when 5-100 users run interactive kernels, i.e. they code.
You do need hub to deploy viola apps!

I have deployed my annotation app for 50 users using only 8GB RAM server (real RAM usage per kernel is around 100 - 200 MB, which sounds horrifying for web!) and I deployed my demo app by just running command like viola --port ....

Unless you are a b2c website with 1M MAU, you will be mostly fine with such RAM expenditure.

[andfanilo]

@Marc

@snakers41

FastAPI is really awesome. Please use it!

This

As background context, I’m mostly interested in quick AI web demonstrators for showing good looking data analytics to customers in a couple days on their datasets. We do Tableau Software here but sometimes I just want a quick, lightweight, dirty solution. So I’m in the domain of “Data guy that had to invest a lot of time in frontend dev, oh wow hello Bootstrap/TailwindCSS, hey why do I need that webpack for etc etc”.

For Django, I’m sure the ecosystem is gigantic but from the perspective of someone who never got inside it there’s too much to learn to get quick prototypes going (says the guy that tries to do FastAPI + Vuejs…).
I did some Flask, but I’m not a Flask guy, I’m sure you can do anything with the Flask ecosystem, but I don’t know, it felt too…low-level.

What got me into FastAPI instead of Flask is :

• Type declaration everywhere with Pydantic, giving data validation for even the most exotic nested request body and structuring body responses. You create a Pydantic class that is an argument of request/response functions, that you can share between multiple functions, that you can properly document with docstrings, appears in Swagger UI, manipulate in functions, and provides code completion in my IDE. I honestly feel like a productive Pythonista when I develop in FastAPI
• Audomatic docs ! In my experience data scientists are not well versed in API design and testing, so seeing that Swagger UI giving the ability to test curls on the fly and editing the code that automatically updates the docs has really improved their skills in this regard. And this well documented Swagger UI makes it easier for frontend devs to develop over it without having to peek in the Python code
• Special thanks to Background tasks that I use to run background computational tasks/model retraining and store results back to a database.
• We can use Starlette behind the scenes, which means putting a bet on Starlette’s future ecosystem to improve FastAPI.

Like Streamlit, FastAPI is still in its “early stages” so there’s a lot going on in the project, and to get most out of FastAPI you sometimes need to go deep into the source, or here the Starlette side.

@snakers41

There is a on_start and on_shutdown events for global object, but that is it. You cannot really handle the scope otherwise (or I am just not familiar enough with starlette ). Probably you just cannot share scope between workers / API methods and thats is (except for the globals);

• This hurts a little, because I didn’t feel at ease when I created a db connection to a test db in integration tests.
• Unfortunately it’s hard to track the progress of a background task, maybe I should have tried opening a websocket to poll with Starlette, but really did not invest much time in this…
• Still a bit shy on the security side but I guess it’s coming.

–

If you want to try, there’s a toy project FastAPI + Vue.js I did

In the end I think FastAPI is very productive to quickly build well structured APIs without having too look for other plugins, and that autodocs is a killer feature.

Now I’m looking for a way to inject custom web components in a Streamlit fork, or through Jupyterlab extensions with Phosphor widgets (I did ipywidgets but could not customize it enough) with the hope that Viola outputs them correctly. But I’m still a loooong way to go and sadly many other things to do …