Inhaltsverzeichnis
- Die Grundidee hinter beiden Frameworks
- Setup-Vergleich: Der erste Eindruck zählt
- Model Schemas: Der größte Unterschied
- Endpoint-Definition: Subtile aber wichtige Unterschiede
- Middlewares und Lifecycles: Verschiedene Philosophien
- Automatische Dokumentationsgenerierung: Beide glänzen
- Nitpicks
- Fazit: Wann solltest du welches Framework wählen?
- Häufig gestellte Fragen (FAQs)
23.07.2025
Ein detaillierter Vergleich zweier moderner API-FrameworksDjango Ninja vs. FastAPI: Ein detaillierter Vergleich
FastAPI hat die Python-Webentwicklung revolutioniert – doch mit Django Ninja gibt es eine Alternative, die das Beste aus zwei Welten vereint.
Während FastAPI mit seiner modernen, asynchronen Architektur und maximaler Flexibilität punktet, bringt Django Ninja die elegante API-Syntax von FastAPI in das bewährte Django-Ökosystem. In diesem umfassenden Vergleich erfährst du nicht nur die technischen Unterschiede bei Setup, Schema-Definitionen und Middleware-Konzepten, sondern erhältst auch eine fundierte Entscheidungshilfe: Wann ist die radikale Freiheit von FastAPI der richtige Weg, und wann profitierst du mehr von Django Ninjas nahtloser Integration in die Django-Welt?
Django Ninja vs FastAPI: Ein detaillierter Vergleich zweier moderner Python Web-Frameworks
Wenn du moderne REST APIs in Python entwickeln möchtest, stößt du unweigerlich auf FastAPI - das Framework, das die Python-Web-Entwicklung in den letzten Jahren revolutioniert hat. Aber kennst du auch Django Ninja? Diese elegante Alternative bringt die Geschwindigkeit und Type-Safety von FastAPI in die Django-Welt. Lass uns gemeinsam erkunden, wie sich diese beiden Frameworks unterscheiden und wann du welches einsetzen solltest.
Die Grundidee hinter beiden Frameworks
Bevor wir in die technischen Details eintauchen, lasst mich kurz erklären, was beide Frameworks besonders macht. FastAPI ist ein eigenständiges, asynchrones Web-Framework, das von Grund auf für moderne API-Entwicklung konzipiert wurde. Django Ninja hingegen ist eine Erweiterung für Django, die es erlaubt, APIs mit einer FastAPI-ähnlichen Syntax zu schreiben, während du weiterhin das gesamte Django-Ökosystem nutzen kannst.
Setup-Vergleich: Der erste Eindruck zählt
FastAPI Setup
Bei FastAPI beginnst du praktisch bei null. Das hat Vor- und Nachteile. Der Vorteil ist die absolute Freiheit - du entscheidest über jeden Aspekt deiner Anwendung. Ein minimales FastAPI-Projekt sieht so aus:
# main.py
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
def read_root():
return {"Hello": "World"}
# Starten mit: fastapi dev main.py
Das war's! Mit nur wenigen Zeilen hast du eine funktionierende API. Aber sobald du Datenbanken, Authentifizierung oder andere Features brauchst, musst du alles selbst konfigurieren:
# Ein realistischeres FastAPI Setup
from fastapi import FastAPI
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker
import uvicorn
# Datenbank Setup
SQLALCHEMY_DATABASE_URL = "postgresql://user:password@localhost/dbname"
engine = create_engine(SQLALCHEMY_DATABASE_URL)
SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)
app = FastAPI(title="Meine API", version="1.0.0")
# Dependency für Datenbank-Sessions
def get_db():
db = SessionLocal()
try:
yield db
finally:
db.close()
Django Ninja Setup
Bei Django Ninja hast du bereits ein vollständiges Django-Projekt als Grundlage. Das bedeutet, dass Datenbank-Konfiguration, Migrationen, Admin-Interface und vieles mehr bereits vorhanden sind:
# Nach django-admin startproject und pip install django-ninja
# views.py
from ninja import NinjaAPI
api = NinjaAPI()
@api.get("/hello")
def hello(request):
return {"message": "Hello from Django Ninja"}
# urls.py
from django.urls import path
from my_app.views import api
urlpatterns = [
path("api/", api.urls),
]
Der große Unterschied? Mit Django Ninja bekommst du das Beste aus beiden Welten: Die intuitive API-Syntax von FastAPI und die bewährte Infrastruktur von Django. Du musst nicht bei null anfangen, sondern baust auf einem soliden Fundament auf.
Model Schemas: Der größte Unterschied
Hier wird es richtig interessant! Beide Frameworks nutzen Python Type Hints für die Validierung, aber die Implementierung unterscheidet sich fundamental.
FastAPI mit Pydantic
FastAPI setzt vollständig auf Pydantic für die Datenvalidierung. Pydantic-Modelle sind eigenständige Klassen, die deine Datenstrukturen definieren:
from pydantic import BaseModel, Field, validator
from datetime import datetime
class UserBase(BaseModel):
# es gibt auch eine E-Mail Klasse in Pydantic!
email: str = Field(..., description="Die E-Mail-Adresse des Benutzers")
username: str = Field(..., min_length=3, max_length=20)
@validator('email')
def email_must_be_valid(cls, v):
if '@' not in v:
raise ValueError('Keine gültige E-Mail-Adresse')
return v
class UserCreate(UserBase):
password: str = Field(..., min_length=8)
class UserResponse(UserBase):
id: int
created_at: datetime
is_active: bool = True
class Config:
# Erlaubt die Verwendung von ORM-Objekten
orm_mode = True
Die Stärke von Pydantic liegt in seiner Flexibilität und den umfangreichen Validierungsmöglichkeiten. Du kannst komplexe Validierungslogik implementieren, automatische Konvertierungen durchführen und sogar verschachtelte Modelle erstellen.
Django Ninja's Schema-System
Django Ninja bietet dir zwei Möglichkeiten: Du kannst entweder Pydantic verwenden oder Ninja's eigenes Schema-System. Das Schema-System von Ninja ist speziell für die Integration mit Django ORM optimiert:
from ninja import Schema, ModelSchema
from django.contrib.auth.models import User
from typing import Optional
# Option 1: Manuelles Schema
class UserSchema(Schema):
id: int
username: str
email: str
first_name: Optional[str] = None
last_name: Optional[str] = None
# Option 2: ModelSchema - Automatisch aus Django Model
class UserModelSchema(ModelSchema):
class Config:
model = User
model_fields = ['id', 'username', 'email', 'first_name', 'last_name']
# Option 3: Erweiterte ModelSchema mit zusätzlichen Feldern
class UserDetailSchema(ModelSchema):
full_name: str
post_count: int = 0
class Config:
model = User
model_fields = '__all__'
@staticmethod
def resolve_full_name(obj):
return f"{obj.first_name} {obj.last_name}"
Der entscheidende Vorteil von Django Ninja's Schema-System ist die nahtlose Integration mit Django Models. Du musst nicht ständig zwischen ORM-Objekten und Pydantic-Modellen konvertieren. Die ModelSchema
Klasse generiert automatisch Schemas basierend auf deinen Django Models, was Duplikation vermeidet.
Der tiefere Vergleich: Pydantic vs Ninja Schema
Lass uns die "philosophischen" Unterschiede verstehen:
Pydantic in FastAPI:
- Vollständig entkoppelt von der Datenbank
- Explizite Konvertierung zwischen ORM und Pydantic nötig
- Mehr Kontrolle, aber auch mehr Boilerplate
- Perfekt für komplexe Validierungen und Transformationen
# FastAPI mit SQLAlchemy
@app.post("/users/", response_model=UserResponse)
def create_user(user: UserCreate, db: Session = Depends(get_db)):
# Manuelle Konvertierung nötig
db_user = UserModel(
email=user.email,
username=user.username,
hashed_password=hash_password(user.password)
)
db.add(db_user)
db.commit()
db.refresh(db_user)
# Pydantic konvertiert automatisch dank orm_mode
return db_user
Ninja Schema:
- Eng mit Django ORM verzahnt
- Automatische Konvertierung zwischen Django Models und Schemas
- Weniger Code, aber auch weniger Flexibilität bei Bedarf
- Ideal für CRUD-Operationen mit Django Models
# Django Ninja
@api.post("/users/", response=UserModelSchema)
def create_user(request, user_data: UserCreateSchema):
# Direkte Arbeit mit Django ORM
user = User.objects.create_user(
username=user_data.username,
email=user_data.email,
password=user_data.password
)
# Automatische Konvertierung zum Response Schema
return user
Endpoint-Definition: Subtile aber wichtige Unterschiede
Auf den ersten Blick sehen die Endpoint-Definitionen sehr ähnlich aus, aber der Teufel steckt im Detail.
FastAPI Endpoints
from fastapi import FastAPI, Path, Query, Body, Header, Depends
from typing import Optional, List
app = FastAPI()
@app.get("/items/{item_id}")
async def read_item(
item_id: int = Path(..., title="Die ID des Items", ge=1),
q: Optional[str] = Query(None, max_length=50),
x_token: str = Header(...),
current_user: User = Depends(get_current_user)
):
# Async ist optional aber empfohlen
return {"item_id": item_id, "q": q}
@app.post("/items/")
async def create_item(
item: Item = Body(..., embed=True),
importance: int = Body(...)
):
return {"item": item, "importance": importance}
Django Ninja Endpoints
from ninja import Router, Path, Query, Body, Header
from django.shortcuts import get_object_or_404
router = Router()
@router.get("/items/{item_id}")
def read_item(
request, # Django Request Objekt ist immer der erste Parameter
item_id: int = Path(..., title="Die ID des Items", ge=1),
q: Optional[str] = Query(None, max_length=50),
x_token: str = Header(...)
):
# Nutze Django's ORM direkt
item = get_object_or_404(Item, id=item_id)
return {"item_id": item.id, "q": q}
@router.post("/items/", response=ItemSchema)
def create_item(request, item_data: ItemCreateSchema):
# Django's Authentifizierung ist direkt verfügbar
if not request.user.is_authenticated:
return 401, {"detail": "Not authenticated"}
item = Item.objects.create(**item_data.dict(), owner=request.user)
return item
Die wichtigsten Unterschiede:
- Request-Objekt: Django Ninja übergibt immer das Django Request-Objekt als ersten Parameter. Das gibt dir Zugriff auf Sessions, User-Objekt und andere Django-Features.
- Async-Support: FastAPI ist von Grund auf async, während Django Ninja primär synchron arbeitet (async Support ist experimentell).
- Response-Handling: Django Ninja erlaubt es dir, direkt Django Model-Instanzen zurückzugeben, während FastAPI explizite Konvertierung benötigt.
Middlewares und Lifecycles: Verschiedene Philosophien
FastAPI Middleware und Lifecycle
FastAPI bietet ein minimalistisches aber mächtiges Middleware-System:
from fastapi import FastAPI, Request
from fastapi.middleware.cors import CORSMiddleware
import time
app = FastAPI()
# CORS Middleware
app.add_middleware(
CORSMiddleware,
# ! ACHTUNG: never ever in Production !
allow_origins=["*"],
allow_methods=["*"],
allow_headers=["*"],
)
# Custom Middleware
@app.middleware("http")
async def add_process_time_header(request: Request, call_next):
start_time = time.time()
response = await call_next(request)
process_time = time.time() - start_time
response.headers["X-Process-Time"] = str(process_time)
return response
# Lifecycle Events
@app.on_event("startup")
async def startup_event():
# Initialisierung, z.B. Datenbankverbindung
print("Starting up...")
@app.on_event("shutdown")
async def shutdown_event():
# Aufräumen
print("Shutting down...")
Django Ninja Middleware
Django Ninja nutzt das bewährte Django Middleware-System:
# Django Middleware (in middleware.py)
class ProcessTimeMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
start_time = time.time()
response = self.get_response(request)
process_time = time.time() - start_time
response['X-Process-Time'] = str(process_time)
return response
# In settings.py
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'myapp.middleware.ProcessTimeMiddleware',
# ... andere Middlewares
]
# Django Ninja spezifische Features
from ninja import NinjaAPI
api = NinjaAPI()
# API-Level Middleware/Hooks
@api.exception_handler(ValidationError)
def validation_error_handler(request, exc):
return api.create_response(
request,
{"detail": exc.errors()},
status=422
)
Der Hauptunterschied liegt in der Philosophie: FastAPI gibt dir ein leeres Blatt und du baust deine Middleware-Pipeline selbst auf. Django hingegen kommt mit einer umfangreichen Middleware-Sammlung (Security, Session, CSRF, etc.), die du bei Django Ninja automatisch nutzen kannst.
Automatische Dokumentationsgenerierung: Beide glänzen
Sowohl FastAPI als auch Django Ninja generieren automatisch interaktive API-Dokumentation. Aber es gibt feine Unterschiede.
FastAPI Dokumentation
from fastapi import FastAPI
from pydantic import BaseModel, Field
app = FastAPI(
title="Meine tolle API",
description="Das ist eine ausführliche Beschreibung meiner API",
version="2.5.0",
terms_of_service="https://blueshoe.de/terms/",
contact={
"name": "API Support",
"email": "support@blueshoe.de"
}
)
class Item(BaseModel):
"""Ein Item in unserem System"""
name: str = Field(..., example="Beispiel Item", description="Der Name des Items")
price: float = Field(..., gt=0, example=29.99, description="Preis in EUR")
tax: Optional[float] = Field(None, example=2.5)
@app.post(
"/items/",
response_model=Item,
summary="Erstelle ein neues Item",
description="Erstelle ein neues Item mit allen Details",
response_description="Das erstellte Item",
tags=["items"]
)
async def create_item(item: Item):
"""
Erstelle ein Item mit allen Informationen:
- **name**: Eindeutiger Name des Items
- **price**: Preis muss größer als 0 sein
- **tax**: Optionale Steuerangabe
"""
# Tatsächlicher Code ....
return item
FastAPI generiert sowohl Swagger UI (unter /docs
) als auch ReDoc (unter /redoc
). Die Dokumentation ist hochgradig anpassbar und nutzt die Pydantic-Modelle für Beispiele.
Django Ninja Dokumentation
from ninja import NinjaAPI, Schema
from typing import Optional
api = NinjaAPI(
title="Django Ninja API",
version="1.0.0",
description="Meine Django-basierte API"
)
class ItemSchema(Schema):
"""Schema für Items"""
name: str = Field(..., example="Beispiel Item")
price: float = Field(..., gt=0, example=29.99)
tax: Optional[float] = None
class Config:
schema_extra = {
"example": {
"name": "Tolles Produkt",
"price": 49.99,
"tax": 3.5
}
}
@api.post(
"/items/",
response=ItemSchema,
summary="Erstelle ein neues Item",
tags=["items"],
operation_id="create_item"
)
def create_item(request, item: ItemSchema):
"""
Erstelle ein neues Item.
Diese Funktion speichert das Item in der Django-Datenbank.
"""
# Tatsächlicher Code ....
return item
Django Ninja generiert ebenfalls eine Swagger UI (standardmäßig unter /api/docs
). Ein Vorteil ist die Integration mit Django's Authentifizierung - die Dokumentation kann automatisch die verfügbaren Authentifizierungsmethoden anzeigen.
Nitpicks
Django Ninja hat kein Response Code "Enum"?!
Ein kleiner Nitpick den ich zum Schluss noch anbringen möchte ist, dass Django Ninja Standardmäßig kein(e) HTTP Response Enum / Klasse hat.
Klar die "ändern sich eh nie" - aber was war nochmal der Temporary Redirect Code? 301, nee 308 - weiß ich sicher!
Spaß bei Seite, Magic Numbers sind nie gut. Also muss man sich pro Projekt die Codes selbst in ein Enum schreiben. Geht und ist nicht schwer - nur nervig.
FastAPI bringt dafür das status Modul mit sich.
Fazit: Wann solltest du welches Framework wählen?
Nach diesem tiefen Einblick fragst du dich sicher: "Welches Framework ist das richtige für mich?" Die Antwort hängt von deinen Anforderungen ab.
Wähle FastAPI wenn:
- Du eine neue API von Grund auf entwickelst
- Maximale Performance und async-Support kritisch sind
- Du volle Kontrolle über jeden Aspekt deiner Anwendung willst
- Dein Team bereits Erfahrung mit modernen Python-Patterns hat
- Du primär APIs entwickelst (keine traditionellen Web-Views)
Wähle Django Ninja wenn:
- Du bereits ein Django-Projekt hast oder planst
- Du Django's Utilities (ORM, Admin, Auth, etc.) nutzen möchtest
- Dein Team Django-Erfahrung hat
- Du eine Mischung aus API und traditionellen Django-Views brauchst
- Schnelle Entwicklung wichtiger ist als maximale Performance
Beide Frameworks sind hervorragend und die Entscheidung ist keine Entweder-Oder-Frage. In der Praxis kannst du sogar beide in verschiedenen Projekten oder Microservices einsetzen. Das Wichtigste ist, dass du die Stärken und Schwächen verstehst und das richtige Werkzeug für deine spezifische Aufgabe wählst.
Die Entscheidung zwischen FastAPI und Django Ninja ist keine reine Technologiefrage – es geht darum, das richtige Werkzeug für deine spezifischen Anforderungen zu finden. Beide Frameworks ermöglichen es dir, moderne, performante APIs zu entwickeln, die den höchsten Standards entsprechen. Die Kunst liegt darin, die Stärken des gewählten Frameworks optimal zu nutzen und eine Architektur zu entwickeln, die nicht nur heute funktioniert, sondern auch morgen noch erweiterbar ist.
Stehst du vor der Entscheidung, welches Framework für dein nächstes Projekt das richtige ist? Oder planst du eine Migration deiner bestehenden API? Bei Blueshoe haben umfangreiche Erfahrung mit beiden Frameworks und unterstützen dich gerne dabei, die optimale Lösung für deine Anforderungen zu finden. Von der Architekturberatung über die Implementierung bis hin zur Performance-Optimierung – lass uns gemeinsam deine API-Vision Wirklichkeit werden lassen. Kontaktiere uns für ein unverbindliches Beratungsgespräch und profitiere von unserer Expertise in der modernen Python-Webentwicklung!
Häufig gestellte Fragen (FAQs)
1. Kann ich von FastAPI zu Django Ninja (oder umgekehrt) migrieren?
Die Migration ist definitiv möglich, aber der Aufwand hängt stark von deiner Codebasis ab. Von FastAPI zu Django Ninja ist oft einfacher, da du "nur" ein Django-Projekt drumherum bauen musst. Die API-Syntax ist so ähnlich, dass viele Endpoints mit minimalen Anpassungen übernommen werden können. Der größte Aufwand entsteht bei der Migration der Datenbank-Layer - von SQLAlchemy zu Django ORM.
Die umgekehrte Richtung (Django Ninja zu FastAPI) erfordert mehr Arbeit, da du die gesamte Django-Infrastruktur ersetzen musst. Du musst Authentifizierung, Datenbankzugriff, Middleware und andere Django-Features neu implementieren. Mein Tipp: Plane eine schrittweise Migration über mehrere Sprints und nutze die Übergangszeit, um beide APIs parallel zu betreiben.
2. Welches Framework ist schneller in der Performance?
FastAPI hat in reinen Benchmarks meist die Nase vorn, besonders bei asynchronen Operationen. Die Zahlen können beeindruckend sein - FastAPI kann teilweise doppelt so viele Requests pro Sekunde verarbeiten. Aber Vorsicht: Diese synthetischen Benchmarks spiegeln selten die Realität wider!
In der Praxis ist der Flaschenhals fast nie das Web-Framework selbst, sondern Datenbankzugriffe, externe API-Calls oder komplexe Business-Logik. Django Ninja's Performance ist für die allermeisten Anwendungen mehr als ausreichend. Wenn du wirklich jede Millisekunde brauchst, ist FastAPI mit async/await die bessere Wahl. Aber bedenke: Premature optimization is the root of all evil. Optimiere erst, wenn du echte Performance-Probleme identifiziert hast.
3. Wie sieht es mit Testing aus?
Beide Frameworks bieten exzellente Testing-Unterstützung, aber mit unterschiedlichen Ansätzen.
Bei FastAPI nutzt du typischerweise TestClient von Starlette:
from fastapi.testclient import TestClient
client = TestClient(app)
response = client.get("/items/1")
assert response.status_code == 200
Django Ninja profitiert vom ausgereiften Django-Test-Framework mit all seinen Features wie Fixtures, Transactional Tests und der Test-Datenbank. Du kannst sowohl Django's TestCase als auch Ninja's eigenen Test-Client verwenden. Der große Vorteil: Du kannst deine API-Tests nahtlos mit anderen Django-Tests kombinieren und hast Zugriff auf Dinge wie Factory Boy oder Model Mommy für Test-Daten.
4. Kann ich beide Frameworks im selben Projekt verwenden?
Technisch gesehen ja, aber ich rate davon ab! Du könntest theoretisch FastAPI für hochperformante Endpoints und Django (mit Ninja) für den Rest verwenden. In der Praxis führt das aber zu unnötiger Komplexität: zwei verschiedene Routing-Systeme, zwei Arten von Middlewares, potenzielle Konflikte bei Dependencies.
Eine bessere Strategie wäre eine Microservice-Architektur, wo verschiedene Services unterschiedliche Frameworks nutzen. Zum Beispiel: Django Ninja für deine Haupt-API mit Nutzerverwaltung und Business-Logik, FastAPI für einen spezialisierten Service, der Echtzeit-Datenverarbeitung macht.
5. Welches Framework hat die steilere Lernkurve?
Das hängt stark von deinem Hintergrund ab! Wenn du bereits Django kennst, wirst du dich bei Django Ninja sofort zuhause fühlen. Die API-Syntax ist intuitiv und du kannst dein Django-Wissen direkt anwenden.
FastAPI hat initial eine flachere Lernkurve, wenn du bei null startest. Die Konzepte sind modern und klar strukturiert. Aber sobald du über "Hello World" hinausgehst, musst du viele Entscheidungen treffen und Dinge selbst implementieren. Das kann überwältigend sein, wenn du nicht genau weißt, was du brauchst.
Mein Rat: Wenn du Python-Webentwicklung lernen willst, starte mit FastAPI für das Verständnis moderner API-Konzepte. Wenn du produktiv werden willst und bereits etwas Erfahrung hast, könnte Django Ninja der schnellere Weg sein.
6. Wie steht es um die Zukunftssicherheit beider Frameworks?
FastAPI hat enormen Momentum gewonnen und wird von einer sehr aktiven Community unterstützt. Große Unternehmen wie Microsoft, Netflix und Uber setzen es ein. Die Entwicklung ist sehr aktiv und das Framework wird ständig verbessert.
Django Ninja ist jünger und hat eine kleinere Community, profitiert aber von der Stabilität des Django-Ökosystems. Solange Django relevant bleibt (und dafür spricht alles), wird auch Django Ninja eine solide Wahl sein. Der Vorteil: Selbst wenn Django Ninja die Entwicklung einstellen würde, könntest du relativ einfach auf Django REST Framework oder pure Django-Views migrieren.
7. Gibt es Situationen, wo keines der beiden Frameworks passt?
Absolut! Wenn du eine GraphQL-API bauen willst, schau dir Strawberry oder Graphene an. Für WebSocket-heavy Anwendungen könnte Starlette oder Django Channels besser passen.
Für sehr einfache APIs oder Prototypen könnte auch Flask mit Flask-RESTX ausreichen. Und wenn du in der Data Science Welt unterwegs bist, könnte Streamlit oder Gradio für API-ähnliche Interfaces interessant sein. Das Schöne am Python-Ökosystem ist die Vielfalt - es gibt für jeden Use Case das passende Tool!
Was unsere Kunden über uns sagen
- Ofa Bamberg GmbHB2B Online-Shop | B2C Website | Hosting | Betreuung | Security© Ofa Bamberg GmbH
- Ludwig-Maximilians-Universität MünchenPlattformentwicklung | Hosting | Betreuung | APIs | Website
Blueshoe hat unsere Forschungsdatenplattform Munich Media Monitoring (M3) entwickelt und uns hervorragend dabei beraten. Das Team hat unsere Anforderungen genau verstanden und sich aktiv in die Ausgestaltung der Software und der Betriebsumgebung eingebracht. Wir sind froh, dass auch Wartung und weiterführender Support in Blueshoes Händen liegen.
- Deutsches MuseumDigitalisierung | Beratung | Datenbank-Optimierung | GraphQL | CMSFoto: Anne Göttlicher
Im Rahmen eines komplexen Digitalisierungsprojekts für unsere Exponate-Datenbank war Blueshoe ein äußerst verlässlicher Partner. Sie haben uns nicht nur während des gesamten Projekts hervorragend beraten, sondern unsere Anforderungen perfekt umgesetzt. Dank ihrer Arbeit ist unsere Datenbank nun ein bedeutender Mehrwert für die weltweite wissenschaftliche Forschung.
- Fonds Finanz Maklerservice GmbHPlattformentwicklung | Prozess-Systeme | Hosting | Betreuung | Zertifikate | Website© Fonds Finanz Maklerservice GmbH
Blueshoe ist unsere verlängerte Werkbank für Entwicklung, Wartung und Support unserer Weiterbildungs- und Zertifizierungsplattformen. Das Team hat sich gründlich in unsere Abläufe eingearbeitet, und wir freuen uns, Blueshoe als zuverlässigen Partner an unserer Seite zu haben.
- Technische Universität HamburgPlattformentwicklung | Beratung | Prozess-Systeme | Hosting | Website
Seit 2019 unterstützt uns die Blueshoe GmbH tatkräftig bei der Entwicklung und Weiterentwicklung des "Digital Learning Lab" und der "Digital Learning Tools". Dank ihrer Beratung konnten wir von Anfang an auf eine zukunftssichere, moderne technische Struktur setzen. Die Zusammenarbeit ist reibungslos, und wir fühlen uns rundum gut betreut. Und davon profitieren dann auch die Lehrkräfte in Hamburg.
Hast du noch Fragen oder eine Meinung? Mit deinem GitHub Account kannst Du es uns wissen lassen...