Elixir Phoenix gebruiken in een commercieel SaaS-project

Linkly is geschreven in Elixir.

Ik wilde altijd al kennis opdoen van het Erlang-ecosysteem, en Elixir is een gemakkelijke weg.

Ik zal hier niet de voordelen van BEAM of Erlang direct behandelen, aangezien daarover elders is geschreven. In plaats daarvan zal ik me richten op de praktische kant van het gebruiken van Elixir Phoenix voor een echt project.

Ik ga ervan uit dat je weet wat Ruby on Rails is, aangezien Phoenix, het webframework van Elixir, sterk geïnspireerd is door Rails.

Schrijven in Elixir is een vreugdevolle ervaring.

Het volgt vergelijkbare paradigma's als Rails, inclusief MVC, en ziet er zelfs vergelijkbaar uit.

In tegenstelling tot Rails wordt de code gecompileerd voordat deze wordt uitgevoerd. Dit is een nuttige stap omdat het je in staat stelt fouten op te vangen die je anders misschien niet zou hebben opgemerkt.

Modellen in Phoenix zijn gegroepeerd in 'Contexts'. Dit is een extra abstractieniveau, bedoeld om duidelijke scheiding te creëren tussen onderdelen van applicaties, bijvoorbeeld Gebruikers en Producten. Elke context kan elk aantal modellen bevatten.

Er is veel ophef gemaakt over prestaties op andere blogs, dus ik zal hier de praktische kant behandelen.

Voor een volledig uitgerust webframework zijn de prestaties duidelijk veel sneller dan Rails, en het vereist aanzienlijk minder hardware om te draaien.

De tijd 'tot opstarten' van het uitvoeren van mix phx.server versus rails server is sneller. Zelfs bij het ontwikkelen op een laptop laden pagina's merkbaar sneller met Phoenix.

Oppervlakkig gezien lijkt er hier een verschil te zijn. Rails heeft vele duizenden gems versus de Hex-repository van Elixir.

Zoals het gebeurt, is bijna alles wat je daadwerkelijk zou gebruiken beschikbaar in het Elixir Hex-pakket systeem - JSON-parsers, HTTP-clients, tools voor het formatteren en parsen van Markdown - het is er allemaal, en de modulekwaliteit is uitstekend.

In Rails zijn er aanzienlijk meer gems, maar je zou ze nooit opnemen in een echt project, vanwege hun ononderhouden status of het risico dat gepaard gaat met het inbouwen van te veel externe afhankelijkheden in je applicatie.

Platforms zoals Stripe en Recurly onderhouden hun eigen Rails-gems voor interactie met hun API's. Dit kan handig zijn, en over het algemeen ontbreekt ondersteuning voor Elixir.

Ik ontdekte echter dat het heel gemakkelijk was om het Tesla-pakket van Elixir te gebruiken voor interactie met HTTP-eindpunten van services, en uiteindelijk gaf ik de voorkeur aan deze manier van werken, versus het gebruik van voorverpakte gems, omdat het lichter is en je in staat stelt te begrijpen wat er gebeurt.

Ecto is niet zo volledig uitgerust als ActiveRecord.

Dat is ook niet de bedoeling.

Ecto is een eenvoudige database-wrapper die database-queries naar Elixir-objecten vertaalt.

In het begin vond ik het frustrerend dat het niet precies werkte zoals ActiveRecord.

Echter, Ecto laat je op een zeer eenvoudige manier met de database communiceren, en maakt het programmeren van webapplicaties eigenlijk veel gemakkelijker.

Met ActiveRecord, zodra je complexe queries begint te bouwen, kost het langer om ActiveRecord uit te zoeken dan gewoon een query als SQL te schrijven.

Na beide te hebben gebruikt, is het mijn conclusie dat het gebruik van een lichtgewicht database-wrapper zoals Ecto gemakkelijker is dan het gebruik van een zware abstractie zoals ActiveRecord.

Het geeft je de veiligheid van het gebruik van een database-wrapper, zonder de hoofdpijn en het gewicht van een 'te slimme' abstractie.

Beide bevatten migratie- en rollback-functionaliteit.

De standaarddatabase voor Phoenix-projecten is Postgres.

Voor degenen die NoSQL-databases gebruiken, werkt Ecto met Mongo.

Nog beter, Ecto werkt met de NoSQL-functies van Postgres, waardoor je JSON kunt opslaan en bevragen zonder Mongo nodig te hebben.

Dit is een gebied waar Elixir Phoenix tekortschiet.

Rails heeft de Devise-module. Phoenix heeft Coherence, maar die wordt momenteel niet onderhouden.

Als je een basis gebruikersnaam en wachtwoord login wilt gebruiken, moet je elke stap daarvan bouwen. Dat omvat het hashen van wachtwoorden, logica voor wachtwoordherstel, 'onthoud-me' instellingen, enz.

Dit is vervelend en brengt aanzienlijke beveiligingsrisico's met zich mee.

Ik koos ervoor om Auth0 te gebruiken, wat prima werkte met Phoenix. Misschien is dit sowieso een betere oplossing, maar het zou fijn zijn geweest om een keuze te hebben gehad.

De belangrijkste host van Phoenix-apps is Gigalixir, een klein Amerikaans bedrijf gerund door Elixir-enthousiastelingen.

Gigalixir wordt gehost op Google Cloud, dus de onderliggende infrastructuur is solide.

Het buildpack van Gigalixir maakt deployment gemakkelijk en ondersteunt alle slimme deployment-strategieën van Elixir (distillery, mix).

Het is duurder dan 'doe-het-zelf', maar het grootste deel van de kosten zit in het hosten van de Postgres-database.

Elixir Phoenix is zo licht dat het kan draaien op kleine docker-pods en nog steeds een zeer gezond aantal verzoeken kan verwerken.

Ondanks de meerprijs is het absoluut de moeite waard om de hoofdpijn weg te nemen.

Ik wil er nog aan toevoegen dat hun klantenservice uitstekend is.

Er zijn aanzienlijk minder Elixir-programmeurs beschikbaar.

Elixir is een "taal voor programmeurs" - een taal waar mensen naartoe komen nadat ze iets anders hebben geleerd.

Dat gezegd hebbende, degenen die Elixir gebruiken zijn doorgaans betere programmeurs. Misschien is het de bewuste keuze om een betere taal te kiezen.

Het doet me denken aan de begindagen van Rails, waar het leek alsof alleen "rocksterren" het zouden gebruiken (versus PHP).

Elke goede Rails-programmeur zal geen problemen hebben met het oppakken van Elixir Phoenix, en zal binnen een paar dagen operationeel zijn.

Absoluut.

Ik heb met veel talen gewerkt, en Elixir is de gemakkelijkste en krachtigste waarmee ik heb gewerkt.

Ik kijk ernaar uit om Elixir te schrijven.