Désormais, nous prévoyons de traiter des micro-services créés autour de Play Framework (ci-après dénommés Play). Play a un bon nombre de changements de rupture à chaque fois que la version passe à 0,1. Ainsi, en vue de mettre à niveau certains services implémentés dans la version précédente vers la dernière version, je vais (re) présenter la dernière version de Play Framework 2.7 pour le moment. J'utilise rarement la version 2.6, donc je rattraperai de temps en temps la connaissance de la version 2.6.
Play facilite le lancement d'un projet basé sur sbt (commande de modèle de départ ci-dessous).
Lisez le dernier modèle de version pour Java:
sbt new playframework/play-java-seed.g8
Jouez au dernier modèle de version pour Scala:
sbt new playframework/play-scala-seed.g8
Cependant, le premier démarrage prend beaucoup de temps car les bibliothèques dépendantes sont collectées à partir de chaque référentiel. Lorsque vous essayez Play, c'est une bonne idée d'appuyer sur l'une des commandes ci-dessus, puis d'exécuter sbt et de collecter les informations nécessaires.
Dans mon cas, il a fallu environ 6 minutes à Play pour démarrer en mode développeur, et environ 30 secondes au navigateur pour accéder au port 9000, terminer la compilation initiale et obtenir une réponse. Cela prendra plus de temps en fonction des conditions de la ligne.
Lisez "Play 2.7.0 est ici!" dans le blog Play Framework. Là, huit nouvelles fonctionnalités de Play 2.7 sont répertoriées. Ci-dessous, mon impression:
Un play-grpc basé sur akka-grpc a été fourni. Du point de vue du développement de microservices, je suis content (bien que ce soit actuellement traité comme Incubation). Avec grpc pris en charge en standard, il sera plus facile de se lier à d'autres services en utilisant des langages de schéma standard tels que les tampons de protocole. Si vous n'avez pas utilisé de tampons de protocole, etc., obtenez une image du langage de schéma ci-dessous.
L'époque où nous ne pouvions écrire qu'une seule application Web qui se connecte à un seul RDB est révolue. Les données peuvent être stockées dans diverses technologies de stockage ici et là, le backend peut être divisé plutôt qu'un service unique, et les clients peuvent avoir des versions Web, iOS et Android, chacune dans une langue différente. Il est implémenté dans, et l'API doit également être exposée à des développeurs externes. Par conséquent, il est nécessaire de sérialiser et de désérialiser les données partout, et de s'assurer qu'il n'y a aucune incohérence dans l'interprétation aux deux extrémités de la communication. Cependant, il est douloureux de parler aux humains en langage naturel dans le but de faire la correspondance, nous voulons donc parler avec un code traitable par machine. Par conséquent, je veux définir correctement quel type de données viendra dans le DSL déclaratif. C'est donc un langage de schéma. (Exposition [Pourquoi le langage du schéma est important](https://qiita.com/yugui/items/160737021d25d761b353#%E3%82%B9%E3%82%AD%E3%83%BC%E3%83%9E % E8% A8% 80% E8% AA% 9E% E3% 81% AF% E3% 81% AA% E3% 81% 9C% E9% 87% 8D% E8% A6% 81% E3% 81% AA% E3 % 81% AE% E3% 81% 8B))
Pour avoir une idée du code, jetons un coup d'œil à l'exemple Hello World grpc dans Play2.7 grpc.
Définition de schéma de Hello World grpc par tampons de protocole:
//(Extrait)
package helloworld;
service GreeterService {
rpc SayHello (HelloRequest) returns (HelloReply) {}
}
message HelloRequest {
string name = 1;
}
message HelloReply {
string message = 1;
}
Exemple d'implémentation du service Greeter par Play2.7.
GreeterServiceImpl.scala
/*
* Copyright (C) 2018-2019 Lightbend Inc. <https://www.lightbend.com>
*/
package example.myapp.helloworld.grpc.helloworld
import akka.stream.Materializer
import javax.inject.Inject
import javax.inject.Singleton
import scala.concurrent.Future
/** User implementation, with support for dependency injection etc */
@Singleton
class GreeterServiceImpl @Inject()(implicit mat: Materializer) extends AbstractGreeterServiceRouter(mat) {
//Recevez Hello Request and Future[HelloReply]SayHello méthode qui retourne
override def sayHello(in: HelloRequest): Future[HelloReply] =
Future.successful(HelloReply(s"Hello, ${in.name}!"))
}
// #service-impl
Si vous n'avez jamais utilisé akka, il y a certains termes que vous ne pouvez pas voir, mais regardons simplement la méthode sayHello. Puisque la réponse de la méthode est Future [Hello Reply], on peut voir que les services sont échangés de manière asynchrone. Cet exemple est actuellement basé sur Scala, mais Java peut également être écrit en Future-based. La méthode sayHello ci-dessus semble pouvoir être écrite de cette manière en Java.
@Override
public CompletionStage<HelloReply> sayHello(HelloRequest in) {
String message = String.format("Hello, %s!", in.getName());
HelloReply reply = HelloReply.newBuilder().setMessage(message).build();
return CompletableFuture.completedFuture(reply);
}
Un exemple de code et de documentation pour grpc est en cours de développement ci-dessous. https://developer.lightbend.com/docs/play-grpc https://github.com/playframework/play-grpc
Ce serait formidable si le grpc de play2.7 pouvait être le déclencheur pour que les principaux frameworks basés sur JVM (basés sur Spring) soient connectés les uns aux autres via grpc. En fait, lorsque le service se développe, il peut être plus facile de remplacer les parties qui sont grandement affectées par le garbage collection par C ++ ou Go.
Il semble que l'arrêt coordonné d'Akka introduit à partir de Play 2.6 ait été intégré au cycle de vie de Play en 2.7. Il s'agit en fait de Play 2.7, et vous l'apprécierez lorsque vous créerez un service qui évolue de haut en bas à tout moment.
Les API Play Cache sont désormais basées sur la caféine Java 8. La caféine semble commencer à être utilisée dans Spring Boot et ainsi de suite. Cette PAI peut réduire la nécessité de lancer et de mettre en cache Redis, etc. en externe.
Je ne peux pas faire de commentaire car je n'ai pas étudié la "Politique de sécurité du contenu (https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)", mais j'aimerais profiter de cette opportunité pour commencer.
Référence Étude de la politique de sécurité du contenu (CSP)
Cela semble être bien en Java. Soumettez facilement des formulaires, simplifiez le code lors du retour aux requêtes Http (pour pouvoir écrire sans Http.Context), etc.
D'un autre côté, en jeu, le style d'écriture précédent ne fonctionne souvent pas à chaque mise à niveau, alors faites attention à ne pas changer le style d'écriture. La dernière moitié des faits saillants de la version est répertoriée. https://www.playframework.com/documentation/2.7.x/Highlights27
Vous l'apprécierez lors de l'écriture d'une API REST dans Play 2.7. Personnellement, j'aimerais que Play supporte activement graphql, qui tire parti de la base asynchrone.
Je voudrais écrire un exemple de micro service qui utilise grpc comme colle (connecteur) dans Play 2.7 dans le but de Golden Week.
Recommended Posts