Proste wytłumaczenie dlaczego powinno się używać bcrypt zamiast md5/sha1: http://codahale.com/how-to-safely-store-a-password/
Proste wytłumaczenie dlaczego powinno się używać PBKDF2/scrypt zamiast bcrypt: http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html
Odświeżę temat, gdyż ,mój dylemat dotyczy właśnie API. Chodzi mi jednak o najlepszy sposób na skalowalne API.
Z uwagi na to że Goliath jest nieblokowalnym serwerem jest on jedną z opcji jaką biorę pod uwagę, drugą opcją jest Celluloid (ostatnio dość popularny), ale tutaj nie znalazłem żadnego przykładu, który pokazywałby jak połączyć się z bazą danych lub jak wykorzystać jakiś ORM.
Drugą kwestią jest rodzaj bazy danych: SQL (np. PostgreSQL) czy NoSQL (np. Mongo). Z jednej strony PostgreSQL ma hstory, ale nie wiem czy biblioteki nieblokujące komunikujące się z bazą danych obsługują funkcjonalność hstory.
Pytanie jest bardziej ogólne i nie dotyczy jakiegoś konkretnego projektu, z góry ustalonym czasem na zrealizowanie.
Ad wybór bazy:
Zastanów się czy kiedykolwiek możesz potrzebować transakcji. Jeśli tak - nie chcesz MongoDB. A to jest NoSQL która teoretycznie najlepiej w swoim gronie wspiera atomowość i spójność danych (z użyciem optimistic locking, którego nigdy w mongo nie udało mi się zmusić do poprawnego działania).
To są zawsze najgorsze pytania bo dopiero mając cyferki możesz rozważać tradeoffy.
Ale generalnie łatwiej bazę znormalizowaną zdenormalizować (także: przejść z relacyjnej na dokumentową czy key-value) niż w drugą stronę, dlatego większość serwisów zaczyna jednak od bazy relacyjnej z pełnym dobrodziejstwem ACID.
OK, to jeden problem rozwiązany, w sumie to skłaniałem się ku bazie SQLowej.
Celluloid to trochę co innego, nie odpalisz na tym API. Co do goliatha, to nie używałem nigdy, ale ja bym raczej użył pumy jeżeli zależy Ci na mniejszym zużyciu pamięci niż przy unicornie czy passengerze.
Goliath to spoko opcja, pod warunkiem, że będziesz robił tylko io.
Celluloid ma swój webframework: lattice i server: reel. Ale nie wiem, czy dużo osób tego używa.
Mógłbyś doprecyzować to mniejsze zużycie pamięci? Bo jeśli używamy JRuby lub Rubinius, to puma jest teraz jedyną opcją (może jeszcze mongrel2?), ale jak to jest z clustered mode w pumie (który potrzebujemy w MRI)? Czy nie jest tak, że się odpalają po prostu kolejne instancje servera w każdym procesie (z informacji które kiedyś gdzieś widziałem i z kodu to wynika, ale…)? Bo jeśli tak, to wtedy chyba Unicorn wygrywa (procesy mają lepsze zarządzanie pamięcią).
Wątki są lżejsze niż fork lub odpalanie oddzielnych procesów, na http://puma.io jest porównanie z innymi serwerami
Ciężko na takie pytanie odpowiedzieć, wszystko zależy od konkretnej aplikacji. Clustered mode używa forka (czyli właściwie tak samo jak unicorn) i pewnie najlepiej jest ustawić ilość workerów odpowiadającą ilości core’ów. Plus jest taki, że każdy z workerów nadal używa wątków. Dlatego jeżeli robisz więcej I/O niż kodu rubiego, to może to być lepszym rozwiązaniem od unicorna. Najlepiej przetestowac różne rozwiązania i zobaczyć co działa najlepiej dla konkretnego przypadku.
Czytałem o reel ale nie znalazłem przykładów do komunikacji z bazą danych, a chciałbym coś nieblokującego.
Co rozumiesz przez nieblokującego? To zależy od bindingów (np. mysql vs mysql2), a nie od serwera.