Kudos for how much polish and documentation work you've done here. It's rare to see a v0.1 release that's this accessible to newcomers, even rarer to see it all from one person. You clearly care about developer experience and that makes the project much more inviting.

Thanks for the kind words, yoz. I think it's easier to write documentation when you're actively using + codeveloping solutions using the library as well. The README guides are as much for my future self as they are for anyone else. :) If you end up poking around with it, please shoot me a line for anything that can use some additional coverage.

Before I try a web framework, I want to know if there's an easy way to do authentication, authorization and multitenancy. Multitenancy may have multiple approaches but am talking about something as simple as row-based multitenancy to get things started. But I also understand this may be a lot for version 0.1. Either way, this is still fantastic work and thanks for sharing.

Authentication and authorization is pretty easy to implement with custom Dependencies. Multitenancy can be a layer on top of that depending on how you want to shard your DB tables / separate rows. If you're interested in poking around a little more with auth then this plugin can be a starting place: https://github.com/piercefreeman/mountaineer/tree/1d44cdf1c6...

(In an old commit and stripped out from the current codebase until it has better test coverage and the main codebase is stable)

I do agree it needs documentation. It is really difficult to tell what the overall capabilities of the framework are beyond being able to serve React. You can have multitenancy with just about any framework though by running instances on different ports behind a reverse proxy like nginx.

This is cool! It's weird that I, very recently, created a project based on FastAPI and had a strong desire for a React frontend as well, so I created a solution for it. My solution actually supports React SSR as well and this project has motivated me to publish my library. Thanks!

Care to share the link?

This looks interesting, but there's a lot of moving pieces (rust, python, typescript, react, v8).

Maybe remove the .DS_Store files from repo and update your gitignore globally to avoid this issue. Also, Pydantic has SecretStr that might be useful to use.

Thanks for the note! SecretStr is a good call as well. I'll switch to using that for the database layer. Also removed DS_Store in the latest PR (really thought I had ignored globally but they snuck in anyway).

Very interesting work! Thanks for sharing. How hard do you think it'd be to swap React for Svelte ? Not that I feel strong for one or the other but I'm the process of learning svelte and having a good backend strategy for svelte views would be cool.

This would be fun to wire up into django middleware for some quick VM binding for react frontends. Appreciate the approach, as other's have said kudos and keep up the good work! Any work in this space to help alleviate the boilerplate is great

Agreed. Would be very interested in the ability to do SSR on React components from Django, without proxying to Node to do so.

This looks interesting! I need to try this on the weekend :)

By the way, I have been able to integrate JavaScript and any backend language with a hybrid approach, which works really well for large-scale commercial projects.

In a hybrid application, we'll have all of the following types of pages:

-- Server-first Django/Laravel/Ruby pages with little-to-no JavaScript.

-- Client-first JavaScript pages with little-to-no Django/Laravel/Ruby.

More Details Here ... https://twitter.com/dvcoolarun/status/1753310384843337907

I'm very happy to see that this package makes use of pydantic. I have been a heavy user of Dash and there is a ton of room there for an improved dev experience via typed models/components/callbacks built on pydantic primitives.

Personally, I probably won't venture to use this as I don't really need the extra client-side flexibility that this provides, but it's an impressive project for an early stage release.

There have been several other web app packages highlighted here over the last week. It's great to see new work being done on open source hobby projects on the web app front for Python/react/rust.

I have a less elegant, but perhaps less "magic" setup here: https://github.com/nitro-bio/micro-app

Looove that approach! Other than the TODO example, is there a full project I can look at that's based on Mountaineer? If I choose to be an early adopter, what are the current gaps / shortcomings I need to look out for?

Seems interesting as current Python-based solutions don't have good support for Javascript. I see the support for the binding is from Python to JS but do you have any plans to support two-way binding work?

Hey buremba, can you share more about the use-case that you're thinking about? Like JS function calling within Python?

This is awesome, thank you for building this. I've been looking for something like this for a long time. Does it have any built-in authentication features?

i like the idea of tight integration between frontend and backend by abstracting out the api/data fetching/transformation which is a lot of busy work

Hi I am trying to learn react for integration with Django.

I keep starting to build tic tac to application and then just leave it there.

Any tips and or documents on how to properly learn react ?

I'd recommend that you start by learning React without Django.

You can make a little tic-tac-toe game that runs in your browser using just React -- no need for Django, provided you don't want to save the state of the game to a database or something.

If I wanted to start today, I'd make sure I had Node 20.x installed, and then run `npm create vite@latest`. I'd name my project `tictac`, then select both `React` and `TypeScript`. I'd follow the instructions I get and visit the running React app in my browser at http://localhost:5173/.

From there, you can edit `src/App.tsx`. Make a tiny change, save it, and your browser will update immediately. I'd probably build my whole tic tac toe game right there in that single file.

TypeScript is optional but it's useful to learn and won't add too much complexity for this particular project (you can mostly ignore it if you like).

Once you have some basic comfort with these tools, the next question will be: okay, how can you make the code you just wrote talk to a Django server? A simple answer might be: have your code call out to the Django server by making a fetch() call. You'll have to figure out where, exactly, fetch() calls belong in React-using code. And you’ll want to have your Django server return some JSON (from a view) that your javascript code does something with. For this to work on your development machine, you'll run both the Vite server and the Django server at the same time. (npm run dev; python manage.py runserver).

