Smashing Podcast Folge 25 mit Anthony Campolo: Was ist RedwoodJS?

Wir sprechen von RedwoodJS. Was genau bedeutet es, ein Full-Stack-Jamstack-Framework zu sein? Ich habe mit Community Champion Anthony Campolo gesprochen, um das herauszufinden.

Notizen anzeigen

• RedwoodJS
• Anton auf Twitter
• Anthonys Artikelserie A First Look at RedwoodJS

Wöchentliches Update

• „Eine Einführung in die programmatische Ausführung von Lighthouse“
  geschrieben von Katy Bowman
• „Animation von Reaktionskomponenten mit GreenSock“
  geschrieben von Blessing Krofegha
• „Design für Aufmerksamkeit“
  Geschrieben von Victor Yocco
• „Erweiterte GraphQL-Nutzung auf Gatsby-Websites“
  geschrieben von Aleem Isiaka
• „Vergleich von Styling-Methoden in Next.js“
  geschrieben von Adebiyi Adedotun

Abschrift

Drew McLellan: Er ist ein Student der Lambda School, studiert Full-Stack-Webentwicklung und leistet Beiträge zu RedwoodJS. Er ist so etwas wie ein Community-Champion und hat kürzlich eine 12-teilige Artikelserie mit dem Titel A First Look at RedwoodJS geschrieben, die dabei hilft, die Ursprünge und Motivationen von Redwood zu erklären, zusammen mit vielen der verschiedenen Konzepte, die das Framework einführt. Wir wissen also, dass er ein Experte bei RedwoodJS ist, aber wussten Sie, dass er noch nie einen Hund gesehen hat? Meine großartigen Freunde, bitte heißt Anthony Campolo willkommen.

Drew: Hallo, Anthony. Wie geht es dir?

Anthony Campolo: Hallo. Ich bin umwerfend, vielen Dank, dass du mich hast.

Drew: Ich wollte heute mit Ihnen sprechen, und es ist wahrscheinlich aus der Einleitung ersichtlich, über RedwoodJS. Für diejenigen, die noch nie von RedwoodJS auf hohem Niveau gehört haben, was ist das?

Anthony: Ich denke, es gibt ein paar Möglichkeiten, wie man es beschreiben kann, je nachdem, woher die Leute kommen, aber die kanonische Definition ist, dass es sich um ein serverloses Full-Stack-Framework für Jamstack handelt. Es kombiniert also Full-Stack-Webentwicklung mit serverlosem AWS Lambda-Zeug und dem Jamstack, was heutzutage eine große Sache ist.

Drew: Es ist also ein Full-Stack-Framework, das versucht, viele Ideen rund um ein Jamstack-Entwicklungsökosystem zusammenzustellen? Ist das richtig?

Anthony: Ja, es verschiebt die Grenzen dessen, was eine Jamstack-Anwendung sein kann. Wenn wir es Full Stack, Jamstack, nennen, geht es darum, wie wir über das Frontend hinausgehen und dieselbe Art von Bereitstellungsparadigma haben, einfach gepusht werden, bekommen Ihr gesamter Code bereitgestellt. Wie bekommen wir das aber auch mit unserem Backend hin und haben das alles miteinander verbunden?

Drew: Nun, bevor wir uns zu tief damit befassen, finde ich es ziemlich interessant zu hören, dass es von einem ziemlich erfahrenen Team kommt, nicht wahr? Die Leute hinter Redwood sind keine Frühlingshühnchen. Um nicht zu sagen, dass sie alt sind, aber sie sind in Bezug auf die Webentwicklung um den Block herumgekommen, nicht wahr?

Anthony: Sie sind erfahren. Ja, ich habe tatsächlich viel Zeit darauf verwendet, über die Geschichte des Frameworks und die Ideen, die dazu geführt haben, zu schreiben, und Tom Preston-Werner ist der Schöpfer, und daher ist er auch als der Schöpfer von Jekyll bekannt, der ist ein wirklich einflussreicher Static-Site-Generator. Er hat auch TOML entwickelt, die Konfigurationsdateisprache. Und er war ursprünglich der CEO von GitHub. Seine Arbeit mit Jekyll- und GitHub-Seiten und dergleichen hat meiner Meinung nach wirklich zu dem geführt, was wir heute als Jamstack bezeichnen. Viele Leute würden sagen: „Oh, das Jamstack ist neu. Sie machen das schon ewig.“ So haben wir darüber gesprochen, wie es eine Erweiterung dieser älteren Ideen ist, der statischen Website-Generationen, aber mit GraphQL und serverlos und diesen Ideen, wie Sie Glue-Code und APIs verwenden können, damit Ihre App funktioniert.

Drew: Also, das ist definitiv von Leuten, die sehr in diese Gemeinschaft eingebettet sind? Ich meine, der CEO von GitHub, Sie werden wirklich nicht mehr in eine Art Open-Source-Community eingebettet. Redwood ist also ein Full-Stack-Framework, und ich denke, das bedeutet, dass Redwood-Code im Frontend und im Backend ausgeführt wird. Ist das richtig?

Anthony: Ja, das ist das erste, was ich den Leuten gerne erkläre, wenn ich ihnen ein Redwood-Projekt zeige, dass es ein Monorepo ist. Sie haben also Ihr Front-End und Ihr Back-End im selben Repo, und dann leben diese jeweils in ihren eigenen Ordnern. Sie haben einen Webordner, der Ihr Frontend ist, und er ist dem ziemlich ähnlich, was Sie von einer Create React-App erhalten würden. Dann haben Sie den API-Ordner, der Ihr Backend ist, und hier werden alle Ihre Funktionen im Wesentlichen in einen großen GraphQL-Handler geschoben, der über Netlify für AWS Lambda bereitgestellt wird.

Drew: Okay, also fangen wir vorne an, wie du schon erwähnt hast, es basiert auf React. Ist das React plus ein Haufen Redwood-Code, oder ist es einfach nur React? Wie ist da das Gleichgewicht?

