**Witam wszystkich ponownie
Więc tak mam już parę ofert i okazało ze to kosztuje wiedzę. Więc za łatwo to sobie wyobrażałem:) bo myslałem skoro appi to większość serwisu.
Oferty zaczynają sie od koło 10 tyś w górę. Techniki wykonania też są rożne. Trafiał sie nawet developer który twierdził że wykonał już taki projekt. Ale przestał odpisywać po nie mógł podać cenę tylko pisał taki czas i tyle godzin a jego stawka godzinowa to 50-65 zł. Prosiłem o cenę bo ja go plonować nie będę kiedy i ile ona pracuje a na gadziny nie chce to zlecać, Tak mu też napisałem i cisza od paru dni.
Teraz mam spory dylemat kogo tu wybrać ponieważ jest ryzyko że takie że nawet jak serwis zostanie wykonany to że nie będzie działał odpowiednio.
Przedstawię teraz wam sposoby wykonania dwóch rożnych osób bo każdy coś innego pisze:)**
Z doświadczenia wiem, że część wizualna Pana projektu jest najprostszą częścią do ogarnięcia. Ciekawie się robi po stronie backendu, głównie za sprawą importu.
Ja proponuję technologie:
- Ruby
- Elasticsearch
- PostgreSQL
- Redis
- React/Redux
I raczej nie szedłbym w stronę monolitycznej aplikacji opartej o jeden framework, a raczej mikroserwisów
Jak powiedziałem frontend to najmniejszy problem. Import - jak przechowywać, znormalizować, zautomatyzować ile się da to jest wyzwanie + panel adm. intuicyjny bez wodotrysków, ale pozwalający szybko, sprawnie i bezbłędnie zarządzać zaimportowanymi ofertami. Dla jednego programisty to jest praca na kilka miesięcy, ciężko to oszacować co do godziny bo póki co specyfikacja skupia się głównie na frontendzie. A to tylko czubek góry.
Nie ważne czy to Django czy Railsy czy inna technologia, utrzymanie serwera będzie kosztem. Zwykły hosting tutaj nie da rady. A czy to będzie chmura np. AWS czy Heroku czy serwer dedykowany to już rzecz wtórna.
Przede wszystkim rozdzielenie aplikacji na początek na 3 części:
- mechanizm importu (a to się akurat również świetnie nadaje na podział na osobne mechanizmy, przetwarzanie XML czy zaciąganie via API, download obrazków, normalizacja danych i kilka innych mechanizmów)
- panel adm.
- strona
Z pewnością wypadałoby również trackować przekliki.
Monolityczna aplikacja to strzał w stopę. Bardzo słabo skalowalna.
Jak ktoś powie, że wystarczy to zrobić i to będzie samo działać to kłamie i że nie będzie w późniejszym czasie potrzebny development, chociażby support.
Jak powiedziałem frontend to najmniejszy problem. Import - jak przechowywać, znormalizować, zautomatyzować ile się da to jest wyzwanie + panel adm. intuicyjny bez wodotrysków, ale pozwalający szybko, sprawnie i bezbłędnie zarządzać zaimportowanymi ofertami.
Nie ważne czy to Django czy Railsy czy inna technologia, utrzymanie serwera będzie kosztem. Zwykły hosting tutaj nie da rady. A czy to będzie chmura np. AWS czy Heroku czy serwer dedykowany to już rzecz wtórna.
Przede wszystkim rozdzielenie aplikacji na początek na 3 części:
- mechanizm importu (a to się akurat również świetnie nadaje na podział na osobne mechanizmy, przetwarzanie XML czy zaciąganie via API, download obrazków, normalizacja danych i kilka innych mechanizmów)
- panel adm.
- strona
Z pewnością wypadałoby również trackować przekliki.
Monolityczna aplikacja to strzał w stopę. Bardzo słabo skalowalna. W przypadku sukcesu idę o zakład, że pewne rzeczy byłyby przepisywane. Tylko, że wtedy moż
Odpowiedz drogiego developera:
Po kolei: Ruby, Elastic search, PostgreSQL, Redis I React. Tutaj wiele się nie różnimy - również używam Elastica oraz PostgreSQL i przykładowo angular, więc tutaj kwestia nie wiele do rozpisywania. Co do importu danych, nie jestem pewien z jakimi danymi pracował dotychczas, u nas były to XML'e z ponad 30 tysiącami produktów i nas system radzi sobie z tym bez większego zająknięcia. Hosting - kolejny raz, zależy. Od danych i wszystkiego, my używaliśmy bodajże VShosting.cz z bardzo dobrą infrastrukturą i znów, bez problemu dawaliśmy sobie radę z BARDZO dużym sklepem gdzie płacą około 200 euro rocznie. O ile dobrze pamiętam. Kolejna sprawa to dzieli to na trzy części, import, panel, strona. Importowanie big data czyli produktów nie stanowi problemu, tak jak wcześniej wspominałem, importu powyżej niejednokrotnie 30tys. produktów, panel administracyjny - do dostosowania i strona. Autor tamtej wiadomości widać że miał chyba jakieś problemy z zarządzaniem tak dużą ilością danych, no ale to jedynie może świadczyć o jego optymalizacji jedynie. Co do odniesienia "monolityczna aplikacja", nie wiem czy było to w kontekście naszego planu jak to stworzyć - jeśli tak: nasza aplikacja nie była by monolityczna, być może po prostu za słabo rozwineliśmy technicznie temat i autor nie mógł tego wywnioskować.
Więc taki skrót: użycie technologi podobne co chciał autor tamtego posta, ale doświadczenie wygląda że u nas wygrywa jeśli chodzi o zarządzanie taką ilością danych.
Co sądzicie o tych technikach? Czy da sie jakoś na umowie zabezpieczyć żeby nie było tak ze po wykonaniu serwisu będę płacił za naprawianie błędów? Support jest według was konieczny?