A really tiny Django view should do just fine to start -- your goal is just to make sure the data sent by the Django server is received by your javascript code. After that, you can start to get fancy. You do not need Django Rest Framework, Ninja, or any other extension to Django on day one -- plain old Django is quite capable of sending and receiving JSON data. (Someday later, you might consider one of those add-ons, but I'd stick with the basics first.)

My usual advice is to build a tool that you'd find useful. You can do the Todo app if you'd find it useful. To focus on react learning use a CSS library like react-bootstrap or material or something.

You'll want to use Django rest framework rather than straight Django, though. Have fun!

Django is better paired with something like HTMX.

What makes it better than the current existing solutions though? For someone who is just interested in rapid prototyping?

Brilliant project. I was looking for something like this for my projects - can’t wait to try it.

Does it support serverside rendering (SSR)?

Yes it does! SSR support out of the box (powered by V8). This was one element of the Rust layer that was really important to pin down early and start benchmarking for performance. It ended up in a pretty nice place for the time-being: exception logging within the console and development frontend, 10-20ms rendering on average.

Very nice. I would probably not try it, as it's FastAPI based, but more of these things need to spring up!

What's wrong with FastAPI?

My own preference, probably not similar to theirs but coming from Django, CherryPy and heck, I'll mention even ASP .NET Core, I prefer to design my websites in a more OOP way. The way CherryPy handles things is my favorite overall, if I could merge CherryPy and FastAPI I would.

Hey giancarlostoro, big fan of OOP as well. I structured Controllers to just be regular classes - so you should be able to write server code and routes very similar to CherryPy.

Beautiful, I'm definitely adding this one to my list of frameworks to check out. I currently do C# professionally so most of my Python projects are just side projects currently.

I don't really like the maintainer model. I'm more of a fan of Litestar, as they seem to have a similar product but more of a mature development model. I could be wrong.

I don't know if Litestar is doing particularly well there.

https://www.reddit.com/r/litestarapi/comments/16flco9/core_m...

Litestar seems to have a very active social outreach team while fastapi seems to have an active user base to me. It's strange to see how often it gets shilled for by its maintainers/fans in python threads to the point it makes me uncomfortable with the project.

open governance and trying to get users make you uncomfortable while not merging prs, bus factor 1 and starting 300 projects with the same basic model ("do things - now with pydantic!") make you happy? fastapi has early mover moat and was great 3 years ago. but it's time to move on, there has been innovation. search for projects mentioning ovines (can't shill!)

btw, to complete the astroturfing, falcon is still the sanest python web library by a longshot (constructing a controller using init and wiring it manually? heresy, must use some bullcrap fake DI system), but it's completely ignored by almost everyone (and maybe dead-ish).

I think this was a temporary drama as the names mentioned in that post are actively working on the project, so in any case ls is more open by design

I wonder what happened after. It looks like the commenter/creator moved on:

https://github.com/litestar-org/litestar/commits?author=Gold...

That's the sort of thing I mean: the project can continue without its creator. It's not fun that whatever happened happened, but it seems a more solid choice from the point of view of continuity. Flask also has a very solid model here with Pallets.

Does anybody know something similar in Golang?

and in Vue.js

interesting, def gonna try it out. thanks for sharing your work.

Seems very neat!

very cool

Removing ChatGPT and the rest of machine learning also? (Most of it based on Python)

If your Python is slow, you are probably doing it wrong.

I prefer fast prototyping over speed. Easier to fix the speed later, than never getting of ground with a “fast” language.

Python is great but typed python is awful. But getting type hints and type checking would be great. That and pythons package management chaos that is somehow even worse than npm are the main pain points imo.

I'm really confused, Python has type hints. It's had type hints for a while now? At least several years. As for package managers, I have run into woes with pip, but most of my gripes are when Debian or Ubuntu have their own versions of packages that are on pip. I rely on venv to save me there though. For the most part pip is fine, I'm not sure I've tried other package managers.

Edit:

Python 3.5 is where type hints were introduced, this was released in 2015, so nearly 9 years ago.

It's not that it doesn't have type hints, it's that they're really bad. Python decided to introduce the syntax for type hints before developing a type checker (which is still not officially supported). This means that the type system is filled with weird gaps that 3rd party typechecking libraries can't fix without breaking changes to the language itself.

For example, `TypedDict` didn't support optional keys until Python 3.11, and even then you have to use the clunky `NotRequired` type to pull it off. This is despite the fact that having optional kwargs has been a common pattern for decades.

The type system is also not particularly robust. You can't make a class similar to `dataclasses.dataclass` yourself and have it typecheck propertly, so libraries like Pydantic have to develop custom plugins for typecheckers like mypy to get themselves to work.

Ah I see, so you want it improved upon to better align with what has always been available to actually be represented by the option type system, I can agree with that.

I'll be honest, I have not used it extensively, I'm used to just doing Python the old way, maybe once its been fully refined and becomes the status quo I'll dive into it. Until then, if I want types I just use a typed language.

If you think typed Python is awful, try typed Ruby

I don't mind them existing but I do think typed languages are generally better. Also I'm personally not interested in raw speed, I care about having the programming language letting me know if statements in my code make no sense before running them.

Just a personal opinion though, I'm always glad when people create something new and useful to them.

Wat den eenen sin Uhl, is den annern sin Nachtigall.

Or in Hochdeutsch:

Was für den einen die Eule ist, ist für den anderen eine Nachtigall.

And maybe idiomatically in English:

One person's own is another person's nightingale. The owl is seen as bad luck while the nightingale as good luck.

A reference for anyone else needing some context: https://en.wikipedia.org/wiki/The_Owl_and_the_Nightingale

Owl* not own