Anthony: Es sind viele Dinge. Es ist definitiv nur React in dem Sinne, dass Sie nicht viele Zustandsverwaltungsbibliotheken einbringen, Sie bringen nicht einmal einen Router ein. Sie haben ihren eigenen Router, den sie geschrieben haben, und sie verwenden viel GraphQL-Zeug. Also, wenn Leute über React und GraphQL und Freunde sprechen, ist das ein bisschen was hier los ist, dass es Ihnen viele Standardintegrationen gibt, um React dazu zu bringen, mit Ihrem GraphQL zu sprechen. Weil wir jetzt viele Konventionen darüber haben, wie man React verwendet, aber das Abrufen von Daten ist immer noch ein großer Aufwand.

Drew: Es ist also React, das mit einer Reihe anderer Tools konfiguriert ist, die gut mit React zusammenarbeiten, um Ihnen ein funktionierendes Ökosystem für diese spezielle Art von Aufgabe zu bieten. Ist das eine faire Beschreibung?

Anthony: Ja, nein, ja, das ist eine großartige Art, es auszudrücken. Tom hat es so ausgedrückt, dass es all diese besten Lösungen gibt, die es gibt, und wirklich ausgefeilte Tools und Technologien, die wir verwenden können, aber es ist wirklich schwierig, sie tatsächlich zu nutzen, weil Sie so hohe Startkosten haben und sie lernen müssen , müssen herausfinden, wie man sie integriert. Also setzten sie den Slogan wie folgt: „Wir machen Ihre Webpack-Konfiguration für Sie.“

Drew: Ich denke, es ist ein häufiger Schmerzpunkt, den Sie von vielen Leuten hören, wenn sie versuchen, in das moderne Entwicklungsframework mit clientseitigen JavaScript-Apps einzusteigen und das Webpaket zu konfigurieren, all die verschiedenen Dinge zu konfigurieren, die Build-Prozesse, die Schritte bauen. Es kann ein ziemliches Minenfeld sein, nicht wahr, alles zusammenzubekommen und zum Laufen zu bringen? Und bis zu „Hello, World!“ ist es ein langer Weg. Redwood gibt uns also alles vorkonfiguriert?

Anthony: Ja, es ist sehr viel eine Konvention über die Idee des Konfigurationstyps, weil Sie … Tom war, als ob er GitHub mit Ruby on Rails und Rob, einem der anderen Hauptmitwirkenden, gebaut hätte, er war schon immer ein Rails-Entwickler. Sie haben viele Ideen, mit denen sie sich philosophisch in Bezug auf Rails ausrichten, aber sie wollen diese Konventionen über Konfigurationsideen, die Full-Stack-Framework-Ideen nehmen und das mit all der modernen Technologie, die wir jetzt haben, implementieren.

Drew: Sie haben also erwähnt, dass Redwood Ihnen einen Router oder einen Router gibt, wie wir auf dieser Seite des großen Teichs sagen, kommt er mit Dingen wie Standardkomponenten und all dem Zeug in React, oder sind Sie es nur das alles selber umsetzen?

Anthony: Ja, der Router ist sehr raffiniert. Es macht die meisten Dinge, die Sie nur vom React-Router bekommen würden, es hat nur andere Ideen, wie diese implementiert werden sollten, weil Next auch ihren eigenen Router hat, und es ist immer noch nicht wirklich ganz herausgefunden, wie wir es tun möchten, dass unser Single-Page-App-Routing funktioniert. Aufgrund von Suspense haben Sie viele dieser Art von Fragen, wo das asynchrone Zeug reinkommen wird? Wir haben mit Redwood diese Idee einer Zelle, und das ist es, was Ihre Daten wirklich für Sie abruft.

Drew: Also könnten wir vielleicht ein bisschen darauf eingehen? Was ist eine Zelle in Bezug auf Redwood?

Anthony: Ja, also ist eine Zelle eine Standardmethode, um eine GraphQL-Abfrage zu schreiben und Ihre Seite dann im Grunde zu sagen, ob Sie die Daten zurückbekommen, ob Sie einen Fehler zurückbekommen, ob Sie sich in einem Ladezustand befinden, oder ob… Da ist noch ein Staat, ich vergesse. Aber ja, es gibt Ihnen die verschiedenen Zustände, in denen Sie sich grundsätzlich befinden können, je nachdem, ob Sie Ihre Daten erhalten oder nicht. Es ist mit Apollo unter der Decke eingerichtet. Wenn Sie also Redwood verwenden, verwenden Sie Apollo als Ihren GraphQL-Client, aber Sie müssen nie darüber nachdenken. Sie müssen nie irgendein Apollo schreiben oder auch nur darüber nachdenken, es ist alles eingebaut. Es lässt Sie einfach GraphQL-Abfragen schreiben, was wirklich der Traum war, warum die Leute GraphQL wollten, weil es diese wirklich einfache Abfragesprache war, die Front-End-Entwickler könnte benutzen. Aber dann mussten Sie herausfinden, wie man einen GraphQL-Server einrichtet, Sie mussten all diese anderen Dinge herausfinden und wie Sie das alles verkabeln. Es übernimmt also die gesamte GraphQL-Integration für Sie, sodass Sie einfach GraphQL schreiben können und nicht darüber nachdenken müssen, wie ich GraphQL überhaupt implementiere.

Drew: Also, ich denke, eine der klassischen Aufgaben eines Frameworks besteht darin, den gesamten Standardcode, den Sie selbst schreiben könnten, für Sie zu implementieren und den Weg hinter die Kulissen zu räumen, damit Sie sich diesen Standardcode nie ansehen müssen immer wieder, und Sie können einfach den Code schreiben, der für Ihre Umstände einzigartig ist. Ich denke, das ist es, was mit einer Zelle los ist, oder? Hier gibt es nichts Revolutionäres, es ist etwas, dass Sie eine React-Komponente einrichten könnten, um all diese verschiedenen Zustände zu haben, und Sie könnten Apollo anschließen und all dies selbst tun, aber das ist eigentlich ziemlich viel Arbeit und es ist ein allgemeines Muster. Redwood hat also ein schönes, wiederverwendbares Muster aufgeräumt, das Sie einfach verwenden können, ohne darüber nachdenken zu müssen. Ist das eine gute Beschreibung?

Anthony: Ja, sie haben sich den Namen ausgedacht, aber sie räumen definitiv ein, dass sie diese Praxis häufig gesehen haben und dass sie viele Leute gesehen haben, die sie einfach selbst codiert haben, und sie entschieden, dass sie einen deklarativen Weg zum Abrufen Ihrer Daten wollten. Deshalb haben Sie dieses Setup, weil Sie damit einfach Ihre verschiedenen Zustände haben können und keine Wenn/Dann-Logik ausführen müssen, um dies herauszufinden, sondern dies tun müssen, wenn dies geschieht. Es geht also darum, nur eine einzige Möglichkeit zu haben, all die verschiedenen Zustände zu deklarieren, in denen sich Ihre Daten befinden könnten, während Sie sie laden.

Drew: Es ist eine der Eigenschaften von React, nicht wahr, dass React nicht versucht, Ihnen eine Architektur für Ihr Projekt zu geben, sondern Sie entscheiden lassen, wie Sie die Dinge strukturieren. Das hat natürlich Vor- und Nachteile. Aber es scheint, als ob Redwood Ihnen etwas von dieser Struktur auferlegt, damit Sie nicht darüber nachdenken müssen und damit es die Installation für Sie erledigen und sozusagen dort weitermachen kann, wo React in Bezug auf das Geben von Ihnen aufgehört hat so eine Struktur.

Anthony: Ja, und ich denke, es ist wirklich interessant, dass wir mehrere verschiedene Lösungsversuche für dieses Problem gesehen haben, denn ich meine, Sie hatten Leute, die es schon immer gesagt haben: „Warum gibt es kein Rails für JavaScript oder Rails for React?“ Es gibt ein großartiges Full Stack Radio-Interview zwischen Michael Chan und Adam Wathan mit dem Titel React is Not a Rails competitor. Dies ist eines der verschiedenen Frameworks.

Anthony: Die anderen sind BlitzJS, das ziemlich viel Aufsehen erregt hat, und dann ist Bison eine Art neuer Aufsteiger. Sie haben alle einen ähnlichen Stapel, aber sie verwenden unterschiedliche Teile. Sie haben eine React-Abfrage anstelle von Apollo oder Sie haben Chakra anstelle von Tailwind. Die Leute, die all diese Teile zu ihren Stapeln zusammenfügen, all diese Stapel sind irgendwie, sie kämpfen darum, es ist alles ein sehr freundschaftlicher Wettbewerb. Das ist eine Sache, die ich wirklich schätze, nämlich dass wir alle auch zwischen den Frameworks zusammenarbeiten. Da gibt es keine Feindseligkeit.

Drew: Also, wir haben Apollo und GraphQL erwähnt, Redwood verwendet GraphQL ziemlich stark als eines der Kernstücke des Frameworks, nicht wahr? Wir können wahrscheinlich eine ganze Podcast-Episode nur GraphQL widmen, aber für diejenigen, die sich nicht auskennen, was macht GraphQL hier, welches Problem löst es in diesem Zusammenhang?

Anthony: Ja, das ist eine großartige Frage. Wenn ich den Leuten erzähle, was sie wissen sollten, um einen guten Start mit Redwood zu haben, würde ich sagen, dass Sie die Create React-App hätten verwenden sollen, nur wenn Sie eine Create React-App erstellt und auf Netlify oder Netlify bereitgestellt haben Vercel, das wird dir einen guten Start verschaffen. Dann sollten Sie sich zumindest ein wenig mit GraphQL auskennen, da es sehr zentral ist. GraphQL ist also die Art und Weise, wie Ihr Frontend mit Ihrem Backend kommuniziert. Sie sagen, es sei eine Abfragesprache für APIs, die Idee ist, dass sie eine Alternative zu RESTful-API-Methoden sein soll, und dass Sie, anstatt dieses RESTful-Ding zu tun, Abfragen senden, die genau die hierarchische Datenstruktur angeben, von der Sie eine Antwort erhalten möchten die Datenbank. Es erfordert also etwas mehr Startzeit, um Ihren GraphQL-Server dazu zu bringen, mit den beiden Teilen zu kommunizieren. Sobald Sie sie dort haben, haben die Front-End-Entwickler die Möglichkeit, Daten auf viel flexiblere Weise zu erhalten. Sie brauchen nicht all diese verschiedenen API-Endpunkte, die Ihre Back-End-Mitarbeiter ständig erstellen müssen.

Drew: Also, wenn sich die Anforderungen im Frontend ändern, können Sie vermutlich einfach Ihre GraphQL-Abfrage optimieren und brauchen nicht die Hilfe von jemandem, der am Backend arbeitet, um diese Änderung für Sie vorzunehmen?

Anthony: Ich meine, der wahre Traum ist, dass Sie einen mobilen Client dazu werfen können, dass es letztendlich so flexibel wäre, dass es wird, dass Sie mehrere Clients haben können, die alle mit Ihrer einen API kommunizieren. Ihre GraphQL-API wird zu Ihrer Quelle der Wahrheit, dort ist Ihre gesamte Logik zentralisiert. Dann können Sie all diese verschiedenen Ansichtsebenen darauf aufbauen.

Drew: Wir haben also GraphQL, das uns die Möglichkeit gibt, eine Art Backend abzufragen. Was ist in Redwood das Backend?

Anton: Ja. Es gibt verschiedene Möglichkeiten, Ihr Backend zu erstellen. Auf diese Weise kommen Sie mit dem Tutorial aus der Box, indem Sie die Postgres-Datenbank verwenden, die auf Heroku bereitgestellt wird, super einfach, super einfach. Anschließend kommuniziert Ihre Redwood-App mit Prisma. Ich weiß nicht, ob Sie Prisma überhaupt kennen, aber es ist wie ein O/RM. Sie sagen ausdrücklich, dass es kein O / RM ist, sondern ein Abfragegenerator, der etwas niedriger ist. Aber um es den Leuten nur zu erklären, Prisma ist das Ding, mit dem Sie mit Ihrer Datenbank sprechen können. Es führt Ihre Migrationen durch und richtet Ihre Tabellen ein. Es erledigt all das SQL-Zeug, sodass Sie kein SQL schreiben müssen. Für mich klingt das nach O/RM. Sie müssen jedoch nicht unbedingt Prisma verwenden, um Redwood zu verwenden.

