jupyter-book VS fastapi

Sphinx supports ReStructuredText and Markdown.

MyST-Markdown supports MathJaX and Sphinx roles and directives. https://myst-parser.readthedocs.io/en/latest/

jupyter-book supports ReStructuredText, Jupyter Notebooks, and MyST-Markdown documents:

You can build Sphinx and Jupyter-Book projects with the ReadTheDocs container, which already has LaTeX installed: https://github.com/executablebooks/jupyter-book/issues/991

myst-templates/plain_latex_book:

your task is very very broad

you mention you don't want to deal with AWS, if it's because of ad-hoc installation concerns and nothing else you can just run your notebooks in ready-made solutions like Google Colab, or Jupyter-book in Github ( https://github.com/executablebooks/jupyter-book ))

that would cover a lot of use cases right away without next to no learning curve

If you don't want to deal with AWS or similar, in that case:

- if it's a static notebook then you can obviously render it and serve the web content (might seem obvious but needs to be considered)

- if it's dynamic but has light hardware requirements, you can try jupyterlite which runs in the browser and should do a pyodine (webassembly CPython kernel) can do: https://jupyterlite.readthedocs.io/en/latest/try/lab/

- otherwise, you can try exposing a dockerised jupyter env ( as in https://github.com/MKAbuMattar/dockerized-jupyter-notebook/b... ) or even better a nixified one ( https://github.com/tweag/jupyenv )

there might be other approaches I'm missing, but I think that's pretty much it that doesn't entail some proprietary solution or an ad-hoc installation as you've been doing

Note: If you want to present a cleaner version of the notebook without assertions, you can use Jupyter book to render it into a site and use the remove-cell tag to omit assertions from the output.

See this thread for example.

And maybe take a look at executablebooks/jupyter-book.

Our team has transferred from Sphinx for documentation to JupyterBook. There have been some growing pains with it but I prefer the look of the output and being able to play with the examples on Colab or Binder at the click of a button is a great feature.

FastAPI is a modern, high-performance web framework for building APIs with Python, based on standard Python type hints.

In this tutorial, I will demonstrate how to use Burr, an open source framework (disclosure: I helped create it), using simple OpenAI client calls to GPT4, and FastAPI to create a custom email assistant agent. We’ll describe the challenge one faces and then how you can solve for them. For the application frontend we provide a reference implementation but won’t dive into details for it.

That’s when I found FastAPI.

FastAPI & Uvicorn

Discussion at FastAPI GitHub: https://github.com/tiangolo/fastapi/issues/2696

An API application framework (such as FastAPI)

It’s been my experience that async Python frameworks tend to turn IO bound problems into CPU bound problems with a high enough request rate, because due to their nature they act as unbounded queues.

This ends up made worse if you’re using sync routes.

If you’re constrained on a resource such as a database connection pool, your framework will continue to pull http requests off the wire that a sane client will cancel and retry due to timeouts because it takes too long to get a connection out of the pool. Since there isn’t a straightforward way to cancel the execution of a route handler in every Python http framework I’ve seen exhibit this problem, the problem quickly snowballs.

This is an issue with fastapi, too- https://github.com/tiangolo/fastapi/issues/5759

Fast API.

We will create our API using FastAPI, a modern high-performance web framework for building fast APIs with Python. It is designed to be easy to use, efficient, and highly scalable. Some key features of FastAPI include: