asp.net core czy django w projekcie webapi

0

Witam,

Mamy do napisania webapi, będzie tam dużo operacji CRUD.
Projekt jest szacowany na około 250 manday i stoimy nad wyborem tych dwóch technologii (asp.net core vs. django), bo akurat te technologie znamy (ale nikt nie zna obu technologii jednocześnie).

Generalnie moje pytanie dotyczy tego co waszym zdaniem sprawi nam mniej kłopotów i w co lepiej brnąć.

3

Django jest dojrzałe i sprawdzone. ASP.NET Core to wciąż hipsterski PoC.

0

To co @somekind napisał plus... a czego się chcecie bardziej nauczyć/z czym popracować?
Albo - którą technologie znacie lepiej, jeśli w przyszłości pojawią się problemy/nowe wymagania, żeby sobie z nimi poradzić?

Rozumiem że wsio ryba jeśli chodzi o wymagania na czym to ma hulać skro bierzecie pod uwagę obie.

0

Generealnie, każdy z nas chętnie nauczy się czegoś nowego.

Lepiej w zespole znamy asp.net (ale to klasyczne windows only), ale bardzo nie chcemy hostować tego na IIS na windowsie, zamiast tego chcemy użyć dockera, więc w gre wchodzi tylko .net core.

Aplikacja wymaga użycia websockets - tutaj jest pierwszy problem .net core ma w planach wprowadzić SignalR dopiero w Q2 2017. Nic wprawdzie nie stoi na przeszkodzie, aby zrobić mikroserwis dla samych socketów np. właśnie w django albo node.js ale zawsze jest to jakiś narzut.

Problem też wynika troche z tego, że mam ograniczone zaufanie do języków dynamicznie typowanych vide python, zastanawia mnie czy, jeśli projekt się bardzo rozrośnie to modyfikacja logiki biznesowej albo refaktoryzacja kodu nie będzie dla nas udręką.

0

Jak nie boisz się narzutów i zabawy niesprawdzoną technologią, do tego chcesz się pouczyć za kasę pracodawcy - idź w core.
Ja jestem .Netowcem ;-) i nie lubię dynamicznych języków. Lubię jak już przy kompilacji mam jakąś małą pewność że czegoś nie popsułem. Ale... statyczne typowanie to tylko pierwsza warstwa testów. Jeśli użyjesz dynamicznego języka i to ładnie otestujesz, to nie powinno mieć tak dużego znaczenia.

Moim zdaniem, django (ja go nie znam, ale skoro bierzesz pod uwagę to pewnie wiesz co mówisz) będzie lepsze, bo na dziś już widzisz, że masz braki w corze, a do tego nie jest to pewne, że SignalR tam dostaniesz w Q1.

Ale możesz też, jeśli czasowo was na to "stać" faktycznie pójść w mikroserwisy i część zrobić w django (nie tylko sockety) a część w .Net Corze. Jeśli coś się nie sprawdzi, to przepiszecie najwyżej. Każdy się czegoś nauczy.

0

Jak nie boisz się narzutów i zabawy niesprawdzoną technologią, do tego chcesz się pouczyć za kasę pracodawcy - idź w core.

No właśnie troche boję się, bo to jest zlecenie i ewentualne kary idą na mnie (niestety nie mam tutaj pracodawcy na którego moge koszty zwalic :P)

Więc chyba pójdziemy w django ewentualnie z mikroserwisami jakoś to wymieszamy

0

Uzywamy juz jakis czas .NET Core, moge tylko polecic. Duzy projekt, REST, microservisy (20+), statycznie typowane, bardzo szybkie. W ostatnim czasie calkiem ustabilizowane.

Na dokumentacje REST uzywamy Swagger a autentyzacja IdentityServer3 (openid, bearer token, itd..).

0

hostujecie aplikacje na linuksie czy na windowsie ?

0

Ja też polecam Django, a która wersja Django, dlatego że od wersji 1.10 wprowadzili sporo fajnych ułatwień. Python jest czytelny i ma mało kodu, to się tak nie martw z tym typowaniem. Jest o wiele łatwiej wyłapywać błędy niż w PHP. A te wynalazki Microsoftu to takie trochę ograniczone jak dla mnie.

0
miba napisał(a):

hostujecie aplikacje na linuksie czy na windowsie ?

Tylko Linux. Kestrel jako web server.
Mamy debian packages i w post install script spuscimy servis.

Dzieki temu wystarczy napisac 'apt-get update' 'apt-get install mojaservisa' i mamy najnowiejsza wersje na produkcji.

0
Marfusios napisał(a):

Dzieki temu wystarczy napisac 'apt-get update' 'apt-get install mojaservisa' i mamy najnowiejsza wersje na produkcji.

I piszecie to na każdym środowisku, czy po prostu macie tylko produkcję?

0
somekind napisał(a):
Marfusios napisał(a):

Dzieki temu wystarczy napisac 'apt-get update' 'apt-get install mojaservisa' i mamy najnowiejsza wersje na produkcji.

I piszecie to na każdym środowisku, czy po prostu macie tylko produkcję?

Obecnie 4 srodowiska. Automatyzacje zapewnia puppet.
Ja jako developer tylko commit/push. CI/build server stworzy debian package, ktory przesle do naszego ropozytorium.
Puppet kazdych pare minut sprawdza wersje na poszczegolnych VM.

1 użytkowników online, w tym zalogowanych: 0, gości: 1