Anthony: Ich habe eigentlich nur eine Proof-of-Concept-App gebaut, bei der wir stattdessen FaunaDB verwendet haben. FaunaDB, sie haben ihre eigene GraphQL-API, sodass Sie die GraphQL-API einfach direkt an Fauna senden und dann Ihre Datenbankmutationen auf diese Weise vornehmen können. Sie verlieren viel von der Funktionalität von Prismas CLI, aber Prisma ist wirklich ein Komfortfaktor, um wirklich einfach mit Ihrer relationalen Datenbank zu arbeiten. Aber wirklich alles, was Ihnen einfällt, Sie könnten herausfinden, wie Sie es mit Redwood verbinden können, habe ich herausgefunden, nur weil es um GraphQL herum aufgebaut ist und der springende Punkt darin besteht, mit all diesen verschiedenen Teilen sprechen zu können.

Drew: Prisma ist also im Wesentlichen eine Art Abstraktionsschicht zwischen Ihrem Code und dem Datenspeicher, den Sie verwenden, vermutlich unterstützt Prisma das … oder macht es intelligentere Dinge als das?

Anthony: Ja, also schreibst du ein Schema, also erstellst du eine schema.Prisma-Datei, und sie hätte model post, und dann hätte sie id und integer und auto increment, wie title sting, body string, created at date, time . Sie würden also mit den Typen im Grunde das erstellen, was Sie in Ihrer Datenbank haben möchten, und dann erledigt es den Datenbankkram für Sie, sodass Sie nicht mit der Datenbank interagieren müssen.

Drew: Sie verwenden also Prisma, um zu definieren, welche Art von Datenbank oder welche Art von Datenspeicher Sie meinen. Dann legen Sie dort Ihre verschiedenen mvc-Modelle an, um diese Sprache zu verwenden. Wenn Ihre Anwendung also mit den Datenspeichern kommuniziert, verwendet sie gewissermaßen eine Instanz eines Prisma-Clients, oder? Ist das, was los ist?

Anton: Ja. Ja, genau das ist es. Im API-Ordner Ihres Backends haben Sie also einen lib-Ordner mit einer db.js, und standardmäßig ist darin Ihr Prisma-Client eingerichtet. Das ist also alles, was Sie aus der Box bekommen, und wie Sie sagten, kann Prisma mit verschiedenen Datenbanken arbeiten. Es kann zwischen SQLite für die Entwicklung und dann Postgres für die Produktion wechseln, so etwas. Im Moment sind es hauptsächlich relationale, aber die Roadmap enthält Dinge wie Mongo und Fauna.

Drew: Das ist also ziemlich nützlich, wenn Sie SQLite in Ihrer lokalen Entwicklungsumgebung einrichten und verwenden können, während Sie die Dinge zum Laufen bringen, und dann mit etwas wie MySQL in die Produktion gehen.

Anthony: Genau so ist das Tutorial aufgebaut, das ist der Arbeitsablauf, den es Ihnen zeigt.

Drew: Es ist ziemlich interessant, nicht wahr, einen sehr modernen Ansatz für ein Framework zu sehen, der dann auf einige dieser traditionelleren Datenbanken wie MySQL zurückgreift. Ich bin sehr vertraut mit MySQL. Ich liebe es wegen seiner Stabilität und ich liebe die relationale Art der Datenspeicherung. Ich denke, es funktioniert so gut für so viele Dinge. Bei den neueren Arten von Datenspeichern sieht man oft das Kind aus dem Wasser geworfen werden, also ist es ziemlich interessant zu sehen, dass Redwood diese guten, alten relationalen Datenbanken standardmäßig unterstützt.

Anthony: Ja, nein, das ist so ein guter Punkt, denn ich sage, dass es bei all den neuen Sachen, die Redwood miteinander kombiniert, einige Dinge gibt, die tatsächlich sagen, dass der alte, bewährte und wahre Weg tatsächlich der beste ist. Sie sind also wirklich groß in relationalen Datenbanken. Das kommt von Toms Erfahrung mit der Verwendung von Rails und einem relationalen Backend. Active Record war die O/RM-Schicht, die Prisma annähern wollte.

Drew: Ich schätze, wir sprechen hier mit Redwood über eine serverlose Architektur, und wir sprachen mit Chris Coyier, glaube ich, vor zwei oder drei Episoden, alles über serverlose Nutzung von APIs und Cloud-Funktionen und so weiter. Gehen Sie also einen Schritt zurück, wenn Sie an ein serverbasiertes Framework denken, wie wir Ruby on Rails oder so etwas wie Laravel in der PHP-Welt erwähnt haben. Selbst mit einem React-Frontend würde Ihre API-Anforderung Code ausführen, der Rails-Code oder Laravel-Code ist, plus Ihren Benutzercode und Ihre Konfiguration. Ist das bei Redwood auch so? Gibt es tatsächlich Redwood-Servercode, der ausgeführt wird, oder sind es nur mehr Tools und Strukturen und Kleber, mit denen Sie Ihren eigenen implementieren können?

Anthony: Ja, also im Backend gibt es eine Datei, die speziell eine Möglichkeit ist, Ihre SDL zu nehmen, also haben Sie Ihre Schema-Definitionssprache, und dann haben Sie, was Sie Ihre Dienste nennen, die wie Ihre Methoden sind, um mit Ihnen zu sprechen hinteres Ende. Dann wird all dies zu einem GraphQL-Handler zusammengefügt, der für eine einzelne Lambda-Funktion bereitgestellt wird. Es ist also speziell für Lambda optimiert. Wir haben erst kürzlich jemanden dazu gebracht, es mit dem serverlosen Framework zu tun, und wir haben einige Leute, die an Azure und Google Cloud arbeiten. Es ist nicht die Google Cloud-Funktion, sondern die darauf aufbauende. Aber ja, also ist es im Moment im Wesentlichen für die Bereitstellung Ihres Backends als GraphQL-Funktion in einem AWS Lambda optimiert. Das ist alles, was in dem Code passiert, den ich nicht verstehe, aber das ist die Erklärung auf hoher Ebene.

Drew: Es gibt also Bereitstellungstools, die den gesamten Code, den Sie geschrieben haben, zu einer Art magischem Codeball zusammenquetschen, der in der Cloud ausgeführt werden kann, und ihn auf AWS stellen, oder Sie müssen Sie diesen Prozess immer noch selbst verwalten?

