JustAPI: Όταν το Framework Τρέχει σε Rust και ο Κώδικάς σου σε Python

Έχεις σκεφτεί ποτέ πόσο από τον χρόνο του server σου αφιερώνεται σε πράγματα που δεν έχουν σχέση με αυτό που γράφεις;

Πάρε για παράδειγμα ένα typical FastAPI project. Κάθε request περνάει από το Starlette, μετά από το uvicorn, κατευθείαν στο asyncio event loop. Πριν καν φτάσει στη λογική σου, έχει ήδη διασχίσει πολλαπλά Python boundaries, έχει κάνει serialization σε Python, και έχει περάσει από κώδικα που τρέχει ακριβώς ίδιος για κάθε request.

Τι θα γινόταν αν αυτό άλλαζε; Τι θα γινόταν αν το framework—το κομμάτι που κάνει την ίδια δουλειά για όλους—έτρεχε εξ ολοκλήρου σε Rust, και η Python έτρεχε μόνο εκεί που ο κώδικάς σου είναι πραγματικά μοναδικός;

Αυτή είναι η ιδέα πίσω από το JustAPI. Και μετά από αρκετή ώρα ενασχόλησης με το project, νομίζω αξίζει να δούμε όχι μόνο τι κάνει, αλλά γιατί οι αρχιτεκτονικές επιλογές έχουν σημασία.

Τα Νούμερα Που Πραγματικά Μετράνε

Ας μιλήσουμε για απόδοση—γιατί νούμερα χωρίς context είναι marketing, όχι engineering.

Το project έφτασε τα 766.000 requests ανά δευτερόλεπτο σε ένα απλό hello-world test. Ο router κάνει lookup σε περίπου 51 nanoseconds με 500 routes. Και η async throughput βελτιώθηκε κατά 14 φορές μετά τη μετάβαση σε multi-threaded Tokio.

Τι σημαίνουν αυτά για σένα; Αν τρέχεις API που επεξεργάζεται χιλιάδες requests το δευτερόλεπτο, οι βελτιώσεις πολλαπλασιάζονται. Lower latency σημαίνει οι χρήστες περιμένουν λιγότερο. Higher throughput σημαίνει οι servers σου αντέχουν περισσότερο.

Αλλά η πραγματική ιστορία δεν είναι τα νούμερα. Είναι αυτό που δεν χρειάζεται να διαχειριστείς.

Κανένα uvicorn. Κανένα Gunicorn. Κανένα ASGI middleware stack να κάνεις debug στις 3 το πρωί. Όλη η request pipeline ζει σε Rust, και ο Python κώδικάς σου είναι απλά... ο κώδικάς σου.

Η Αρχιτεκτονική: Python ως Exception, Όχι ως Rule

Η πορεία ενός request μοιάζει έτσι:

Kernel (epoll/io_uring) → Tokio connection manager → TLS μέσω rustls → HTTP parsing μέσω Hyper → Router (matchit radix trie) → Middleware chain → Python boundary μέσω PyO3 → Ο handler σου → Rust serializer → Response

Πρόσεξε πού μπαίνει η Python: μόνο στο σημείο που αρχίζει η λογική της εφαρμογής σου. Όλα τα υπόλοιπα—όλα όσα τρέχουν ίδια για κάθε request—είναι Rust.

Αυτό είναι μια σημαντική διάκριση. Ο developer του JustAPI έβαλε έναν απλό κανόνα κατά την ανάπτυξη: αν ένα feature μπορεί να υλοποιηθεί σε Rust, πρέπει να υλοποιηθεί σε Rust. Όχι "μπορεί να είναι πιο γρήγορο σε Rust"—μπορεί να υλοποιηθεί σε Rust. Η Python είναι για την "κόλλα" μεταξύ των Rust values και των handlers σου.

Είναι ένας constraint που διαμόρφωσε ολόκληρο το project και δημιούργησε κάτι πραγματικά διαφορετικό από άλλα Python frameworks που έχουν προσθέσει Rust κομμάτια εκ των υστέρων.

Τι Σημαίνει Αυτό για την Εμπειρία Προγραμματιστή

Εδώ νομίζω η προσέγγιση γίνεται ενδιαφέρουσα για startups και αναπτυσσόμενες ομάδες.

Παίρνεις ένα πλήρες API framework—HTTP/1.1 και HTTP/2, TLS, routing με parameters, JSON serialization, αυτόματη OpenAPI documentation—με 30 γραμμές κώδικα που μοιάζουν πραγματικά με Python:

