tl; dr Maîtrisons systématiquement les pratiques DevOps / MLOps pour les futures séries Dans mon cas, j'ai pensé que ce serait une bonne idée de commencer par connecter le langage frontal Typescript (ts) et le langage back-end Scala / Python (avec l'écosystème Spark).
Raison du jugement:
1)Développeur frontal(js/utilisateur ts)Python est convivial
※js/Il semble que l'un des langages de programmation standard utilisés par les utilisateurs de ts soit python ★ 1
2)Haute affinité entre la définition du modèle TS et la définition du modèle Spark
* La définition de l'interface Typescript et la classe de cas pour Spark sont particulièrement similaires.
3)L'appel mutuel entre ts et spark devient plus facile (la magie de «jsii»).
* Par exemple, en utilisant jsii, testez une application nodejs écrite en typographie par Scala./Peut être fait avec Python.
4) terraform/ansible/docker/Mon défi avec hashi stack est le front-end moderne.
★ 1 Source: "Deuxième langage de programmation" utilisé par les utilisateurs de JavaScript, le numéro un est Python
Typescript, un langage compatible js typé. Typescript peut être une option plus sûre pour les ingénieurs qui écrivent leurs backends dans des langages typés (C # / Scala, etc.), bien qu'il puisse avoir un seuil plus élevé que js. Il semble que le savoir-faire lors de l'exécution de Typescript sur nodejs, option indispensable pour le développement Web, soit également accumulé.
Dans ce qui suit, nous prendrons le framework Nest.js, qui semble être l'une des solutions récentes de Typescript on nodejs
, comme exemple (bien que le framework soit devenu obsolète, Typescript on nodejs
restera un choix standard. Continuera de l'être.)
Référence Nest.js is wonderful
Les définitions de modèle Typescript avec interfaces sont compatibles avec C # et Scala. Laisse moi te donner un exemple. ↑ Nest.js Excellent article, [Création d'une interface utilisateur avec 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 L'interface du modèle utilisateur user.interface.ts créée dans) est la suivante:
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;
}
En revanche, la classe scala correspondante pour Spark est, par exemple:
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
)
C'est un niveau qui peut être fait par remplacement mécanique (scala est utilisé ici, mais Python (PySpark) avec une annotation de type comme Typscript est également le même). Il est pratiquement facile d'utiliser uniquement des types de base tels que String / Int / Boolean / TimeStamp pour les propriétés qui sont conservées dans Spark. Si le front-end peut écrire en toute sécurité de la même manière, l'histoire est rapide (nest.js est un aperçu, j'ai l'impression de pouvoir l'écrire en toute sécurité et de manière productive ... Est-ce que je l'écris moi-même? S'il vous plaît ou pas). Si vous pouvez générer json à partir de node.js écrit en Typescript et le verser dans Spark (avec Kafka, etc. entre les traitements ou semi-stream), le reste ne sera pas pertinent. Côté backend, Spark est l'une des solutions standard pour décrire les hubs de données entre les datastores (connexion csv, cassandra, hive, neo4j, infrastructure de machine learning, etc.).
Le jsii créé par AWS que j'ai appris dans l'article suivant. Présentation du "jsii" magique qui exécute des programmes écrits en TypeScript avec Python, etc.
jsii signifie que le code TypeScript peut être appelé directement à partir du langage Python / JVM (Scala) / C #. Cela signifie que vous pouvez écrire du code de test Typescript en Python ou Scala. Dans le système qui est entré en fonctionnement réel, le modèle Typescript changera selon les circonstances du côté frontal (extension du service, etc.). C'est bien de pouvoir tester en permanence le transfert de données au fur et à mesure que le modèle change (les tests lors de l'introduction de données non typées (par exemple CSV) dans le monde des étincelles sont assez fastidieux).
Récemment, j'ai personnellement étudié comment créer rapidement l'arrière (infrastructure de données) d'un système avec un front-end Web qui recherche la performance. Je ne suis pas familier avec la technologie front-end, mais j'ai pu en avoir une idée en touchant Svelte / typescript / nodejs / firebase ... dans l'ordre. À l'avenir, j'aimerais essayer de me connecter avec le côté de l'étincelle du backend tout en déplaçant mes mains avec nestjs / SSR / ts2elm .... J'espère que l'action github, qui peut cibler CI / CD nodejs et Docker, sera utile.
Recommended Posts