Anthony: Ja, also wird alles über Netlify erledigt, wenn Sie dem Tutorial folgen. Sie müssen sich nicht wirklich selbst mit irgendwelchen serverlosen Funktionen herumschlagen. Das Zeug, das Ihr Backend zusammenschaltet, um es in AWS Lambda zu schieben, das ist alles erledigt, Sie müssen diesen Code nicht berühren. Das alles wird standardmäßig als Ihre Konventionen für Ihre Konfigurationen generiert, sodass Sie nicht wirklich zu viel darüber nachdenken müssen, wie Sie es serverlos machen können. Es ist standardmäßig serverlos. Es ist wirklich schwer, den Kopf zu wickeln. Es hat eine Weile gedauert, bis ich mich daran gewöhnt habe.

Drew: Ja, weil es ein wichtiger Punkt ist, nicht, weil es jetzt tatsächlich ein paar verschiedene Bereiche gibt, die wir hier im Auge behalten. Wir haben, glaube ich, drei verschiedene Bereiche. Wir haben unsere Front-End-React-App, die im Browser läuft, und dann haben wir eine GraphQL-basierte API, die als Cloud-Funktion läuft und auf unsere Abfragen antwortet, aber dann mit einem Datenspeicher interagiert die Prisma verwendet. Und dieser Datenspeicher ist was und wo darin, weil Sie keinen MySQL-Server auf Netlify betreiben können, oder?

Anthony: Ja, hier kommt Heroku ins Spiel. Also stellen Sie im allerletzten Teil des Tutorials Ihr Frontend auf Netlify und dann Ihr Backend auf Heroku Postgres bereit und Sie holen sich einfach Ihre Konfigurationsvariablen von Heroku und schließen es an in Netlify. Es ist wirklich sehr einfach, Ihr Netlify-Frontend dazu zu bringen, mit Ihrem Postgres-Backend zu kommunizieren. Sie wollten mit dem Ding fahren, das für jeden am einfachsten zu drehen sein würde, aber immer noch eine gute, stabile, kampferprobte Technologie haben. Was Sie am Ende aus der Box bekommen, wenn Sie nur den Anweisungen folgen, ist wirklich unglaublich.

Drew: Jamstack-Enthusiasten werden Dienste wie FaunaDB kennen, die Sie erwähnt haben, die einen Datenspeicher als API bereitstellt, AWS hat DynamoDB, Google hat Cloud SQL und so weiter. Also, Sie haben erwähnt, dass Redwood eine Integration anstrebt, oder ich denke, Prisma ist die Komponente hier, die eine Integration mit diesen Arten von Diensten im weiteren Verlauf anstrebt?

Anthony: Ja, das ist eine gute Frage. Das ist etwas, mit dem ich gerade mit Ryan Chenkie bei Prisma über eine Art Hilfe spreche. Was ist die Art von Datenbankgeschichte für Redwood für Dinge, die nicht unbedingt mit Prisma funktionieren? Wäre es besser, einen Weg zu finden, Redwood dazu zu bringen, direkt damit zu arbeiten, wie ich es mit Fauna getan habe, oder wäre es sinnvoller, einen Treiber für Prisma zu implementieren? Es gibt also verschiedene Herangehensweisen. Offensichtlich gibt es jetzt eine Million verschiedener Datenbanken, die jeder verwenden möchte. Es hängt also davon ab, wie motiviert Sie sind, Ihren Datenspeicher darauf zu bringen. Es gibt eine Menge Community-Beiträge, die dort hineingehen.

Drew: Da Prisma Ihr Modell versteht und weiß, wie man sie abfragt, ist es in der Lage, Migrationen oder ähnliches zu generieren, um Ihnen bei der Einrichtung dieser Datenbank zu helfen?

Anthony: Das ist genau das, was Sie verlieren, wenn Sie Prisma herausnehmen und Ihre Daten abrufen müssen, nämlich, dass Sie alle Migrationsfunktionen verlieren. Es hat eine wirklich fortschrittliche CLI, die eine Menge Dinge für Sie erledigt, sodass Sie das gesamte Redwood-Tutorial durchgehen und die Prisma-Befehle eingeben können, und Sie müssen keine Ahnung haben, was es tut, es funktioniert einfach. Es ist ein wirklich großartiges Werkzeug, um all diese Art von Datenbank-Zeug zu erledigen, bei dem Sie sicherstellen möchten, dass Sie es richtig machen und Sie sicherstellen möchten, dass es richtig gemacht wird.

Drew: Es scheint, als wäre ein wirklich gutes Tooling rund um Frameworks ein ziemlich moderner Trend, nicht wahr? Um nicht nur zu sagen: „Hier sind alle Dinge, die dieses Framework tun kann, aber hier sind vielleicht einige CLI-Tools, die eine ganze Menge davon für Sie erledigen werden.“ Hat Redwood Tools für Dinge wie CLI-Generatoren und ähnliches, um Sie schnell zum Laufen zu bringen?

Anthony: Das ist wahrscheinlich das größte Hauptmerkmal, das Sie von Redwood bekommen, ist, dass Sie eine ganze Reihe sehr ausgeklügelter Generatoren bekommen. Für jeden, der jemals die originale Ruby on Rails-Demo gesehen hat, die DHH gab, er baut einen Blog in etwa 15 Minuten auf und er macht alles mit Rails, und die Leute sagen: „Whoa, das ist erstaunlich.“ Das ist der Effekt, den Redwood anstrebt. Sie möchten, dass Sie in der Lage sind, alles sehr schnell hochzufahren, damit Sie Seiten generieren können, Sie können Layouts generieren, Sie können Ihre Zellen generieren, worüber ich gesprochen habe, und Sie können einen Gerüstbefehl ausführen, der Ihr gesamtes erstellt CRUD-Schnittstelle. Ich habe einen ganzen Abschnitt, Teil vier der Blog-Serie, erklärt nur den gesamten Code, den das Gerüst Ihnen gibt. Es gibt Ihnen so viel Code. Es gibt einen Off-Generator, es gibt sogar einen Tailwind-Generator, der Ihren Rückenwind für Sie konfiguriert.

