tl; dr Lassen Sie uns die DevOps / MLOps-Praktiken für die zukünftige Serie systematisch beherrschen In meinem Fall hielt ich es für eine gute Idee, zunächst die Front-End-Sprache Typescript (ts) und die Back-End-Sprache Scala / Python (mit Spark-Ökosystem) zu verbinden.
Grund für das Urteil:
1)Entwickler für Benutzeroberflächen(js/ts Benutzer)Python ist freundlich
※js/Es scheint, dass eine der von ts-Benutzern verwendeten Standardprogrammiersprachen Python ★ 1 ist
2)Hohe Affinität zwischen der Modelldefinition und der Funkenmodelldefinition
* Die Definition der Typoskript-Schnittstelle und die Fallklasse für Spark sind besonders ähnlich.
3)Das gegenseitige Rufen zwischen ts und spark wird immer einfacher (die Magie von "jsii").
* Testen Sie beispielsweise mit jsii eine von Scala in Typoskript geschriebene NodeJS-App./Kann mit Python gemacht werden.
4) terraform/ansible/docker/Meine Herausforderung mit Hashi Stack ist das moderne Frontend.
★ 1 Quelle: "Zweite Programmiersprache", die von JavaScript-Benutzern verwendet wird, Nummer eins ist Python
Typoskript, eine typisierte js-kompatible Sprache. Typoskript ist möglicherweise eine sicherere Option für Ingenieure, die ihre Backends in typisierten Sprachen (C # / Scala usw.) schreiben, obwohl es möglicherweise einen höheren Schwellenwert als js hat. Es scheint, dass auch Know-how beim Ausführen von Typescript auf NodeJS, das eine unverzichtbare Option für die Webentwicklung darstellt, angesammelt wird.
Im Folgenden nehmen wir als Beispiel das Nest.js-Framework, das eine der jüngsten Lösungen von "Typescript on nodejs" zu sein scheint. Wird weiterhin sein.) Referenz Nest.js ist wunderbar
Typoskript-Modelldefinitionen mit Schnittstellen sind mit C # und Scala kompatibel. Lassen Sie mich Ihnen ein Beispiel geben. ↑ Nest.js Großartiger Artikel, [Erstellen einer Benutzeroberfläche mit Nest.js](https://qiita.com/kmatae/items/5aacc8375f71105ce0e4#user%E3%82%A4%E3%83%B3%E3%82 % BF% E3% 83% BC% E3% 83% 95% E3% 82% A7% E3% 83% BC% E3% 82% B9% E3% 81% AE% E4% BD% 9C% E6% 88% 90 Die in) erstellte Benutzermodellschnittstelle user.interface.ts lautet wie folgt:
typescript:user.interface.ts
export interface IUser {
id: string;
name: string;
kana: string;
email: string;
postcode: string;
address: string;
phone: string;
password: string;
admin: boolean;
createdAt: Date;
updatedAt: Date;
}
Im Gegensatz dazu lautet die entsprechende Scala-Klasse für Spark beispielsweise:
IUser.scala
case class IUser (
id: String,
name: String,
kana: String,
email: String,
postcode: String,
address: String,
phone: String,
password: String,
admin: Boolean,
createdAt:TimeStamp,
updatedAt:TimeStamp
)
Es ist eine Ebene, die durch mechanisches Ersetzen durchgeführt werden kann (hier wird Scala verwendet, aber Python (PySpark) mit Typanmerkungen wie Typscript ist auch dasselbe). Es ist praktisch einfach, nur grundlegende Typen wie String / Int / Boolean / TimeStamp für Eigenschaften zu verwenden, die für Spark beibehalten werden. Wenn die Front-End-Seite auf die gleiche Weise sicher schreiben kann, ist die Geschichte schnell (nest.js ist eine Übersicht, ich habe das Gefühl, dass ich sie sicher und produktiv schreiben kann ... Schreibe ich sie tatsächlich selbst? Bitte oder nicht). Wenn Sie json aus node.js generieren können, das in Typescript geschrieben ist, und es in spark (mit Kafka usw. dazwischen oder Quasi-Stream-Verarbeitung) gießen können, ist der Rest irrelevant. Auf der Backend-Seite ist Spark eine der Standardlösungen zur Beschreibung von Daten-Hubs zwischen Datenspeichern (Verbindung von CSV, Cassandra, Hive, Neo4J, Infrastruktur für maschinelles Lernen usw.).
Das von AWS erstellte jsii, das ich aus dem folgenden Artikel gelernt habe. Einführung in das magische "jsii", mit dem in TypeScript geschriebene Programme mit Python usw. ausgeführt werden
jsii bedeutet, dass TypeScript-Code direkt aus der Python / JVM-Sprache (Scala) / C # aufgerufen werden kann. Dies bedeutet, dass Sie Typescript-Testcode in Python oder Scala schreiben können. In dem System, das den tatsächlichen Betrieb aufgenommen hat, ändert sich das Typescript-Modell abhängig von den Umständen auf der Front-End-Seite (Serviceerweiterung usw.). Es ist schön, die Datenübertragung kontinuierlich testen zu können, wenn sich das Modell ändert (das Testen, wenn nicht typisierte Daten (z. B. CSV) in die Funkenwelt gebracht werden, ist ziemlich umständlich).
Kürzlich habe ich persönlich untersucht, wie schnell die Rückseite (Dateninfrastruktur) eines Systems mit einem Web-Frontend erstellt werden kann, das die Leistung verfolgt. Ich bin nicht mit der Front-End-Technologie vertraut, aber ich konnte ein Gefühl dafür bekommen, indem ich Svelte / typescript / nodejs / firebase ... der Reihe nach berührte. In Zukunft möchte ich versuchen, eine Verbindung mit der Backend-Funken-Seite herzustellen, während ich meine Hände mit nestjs / SSR / ts2elm bewege. Ich hoffe, dass die Github-Aktion, die CI / CD auf NodeJS und Docker abzielen kann, nützlich sein wird.
Recommended Posts