from justapi import JustAPIApp

app = JustAPIApp()

@app.get("/")
def hello():
    return {"Hello": "World"}

app.run()

Αλλά κάτω από αυτή την οικεία επιφάνεια, τρέχει ένας Rust server που χειρίζεται TLS, διαχειρίζεται connections, και σειριοποιεί responses χωρίς ποτέ να περάσει σε Python. Η developer experience μένει Pythonic. Η runtime performance είναι Rust.

Για ομάδες που φτιάχνουν MVPs που μπορεί να χρειαστεί να κλιμακωθούν αργότερα, αυτό έχει σημασία. Γράφεις Python σήμερα. Παίρνεις Rust performance χωρίς να χρειάζεται να ξαναγράψεις τίποτα όταν θα χρειαστεί να διαχειριστείς περισσότερο load.

Το AI Factor: Ένας Μηχανικός Συνεργάτης, Όχι Αντικαταστάτης

Αυτό το project χτίστηκε με agentic AI ως ενεργό συμμέτοχο—όχι ως autocomplete, αλλά ως μηχανικός οδηγός που βοήθησε στο design της αρχιτεκτονικής, μετέτρεψε αποφάσεις σε κώδικα, βρήκε bugs, και έγραψε tests.

Αυτό αξίζει να το συζητήσουμε ειλικρινά, γιατί γίνεται όλο και πιο συνηθισμένο και σπάνια συζητιέται διαφανώς.

Ο developer περιγράφει το codebase σε τρία επίπεδα: κομμάτια που καταλαβαίνει πλήρως, κομμάτια που καταλαβαίνει αρκετά για να συντηρήσει, και κομμάτια που έγραψε το AI και ελέγχθηκαν αλλά δεν μπορεί να αναπαράγει από μνήμη. Είναι ειλικρινής ότι αυτό είναι μέρος του πώς υπάρχει το project.

Νομίζω αυτή είναι η σωστή προσέγγιση. Τα AI tools επιταχύνουν την ανάπτυξη σε complex projects, και το να το προσποιούμαστε δεν βοηθάει κανέναν. Το key είναι να καταλαβαίνεις τι ανήκει σε σένα versus τι έχεις αναθέσει—και να είσαι ειλικρινής για το ποιο είναι ποιο.

Το Πρακτικό Συμπέρασμα

Frameworks σαν το JustAPI αντιπροσωπεύουν μια στροφή στο πώς σκεφτόμαστε τον ρόλο της Python σε high-performance συστήματα. Η Python δεν πάει πουθενά για application logic—η αναγνωσιμότητα και το ecosystem της είναι πολύτιμα. Αλλά η υπόθεση ότι το framework πρέπει να τρέχει σε Python αμφισβητείται.

Είτε το JustAPI γίνει το επόμενο framework σου είτε παραμείνει ένα ενδιαφέρον experiment, η υποκείμενη ιδέα έχει αξία: κοίτα τι τρέχει το ίδιο σε κάθε request στο stack σου. Αυτό είναι πιθανότατα Rust territory. Τα κομμάτια που αλλάζουν; Κράτα τα σε όποια γλώσσα η ομάδα σου είναι πιο παραγωγική.

Η απόσταση μεταξύ "δουλεύει" και "δουλεύει καλά" συνεχώς μικραίνει. Οι χρήστες σου δεν θα προσέξουν την αρχιτεκτονική, αλλά θα προσέξουν τη latency.

Πού Βρίσκεται Τώρα

Το JustAPI είναι στην έκδοση 2.0.10 με documented features που περιλαμβάνουν WebSockets, SSE, background tasks, scheduler, database access μέσω SQLx, και operational tooling όπως OpenTelemetry και Prometheus metrics. Είναι διαθέσιμο στο PyPI με wheels για standard Linux, macOS, Windows, και το free-threaded CPython 3.14t build.

Τα νούμερα είναι στο repository. Τα tests περνάνε. Τα failures είναι documented. Αυτό είναι το είδος της μηχανικής διαφάνειας που πρέπει να ενθαρρύνουμε περισσότερο.

Αν φτιάχνεις Python APIs και η απόδοση έχει σημασία για σένα, αξίζει μια ματιά. Το μέλλον των Python web frameworks μπορεί να μην μοιάζει με αυτό που χρησιμοποιείς σήμερα.