Drew: Das ist erstaunlich. Ich erinnere mich, dass ich DHHs Demo von Rails gesehen habe. Ich meine, es war wahrscheinlich vor 15 Jahren, als er zum ersten Mal dieses Gerüst erstellte und Ihnen zeigte, und Sie erhalten ein ziemlich rudimentäres, aber funktionales Bedienfeld, mit dem Sie im Wesentlichen neue Elemente erstellen, bearbeiten, löschen usw. können . Das kann in einem Projekt von unschätzbarem Wert sein, besonders wenn Sie in einer Art dynamischer Umgebung arbeiten, in der Sie vielleicht in Zukunft bessere Tools zum Bearbeiten dieser Inhalte implementieren werden, aber es bedeutet, dass Sie schnell etwas entwickeln können, das Sie bekommen können Testdaten ein, oder Sie können sie sogar einem Content-Team übergeben, das mit der Arbeit beginnen könnte, während Sie am Frontend arbeiten, das ist also wirklich nützlich.

Drew: Wenn Sie das nur bereitstellen und in der Produktion haben wollten, können Sie es vermutlich einfach zusammen mit Ihrem Front-End-Code bereitstellen, aber Sie müssten diesen Aspekt, diese Wurzeln in Ihrer Anwendung, irgendwie sichern.

Anthony: Ja, es gibt ein paar verschiedene Optionen für die Authentifizierung. Sie können die Netlify-Identität verwenden. Das ist die Standardeinstellung, wenn Sie in das Tutorial gehen, und dann können Sie auch Auth0 verwenden, und dann einen, mit dem ich nicht vertraut bin, namens Magic.Link, und es werden wahrscheinlich in Zukunft ein paar zusätzliche hinzugefügt. Aber ja, es gibt dort bereits ein paar eingebaute Lösungen, und das ist das Allerletzte, was Sie tun, also ist der allerletzte Teil meiner gesamten 12-teiligen Blog-Serie der Auth. Ich glaube nicht, dass ich Auth jemals herausgefunden hatte, bevor ich Redwood benutzte. Es ist schwer und sie haben definitiv einen guten Job damit gemacht.

Drew: Lässt sich das auf Routenebene integrieren oder auf Routenebene, Entschuldigung, wie sichern Sie die Dinge?

Anthony: Ja, ein Teil davon, dass sie ihren eigenen Router haben, haben sie auch … Sie können private Routen erstellen, also haben sie eine private Routenkomponente. Dann ist Ihr eigentliches Anmeldeformular das, was Sie von der Netlify-Identität erhalten, sodass Sie kein Formular erstellen und damit Ihre Statusverwaltung durchführen müssen. Hier kommen viele Probleme ins Spiel. Wenn Sie die wirklich wichtigen Teile wegnehmen, können Sie einfach den rollenbasierten Zugriff implementieren. Wir haben ein rollenbasiertes Zugriffskontroll-Add-On, das in den letzten Wochen von David T. erstellt wurde. Es gibt also viel Arbeit, um andere Möglichkeiten zu finden, dies zu tun, aber was sie jetzt haben, ist bereits ... es funktioniert, es' Ich werde Sie funktionsfähig machen.

Drew: Die Leute sagen immer über Sicherheitsalgorithmus-Hashing-Kryptographie, dass Sie niemals Ihre eigene schreiben sollten, weil sie niemals so gut sein wird wie die Dinge, die da draußen sind. Ich denke, das gilt zunehmend auch für die Authentifizierung auf höherer Ebene; Diese Authentifizierung ist heutzutage ein so komplexer Bereich, dass sich Benutzer nicht nur mit eindeutigen Anmeldeinformationen bei Ihrer Website anmelden möchten, sondern sich möglicherweise mit Google authentifizieren möchten, oder sie möchten sich mit einem Apple-Gerät authentifizieren, oder sie möchten möglicherweise eine Zwei-Faktor-Authentifizierung , oder sie möchten es in einen Single-Sign-On-Dienst integrieren, den sie von einem Unternehmen aus verwenden. All diese Dinge sind solche Kopfschmerzen, wenn Sie versuchen, sie selbst zu implementieren, und bieten so viele Möglichkeiten, etwas falsch zu machen und Sicherheitslücken in Ihrer Anwendung aufzudecken, dass die Verwendung eines Authentifizierungsdienstes an dieser Stelle für mich fast wie ein Kinderspiel erscheint. Es klingt also nach einer wirklich produktiven Art zu arbeiten und die Dinge sicher zu halten, einfach in der Lage zu sein, etwas mit im Wesentlichen ein paar Zeilen Code einzufügen und einsatzbereit zu sein.

Drew: Es hört sich so an, als ob die Bereitstellung sowohl des Front-Ends als auch der Serveraspekte, der serverlosen Funktionen, natürlich für die Bereitstellung auf Netlify geeignet ist. Sind Sie mit Redwood darin verwickelt? Ich meine, wir haben erwähnt, dass Tom Preston-Werner einer der Hauptbefürworter dieses Frameworks ist, er ist auch im Vorstand von Netlify. Glaubst du, dass es dort Potenzial für eine zu enge Kopplung gibt, wenn du Redwood als Basis für ein Projekt wählen würdest?

Anthony: Ja, das ist etwas, dessen sich Tom definitiv bewusst ist. Er hat in viele Unternehmen investiert, die herumschwirren. Er investierte in Prisma und Fauna. Er möchte nur die Werkzeuge herstellen, die er verwenden möchte. Es geht nicht darum, dass wir Sie in diese Sache einsperren wollen, sondern das, was Netlify gebaut hat, seiner Meinung nach die beste Option ist, also haben sie darum herum gebaut. Aber sie wollen nicht, dass es an ein bestimmtes Bereitstellungsziel gebunden ist, und deshalb haben wir an Dingen wie dem Serverless-Framework gearbeitet und einige Leute haben über Begin gesprochen. Wir wollen pragmatisch sein, wir wollen, dass es für jeden Anwendungsfall funktioniert. Wir bringen Sie also zu 90 % fertig und dann müssen Sie nur noch die letzten paar Dinge verkabeln, damit es mit dem Server Ihrer Wahl funktioniert.

Drew: Ich schätze, sogar Netlify verwendet AWS Lambda für die Serverfunktionen, also ist es wirklich der Bereitstellungsteil, der dort von Redwood erledigt wird, und eigentlich könnten Sie das selbst für Lambda bereitstellen. Das Posten Ihres Frontends besteht nur aus Dateien, nicht wahr, der Rest basiert auf CDN? Es gibt also ziemlich viel Flexibilität, ohne zu sehr gebunden zu sein.

Anthony: Ja, es gibt tatsächlich einen Begriff, über den Tom als die philosophische Kernidee hinter Redwood spricht, nämlich dass wir zu einer universellen Bereitstellungsmaschine gelangen wollen. Das ist irgendwie keine Idee, ist, dass Sie Dinge einfach bereitstellen können und überhaupt nicht darüber nachdenken müssen. Er spricht seit Jahren und Jahren und Jahren über diese Idee, und genau darum ging es Jekyll damals sogar. Wenn du das jetzt hörst, denkst du: „Oh, du meinst wie Netlify?“ Das ist im Grunde das, was Netlify für die meisten Leute ist, die am Frontend arbeiten. Sie denken nicht einmal mehr an einen Einsatz, es ist nicht einmal ein Gedanke.

Drew: Hier ist meine Anwendung in einem Git Repo, dieses Verzeichnis ist das Frontend, dieses Verzeichnis ist das Backend, hier ist meine Datenbank, und das ist ungefähr so ​​viel Konfiguration, wie Sie vielleicht benötigen würden, um den Dienst zu übernehmen und zu erstellen und hoste es.

Anthony: Ja, und auf eine Sache sollte ich auch hinweisen: Wir haben erst vor kurzem die Standardbereitstellung von Vercel Redwood eingerichtet. Wenn Sie also eine serverseitige Anwendung bereitstellen, können Sie sagen: „Oh, ich habe die Gatsby-App“ und Es weiß genau, wie man eine Gatsby-App im Vergleich zu einer NextApp erstellt. Das haben wir jetzt für Vercel. Es gibt also auch wirklich, wirklich gute Optionen außerhalb von Netlify, wenn Sie sich mehr dafür interessieren.

Drew: Also, wenn ich loslegen und eine App bauen und diese Woche in Produktion nehmen wollte, ist Redwood dafür bereit? Ist es ausgereift?

Anthony: Ja, wir haben etwa ein halbes Dutzend Apps, die derzeit in Produktion sind. Das erste hieß Predict COVID und kam im März heraus. Es ist wie eine Echtzeit-Datenvisualisierungsanwendung. Dann haben wir noch repeater.dev, das von Rob gemacht wird, es ist wie ein Cron-Job wie bei Jamstack. Dann gibt es Tape.sh, Duoflag, glaube ich, ist ein weiteres. Es gibt also mindestens eine Handvoll. Wenn Sie sich für ein fantastisches Redwood-Repo entscheiden, können Sie eine Liste aller sehen. Wenn Sie zu den Community-Foren gehen, können Sie auch Berichte darüber finden, weil die Leute diese in Produktion genommen haben und irgendwie gesagt haben, wie es gelaufen ist. Bisher waren sie alle erfolgreich und niemand hat gesagt: „Ich benutze das nie wieder.“

Drew: Aber es ist sehr neu. Ich schätze, dem lässt sich nicht entkommen, aber in Bezug auf die Reife ist Redwood ziemlich neu und bekommt eine gute Anhängerschaft.

Anthony: Nun, es ist lustig, es ist und es ist nicht. Das wurde im März bekannt gegeben. Zu diesem Zeitpunkt hatten Tom und Peter etwa ein Jahr daran gearbeitet. So, they'd already put a ton of upfront work into this, so it wasn't like I'm going to announce this project with a Read Me and then start building it. By the time they announced it, it wasn't… It's not a 1.0 now, but it's pretty dang close in terms of what people would expect out of a 1.0. But, Tom is very against what we call type driven development so he always errs on the say it's not ready. So, we say it's not ready for production even though it's in production.

Drew: I think one thing that people sometimes get burned on using frameworks is that they'll build a project around the framework and then that framework will very quickly go to another major version that had backwards incompatibilities, and they're then left with a big project to update everything onto the new version of the framework. Is that something that's likely to happen with Redwood? I mean, none of us has got a crystal ball, but just with the technologies that are involved and the way it's structured, do you think that's a big danger or a little danger?

Anthony: Yeah, it's a super valid concern and definitely something the team has thought about. The CLI has an upgrade command, so you can basically every time there's a version bump, you just do a command and it bumps you up the version. I've been dealing with this a little bit just because of the series I wrote, I started it when it was on version 11 or 0.11, it's like 0.17 or something now. So, I've been slowly iterating on it as it's gone but nothing breaks. It's all, you get slowly things, or like “Oh, this is kind of a nice little touch you've got here,” but it's pretty much set in stone architecturally. Redwood as it's structured, the front or the back end is not going to change at all. It was very well thought out in terms of what they want architecturally. That's why they built it, so they could get something that's structured like this thing.

Drew: I guess with modern web development, there is a certain point where you're just never going to get away from being reliant on dependencies updating themselves and changing. I mean, even using React, React goes through as many different changes as anything else.

Anthony: That's exactly why Tom inventing semantic versioning.

Drew: I guess from the other side of that coin, if Redwood did happen to go away, which is always something we consider when picking a framework, if development stopped somehow, I guess the impact on a particular app might not be too great because it is just so heavily built on existing other projects around. Is that-

Anthony: Well, some would say that a Redwood tree can survive a lot, it survives for a very long time. That may have been why it's called that, is that you can just make a site and deploy it and it's not going to break, it's just going to work. So yeah, maintainability, sustainability, all that kind of stuff, that's huge. Being built by people who tried to scale Rails apps, I imagine they've thought a lot about that. But in terms of the going away part, that's always going to be a danger with any open source project, so I think what you have to look for is how enthusiastic is the community to continue it without the team if that ever happens. I don't think you even need to worry about that because Tom's a billionaire and he has a venture funding thing that is funding some of the development. It is an open source project that is well funded actually. It has four full time members, Tom, Rob, David, and Peter. You just go to the forums, you can see the activity that's going on, so I wouldn't worry about that too much-

Draw: Natürlich.

Anthony: Beyond normal open source worries that come along with that stuff.

Drew: What is the community like? You mentioned the community, are there lots of people using it and contributing to the code base or is it mainly the core team who are doing the development?

Anthony: Yeah, it's very much structured to be a community thing. They want to get as much buy in from the community as possible, and this comes from the lineage like you said. There's few people with more open source cred than Tom, so he's done a really great job of bringing people into the fold. I think just my story in general is a big win for the community because I came in, I'm a boot camp student, I'm learning all this stuff as I go. I'm not pushing code to the repo, I'm making doc fixes and writing blog articles and stuff, but they still invited me to the core contributors meeting because they saw what I was doing and they thought it was adding value. Yeah, there's really a lot of things about how they approach community building that I have a lot of respect for, and that is why I've been so invested in it and putting so much of myself into it.

Drew: Some frameworks have got this sort of natural bent for certain types of projects. Zum Beispiel. The Python framework, Django came out of online news publishing, and so it's a really good fit if you want to rapidly publish content like you would in a news organization. Does Redwood lean in any particular direction when it comes to the type of projects? Is it suited for content publishing or building web applications or-

Anthony: It's made to be fairly agnostic to that. It wants to be a tool that you use for a lot of stuff. First, before it was called Redwood, it was called Hammer, the idea being that you do a lot of stuff with a hammer. But, there definitely is a kind of sweet spot, which I think is the multi client type applications. So, if you know that you're starting with a web front end but you're pretty sure you're going to end up with a mobile client as well, then it's a really good fit for that because it starts you off in a way that you're going to be able to extend into having multiple clients with GraphQL, which we kind of talked about a little bit. So, I'd say that'd probably be the first thing that I would say is its sweet spot. But, it's meant to work for as many things as possible.

Drew: Does Redwood have a published roadmap of where it's going? What can we expect to be coming in the near future?

Anthony: Glad you asked. We just put out a roadmap to 1.0 less than a month ago, it was probably like two or three weeks ago. It kind of itemizes things that we're working on, things we think we're kind of close on, things we think we still have a long ways to go on. That kind of helps the community see where can I help contribute. That's one of the things we're really great about is showing here are the things that still need to be worked on. They're aiming for 1.0 by the end of the year. We'll see where we get with that, but that's the trajectory we're currently on.

Drew: One of the beauties of a Jamstack and a serverless approach I always think is that it's this idea of lots of pieces loosely joined that has served us so well in computer science up until this point. It should be really easy to scale up a Jamstack and serverless project because you can add multiple front ends or you could put more resources behind running your functions, and you can scale up a big engineering team by having people work on different small pieces. Is there a danger that adopting a framework around all of that, that you might be taking a distributed architecture and creating a tighter binding than you might otherwise have? Could Redwood become the monolith that acts as a bottleneck in your engineering efforts?

Anthony: Yeah, this is something I think about a lot because as I learned web development, I was taking… I'm in a boot camp that supposedly is full stack development, but you learn each piece in isolation. We're essentially learning the PERN stack, but you learn React, and then we learned Express. We never talked about how it actually works together. So, I do think that there is definitely a danger of not being able to comprehend in your project because of how it's all wired up. So, what I really liked about Redwood is that it just made sense. It was a mental model of how to think about my entire app and all the pieces and how they fit together in a way that really made sense to me. But, what I was surprised to find doing the Fauna project is that it's much more modular than you would think based on… You talk about it, and like you said, it sounds like it's a monolith thing, but you can rip pieces out and replace them with other pieces and they can still work. So, it's made to be a fully integrated solution, but not a solution that is tightly coupled just because this is a good way to integrate all these technologies doesn't mean you need to tightly couple them to integrate them well.

Drew: Yeah, that sounds a very promising way of structuring things, and it's going to be really exciting to see what happens with Redwood as it gets to version 1.0. Is there anything else we should know about it that we haven't talked about?

Anthony: No. I mean, I would say if you're interested, just check out the tutorial on YouTube, the RedwoodJS tutorial. They have what they call tutorial driven development, which is kind of a play on Read Me driven development, which is another thing Tom coined, that you should start with a Read Me, and then create your code to make sense with what your Read Me was. This is the idea of you create a tutorial and then you write your framework to make the tutorial work. So, that's why it's a really easy way to get spun up with it because it was made to make sense of going through the process of learning it. They've really thought about how to actually get onboarded into a massive framework with all these different pieces and all this different new tech. They progressively reveal it to you as you go. The series that I wrote is very heavily influenced by it. I essentially built the same project, but I write my own stuff as I go, and reference the docs. So, if you're interested in just learning Redwood, start with the actual tutorial and then check out my series.

Drew: So, I've been learning all about Redwood, what have you been learning about?

Anthony: Yeah, so I've been learning about CMSs, and I was actually really curious to get your thoughts on this because I imagine you've been around the block, you know a lot of CMSs. Obviously, you know you've got your WordPress's, your Drupal, but what's really interesting with something like Redwood is since you have this GraphQL stuff baked in, it has the CMS, it's just such a natural fit. So, I'm trying to figure out, what are interesting headless CMSs to check out? Which ones have GraphQL integration? Which ones have different sweet spots? If I wanted to take a CMS to build an app with RedwoodJS, what would you recommend?

Drew: That is a good question, and I'm not sure I have an immediate answer. I have looked at lots of different CMSs, not particularly with a view to GraphQL. I've not worked with GraphQL myself yet, and so that was not-

Anthony: Oh man, you've got to join the club, dude.

Drew: Yeah, no, I'm definitely getting onboard. But yes, I have a requirement at work that may be coming up to know a bit more about GraphQL, so it's certainly one of the things that I need to be learning.

Anthony: I actually learned GraphQL through Redwood. I didn't really know GraphQL, and I'd say you should know a little bit before going into it, and I had a very, very tiny basic knowledge. You can actually learn what a schema definition language is, and that GraphQL kind of jargon. You'll learn a lot and you'll pick it up as you go with Redwood.

Drew: Yeah, I should definitely get onboard and maybe doing some Redwood is the way to do it. Perhaps I need to pick up a project and start going with Redwood and see where it takes me.

Anthony: Yeah, at the very least I would say just check it out, just because it's interesting. I find it to be just a really fascinating thought experiment of how do we do modern web application development differently and more coherently.

Drew: If you, dear listener, would like to hear more from Anthony, you can find him on Twitter at ajcwebdev. His comprehensive series of articles about getting started with Redwood are on the Redwood community site, which we'll link to from the show notes. Of course, you can find all about Redwood and get started at RedwoodJS.com. Thanks for joining us today, Anthony. Hast du Abschiedsworte?

Anthony: Wenn Sie an irgendetwas davon interessiert sind, können Sie sich gerne melden. Meine DMs sind immer offen. Die Community ist generell sehr offen. Ich erkläre oder führe Sie gerne durch oder gebe Ihnen alles, was Sie wissen müssen, um loszulegen.