API stands for Application Programming Interface, which is a set of functions and commands that allows different software applications to communicate with each other.
RPC stands for Remote Procedure Call, which is a protocol that one networked computer program can use to request a service from another program located in a different computer server on the network without having to understand the network's details.
"API RPC" refers to a particular kind of API that employs the RPC protocol to perform its services. This allows for real-time communication between a client and a server, in which the client sends a message for the server to execute a specific procedure.
The main problem with JSON is the tooling. OpenAPI Generator provides a tool to generate stubs for the data. There is also Swagger CodeGen but they are IMO piss poor in terms of documentation and support.
With Protobuf (plus GRPC) you get smaller network footprint and a performant server implementation that gets generated for you. However, the .proto files do not have much in terms of schema definition. It is meant to be a binary data transfer protocol meant for machine to machine. Even if it can be sent over HTTP as binary, it just adds to the complexity because you'd need specialized tools to debug it.
In a microservices architecture, I'd use JSON for the following:
anything going outside (i.e. HTTP requests/responses)
Data stored in Kafka (makes thing much easier to debug)
Data stored in MySQL (which has a JSON data type)
(to generalize any place where data is looked at and is persisted to disk)
I'd use Protobuf + GRPC for
remote procedure calls. This saves having to run a full HTTP stack, a GRPC server is much lighter.
values stored in Redis. This is primarily because Redis stores all data in memory so it's best to keep it as small as possible. I emphasized values because it's still best to keep keys readable. But this is if you need multiple languages to read through the data. Otherwise use the fastest serialization mechanism you have.
- włączenie DSL jako usługi z przesyłaniem TXT i YML
- podłączenie usług
- obsługa zbiorów danych, i odczyt poprzez
REQUEST PROTOCOL HOST OBJECT DATA FORMAT
GET http://local/object.yaml
DSL jest do specyficznych, wyspecjalizowanych zastosowań, tutaj chciałbym mieć okazję do tworzenia w różnych formatach tych scenariuszy, by je przesyłać i wykonywać w różnych miejscach jest coś takiego jak Apache CAMEL https://camel.apache.org/camel-k/2.0.x/
Camel is an open source integration framework that empowers you to quickly and easily integrate various systems consuming or producing data. from('timer:tick?period=3000') .setBody().constant('Hello world from Camel K') .to('log:info') inspirując się nim i JQUERY zrobiłem APIdsl ale to skomplikowane, gdy musisz uczyć się tych wszystkich URI dlatego łatwiej po prostu spiąć do kupy kod który masz lokalnie
APIDSL
w APIDSL chodziło o reuzycie kodu taki jaki jest teraz mysle nad czyms co ulatwi konfiguracje detali na początku myślałem o takim zapisie:
- Oczekiwany format - komenda - dana wejściowa
- Obiekt - komenda - wartość
APIRPC:
- format YAML, bo łatwiej to walidować
- kilka warstw,
- kod w zależnościach
- uruchaminie kodu jako usługa i zarządzanie na poziomie systemu
- SERVE możliwosć użycia z usług zdalnych i tutaj chce to wszystko zebrać do kupy tak jak robimy to w docker compose, ale o poziom wyżej, z możliwością konfigurowania samego formatu pliku np. na poczatku
wartswa podstawowa to warstwa systemu, dlatego każdy z tych parametrów może być obsługiwany lokalnie inaczej
to było by dobre, gdybym chciał stworzyć coś na wzór języka programowania tutaj chodzi o tworzenie scenariuszy np. deno to jezyk imperatywny, działający tylko z JS a mnie interesuje niezależnie od platformy aby wykonać dowolny kod, trzeba najpier mieć do dsypozycji biblioteki zamiast zmieniać biblioteki, chciałbym je dostosowywać w tym samym języku w którym są pisane a potem użyć tutaj w YAML bez względu na język język programowania typu nodej/python/... aby móc korzystać z klas, które są pośrenikami pomiędzy tym zapisem w YAML a konkretnymi bibliotekami myślę, że lepiej rozbić te dwie kwestie, jak biblioteka i adaptacja do użycia
Ta koncepcja polega na pisaniu konwertowalnego do różnej postaci jezyka deklaratywnego, ale z zachowaniem detali, podstawowe parametry programu to:
- INIT
- IMPORT
- SERVE
- RUN
- TEST
- SET
postanowiłem położyć nacisk na typowanie, aby zmienne były tylko deklarowane jako publiczne a wewnątrz używać typów danych, które są obiektami klas, dzięki czemu, można je rozwijać i tworzyć własne IMPORT pozwala na to staram się też nie używać rozwiązań typu pętla, czy if, aby zachować prostotę w logice zmaiasty tego mamy strukturę z typowaniem oczekiwanych danych apidsl bezpośrednio uzywał prostych skryptów bash-a
warstwa DSL dla komunikacji żeby można było wymieniać dane przez HTTP poprzez komendy w konsoli/na backendzie
format DSL: apifunc.host(provider.com).data(funkcja).format(json).funkcja('POST')
format URL requestów http:// provider.com / data_model . format
czyli przez CURL też można, np:
GET http:// provider.com / user . json?all
DELETE http:// provider.com / user . json ? username="enemy"YAML SCAN_NETWORK 192.168.0.0/24
TXT GET /device1/api/data
JSON POST /device2/api/data { "temperature": 25 }
JSON PUT /device2/api/data { "temperature": 20 }local file
LIST READ file://domain.txtor
LIST GET file://domain.txtRead remote file plik domain.txt zawiera listę adresów URL
LIST GET https://domena.com/domain.txtpobierz adres URL z listy LIST
URL FIRST LISTstwórz screenshoot z adresu URL elementu z listy LIST
IMAGE SCREENSHOT URLkonfiguracja Zapisz do lokalnego pliku o nazwie hosta w formacie PNG
IMAGE FILENAME | HOSTNAME FROM URL
IMAGE MIMETYPE PNGZapisz screenshot do folderu i nazwie pliku wczesniej zdefiniowanego
URL FIRST LIST
IMAGE SCREENSHOT URL
FILE PATH_FOLDER file://screenshots/
FILE CONTENT IMAGE
LOG FROM FILEwszelkie parametry podane na początku są ustalone jako default w trakcie wykonywania można je zmienić, np. ścieżka do pliku, może być stała a nazwa pliku dopasowywana do ale obie te wartości i zależności można ustalić wcześniej na koniec zapisz LOG z obiektu FILE
kaskadowo, kolejno
PATH_FILE FROM file://domain.txt
LIST GET PATH_FILE
URL EACH LIST:
IMAGE SCREENSHOT URL
IMAGE MIMETYPE PNG
FILE PATH_FOLDER /screenshots/
FILE FILE_NAME | HOST_NAME FROM URL
FILE CONTENT IMAGE
LOG FROM FILEPATH_FILE: FROM file://domain.txt
LIST: GET PATH_FILE
URL: EACH LIST
LIST:
IMAGE:
SCREENSHOT URL
MIMETYPE PNG
FILE:
PATH_FOLDER /screenshots/
FILE_NAME | HOST_NAME FROM URL
CONTENT IMAGE
LOG FROM FILEPATH_FILE: /domains/ionos.txt
LIST:
URI PATH_FILE
SEPARATOR NEL
URL EACH LIST:
IMAGE:
SCREENSHOT URL
MIMETYPE PNG
FILE:
PATH_FOLDER /screenshots/
FILE_NAME | HOST_NAME FROM URL
CONTENT IMAGE
LOG FROM FILEPATH_FILE: /domains/ionos.txt
LIST:
GET: PATH_FILE
SEPARATOR: NEL
URL EACH LIST:
IMAGE:
SCREENSHOT: URL
MIMETYPE: PNG
FILE:
PATH_FOLDER: /screenshots/
FILE_NAME:
HOST_NAME: URL
CONTENT: IMAGE
LOG:
PATH_FOLDER: /logs/
FILE_NAME: dsl.log
CONTENT: FILEPATH_FILE: /domains/ionos.txt
LIST:
GET: PATH_FILE
SEPARATOR: NEL
URL EACH LIST:
FILE:
PATH_FOLDER: /screenshots/
FILE_NAME:
HOST_NAME: URL
CONTENT:
IMAGE:
SCREENSHOT: URL
MIMETYPE: PNG
LOG:
PATH_FOLDER: /logs/
FILE_NAME: dsl.log
CONTENT: FILEIMPORT:
lodash: "https://esm.sh/lodash@4.17.21"
apirpc: "git@github.com:inframonit/bash.git"
PATH_FILE: /domains/ionos.txt
LIST:
GET: PATH_FILE
SEPARATOR: NEL
URL EACH LIST:
LOG:
PATH_FOLDER: /logs/
FILE_NAME: dsl.log
CONTENT:
FILE:
PATH_FOLDER: /screenshots/
FILE_NAME:
HOST_NAME: URL
CONTENT:
IMAGE:
SCREENSHOT: URL
MIMETYPE: PNGIMPORT:
lodash: "https://esm.sh/lodash@4.17.21"
apirpc: "git@github.com:inframonit/bash.git"
LIST: "git@github.com:apirpc/list.git"
FILE: "git@github.com:apirpc/file.git"
IMAGE: "git@github.com:apirpc/image.git"
SCREENSHOT: "git@github.com:apirpc/screenshot.git"
SET:
PATH_PROVIDER: "/domains/ionos.txt"
PATH_SCREENSHOT: "/screenshots/"
FILE_FORMAT: "png"
RUN:
LIST:
GET:
PATH_FILE: PATH_PROVIDER
SEPARATOR: NEL
ITEM: URL
EACH:
FILE:
PATH_FOLDER: PATH_SCREENSHOT
FILE_NAME:
HOST_NAME: URL
CONTENT:
IMAGE:
MIMETYPE: FILE_FORMAT
CONTENT:
SCREENSHOT:
GET: URL
SIZE: HDIMPORT:
lodash: "https://esm.sh/lodash@4.17.21"
apirpc: "git@github.com:inframonit/bash.git"
LIST: "git@github.com:apirpc/list.git"
FILE: "git@github.com:apirpc/file.git"
PATH: "git@github.com:apirpc/path.git"
IMAGE: "git@github.com:apirpc/image.git"
SCREENSHOT: "git@github.com:apirpc/screenshot.git"
SET:
PATH_PROVIDER: "/domains/ionos.txt"
PATH_SCREENSHOT: "/screenshots/"
TEST_PATH_SCREENSHOT: "/screenshots/*"
FILE_FORMAT: "png"
TEST:
PATH:
EXIST: PATH_PROVIDER
EXIST: PATH_SCREENSHOT
FILE:
GET: PATH_PROVIDER
RIGHTS: READABLE
RUN:
LIST:
- GET:
PATH_FILE: PATH_PROVIDER
- SEPARATOR: NEL
- ITEM: URL
- EACH:
FILE:
- PATH_FOLDER: PATH_SCREENSHOT
- FILE_NAME:
HOST_NAME: URL
- CONTENT:
IMAGE:
- MIMETYPE: FILE_FORMAT
- CONTENT:
SCREENSHOT:
- GET: URL
- SIZE: HD
TEST:
PATH:
EXIST: TEST_PATH_SCREENSHOT załadowanie yaml
- na podstawie IMPORT generowanie struktury projektów w .apirpc/
- pobieranie klas i na ich podstawie walidowanie i debugowanie
- na podstawie SET zapisanie zmiennych
- na podstawie RUN uruchomienie wywołań
- TEST - sprawdzenie przed i po wykonaniu
class Screenshot {
public get;
public size;
run (){
}
}class File {
public path_folder;
public file_name;
public content;
contentFromImage() {
}
run (){
}
}class Image {
public mimetype;
public content;
run (){
}
}zapisywanie logów
FILE:
PATH_FOLDER /logs/
FILE_NAME dsl.log
CONTENT FILEITEM FIRST LIST
IMAGE GET ITEM
FILE CREATE IMAGE
kaskadowo, kolejno
LIST GET /path/to/folder/images/*
FILENAME EACH LIST | FILENAME GET ITEM | TXT OCR IMAGE | FILE CREATE file://domain.txtbot na strone www, desktop strato/login_screenshot.csv at main · botreck/strato
BROWSER GET https://strato.pl/auth/login.html
BROWSER FOCUS | CLASS input.text.login
BROWSER WRITE | TXT GET file://strato.pl/.user
BROWSER FOCUS | CLASS input.text.password
BROWSER WRITE | TXT GET file://strato.pl/.pass
BROWSER WAIT 3000
BROWSER CLICK | XPATH input.mid.button-green-large
BROWSER CREATE file://screen.pngWykonanie kodu poprzez skrypt z domyślnymi danymi:
./apirpc browser.yamllub z parametrami
./apirpc browser.yaml URL=https://strato.pl/auth/login.html PATH_OUT="/screenshots/" PATH_IN="/provider/" FOLDER_PROVIDER="strato.pl"browser.yaml
IMPORT:
XPATH: "git@github.com:apirpc/list.git"
TXT_FROM_FILE_PATH: "git@github.com:apirpc/file.git"
BROWSER: "git@github.com:apirpc/path.git"
USE:
XPATH: "class/xpath.py"
TXT_FROM_FILE_PATH: "class/txt_from_file_path.py"
BROWSER: "class/browser.py"
ENV:
XPATH: "docker image"
TXT_FROM_FILE_PATH: "docker image"
BROWSER: "docker image"
API:
FTP:
URI:"ftp://host:21"
AUTH:
PASS: .
USER: .
SET:
URL: https://strato.pl/auth/login.html
PATH_OUT: "/screenshots/"
PATH_IN: "/provider/"
FOLDER_PROVIDER: "strato.pl"
PATH_USER:
- "file://"
- FOLDER_PROVIDER
- "/.user"
PATH_PASS:
- "file://"
- FOLDER_PROVIDER
- "/.pass"
RUN:
BROWSER:
GET: URL
FOCUS:
XPATH: "input.text.login"
WRITE:
TXT_FROM_FILE_PATH: PATH_USER
FOCUS:
XPATH: "input.text.password"
WRITE:
TXT_FROM_FILE_PATH: PATH_PASS
WAIT: 3000
CLICK:
XPATH: "input.mid.button-green-large"
SCREENSHOT:
- MIMETYPE: FILE_FORMAT
- GET: URL
- SIZE: HD
- PATH:
- FOLDER: PATH_SCREENSHOT
- FILE_NAME:
HOST_NAME: URLbrowser.yaml
# INSTALL: wget https://www.apirpc.com/apirpc.py | python
INIT:
RUN: "/apirpc/router.sh"
SET: "/apirpc/config.sh"
IMPORT: "/apirpc/import.sh"
SERVE: "/apirpc/services.sh"
IMPORT:
XPATH:
SOURCE: "git@github.com:apirpc/list.git"
ADAPTER: "python/xpath.py"
DOCKER: "python/DOCKERFILE"
TXT_FROM_FILE_PATH:
GIT: "git@github.com:apirpc/txt_from_file_path.git"
ADAPTER: "nodejs/txt_from_file_path.nodejs"
DOCKER: "nodejs/DOCKERFILE"
BROWSER:
GIT: "git@github.com:apirpc/browser.git"
ADAPTER: "java/browser.java"
DOCKER: "java/DOCKERFILE"
SERVE:
FTP:
URI:"ftp://host:21"
AUTH:
PASS: .
USER: .
SET:
URL: https://strato.pl/auth/login.html
PATH_OUT: "/screenshots/"
PATH_IN: "/provider/"
FOLDER_PROVIDER: "strato.pl"
PATH_USER:
- "file://"
- FOLDER_PROVIDER
- "/.user"
PATH_PASS:
- "file://"
- FOLDER_PROVIDER
- "/.pass"
RUN:
BROWSER:
GET: URL
FOCUS:
XPATH: "input.text.login"
WRITE:
TXT_FROM_FILE_PATH: PATH_USER
FOCUS:
XPATH: "input.text.password"
WRITE:
TXT_FROM_FILE_PATH: PATH_PASS
WAIT: 3000
CLICK:
XPATH: "input.mid.button-green-large"
SCREENSHOT:
- MIMETYPE: FILE_FORMAT
- GET: URL
- SIZE: HD
- PATH:
- FOLDER: PATH_SCREENSHOT
- FILE_NAME:
HOST_NAME: URLbrowser.yaml
# INSTALL: wget https://www.apirpc.com/apirpc.py | python
INIT: "git@github.com:apirpc/apirpc.git"
IMPORT:
XPATH:
SOURCE: "git@github.com:apirpc/list.git"
ADAPTER: "python/xpath.py"
DOCKER: "python/DOCKERFILE"
TXT_FROM_FILE_PATH:
GIT: "git@github.com:apirpc/txt_from_file_path.git"
ADAPTER: "nodejs/txt_from_file_path.nodejs"
DOCKER: "nodejs/DOCKERFILE"
BROWSER:
GIT: "git@github.com:apirpc/browser.git"
ADAPTER: "java/browser.java"
DOCKER: "java/DOCKERFILE"
SCREENSHOT:
GIT: "git@github.com:apirpc/puppetter.git"
ADAPTER: "js/browser.js"
DOCKER: "js/DOCKERFILE"
SET:
URL: https://strato.pl/auth/login.html
PATH_OUT: "/screenshots/"
PATH_IN: "/provider/"
FOLDER_PROVIDER: "strato.pl"
PATH_USER:
- "file://"
- FOLDER_PROVIDER
- "/.user"
PATH_PASS:
- "file://"
- FOLDER_PROVIDER
- "/.pass"
RUN:
BROWSER:
GET: URL
FOCUS:
XPATH: "input.text.login"
WRITE:
TXT_FROM_FILE_PATH: PATH_USER
FOCUS:
XPATH: "input.text.password"
WRITE:
TXT_FROM_FILE_PATH: PATH_PASS
WAIT: 3000
CLICK:
XPATH: "input.mid.button-green-large"
SCREENSHOT:
- MIMETYPE: FILE_FORMAT
- GET: URL
- SIZE: HD
- PATH:
- FOLDER: PATH_SCREENSHOT
- FILE_NAME:
HOST_NAME: URLenvironment_config.yaml
# INSTALL: wget https://www.apirpc.com/apirpc.py | python
INIT: "git@github.com:apirpc/apirpc.git"
IMPORT:
XPATH:
SOURCE: "git@github.com:apirpc/list.git"
ADAPTER: "python/xpath.py"
DOCKER: "python/DOCKERFILE"
TXT_FROM_FILE_PATH:
GIT: "git@github.com:apirpc/txt_from_file_path.git"
ADAPTER: "nodejs/txt_from_file_path.nodejs"
DOCKER: "nodejs/DOCKERFILE"
BROWSER:
GIT: "git@github.com:apirpc/browser.git"
ADAPTER: "java/browser.java"
DOCKER: "java/DOCKERFILE"
SCREENSHOT:
GIT: "git@github.com:apirpc/puppetter.git"
ADAPTER: "js/browser.js"
DOCKER: "js/DOCKERFILE"
SET:
URL: https://strato.pl/auth/login.html
PATH_OUT: "/screenshots/"
PATH_IN: "/provider/"
FOLDER_PROVIDER: "strato.pl"
PATH_USER:
- "file://"
- FOLDER_PROVIDER
- "/.user"
PATH_PASS:
- "file://"
- FOLDER_PROVIDER
- "/.pass"
SERVE:
PORT:
HOST:
PATH:
AUTH:
USER:
PASS:browser_script_run.yaml
BROWSER:
GET: URL
FOCUS:
XPATH: "input.text.login"
WRITE:
TXT_FROM_FILE_PATH: PATH_USER
FOCUS:
XPATH: "input.text.password"
WRITE:
TXT_FROM_FILE_PATH: PATH_PASS
WAIT: 3000
CLICK:
XPATH: "input.mid.button-green-large"
SCREENSHOT:
- MIMETYPE: FILE_FORMAT
- GET: URL
- SIZE: HD
- PATH:
- FOLDER: PATH_SCREENSHOT
- FILE_NAME:
HOST_NAME: URLscript.apirpc
BROWSER GET URL
XPATH SET "input.text.login"
BROWSER FOCUS XPATH
BROWSER WRITE | CONTENT GET FILE | FILE READ PATH_USER
XPATH SET "input.text.password"
BROWSER FOCUS XPATH
BROWSER WRITE | TXT_FROM_FILE_PATH: PATH_PASS
BROWSER WAIT: 3000
BROWSER CLICK | XPATH: "input.mid.button-green-large"
BROWSER SCREENSHOT:
- MIMETYPE: FILE_FORMAT
- GET: URL
- SIZE: HD
- PATH:
- FOLDER: PATH_SCREENSHOT
- FILE_NAME:
HOST_NAME: URL
start script in commmand console or such service on port 24 https://unix.stackexchange.com/questions/314550/how-to-set-a-script-to-execute-when-a-port-receives-a-message#314552
./apirpc script.apirpcdana wyjściowa - komenda - źródło
- CREATE=POST
- UPDATE=PUT
- OCR - image processing
- LIST - internal
- IMAGE - screenshoot
- YAML
- JSON
- TXT
jako format do operacji na sieci CDN
aby łatwo dodawać i odcinać zasoby a także do użycia lokalnie do zasobów, które mają być dostępne dla backendu, np tworzę coś na wzór elastic search dla swoich usług, domen, projektów potrzebuję mieć przegląd biznesu z róznych API, aby móc też na tym budować logikę i strategię z planowaniem decyzji automatycznie dlatego pomyślałem, że tak mógłbym określać zbiory zasobów dodałbym do tego routing lokalnie w pliku i przetwarzał lokalnie w oparciu o własne zasoby lub te zdalne
GET apiRPC :// godaddy.com / domain . json?allpowyżej wywołanie było by przekierowywane do wewnątrz, np do pliku: local/godaddy.com/api.py a dane były by w local/godaddy.com/domain.json chodzi o dostęp do zasobów, które można budować w formie lokalnych wywołań niezależnie od języka programowania i danych aby można było łatwo zbudowac strukturę danych i wywoływać je na frontendzie
w formie np.
http://localhost/godaddy.com/domain.json
czyli
PROTOCOL / HOST / PROVIDER / DATA MODEL / DATA TYPE
- Examples — jsonrpcclient 4.0.0-dev documentation
- explodinglabs/jsonrpcclient: Generate JSON-RPC requests and parse responses in Python
JSON-RPC is a remote procedure call protocol encoded in JSON. It is similar to the XML-RPC protocol, defining only a few data types and commands. JSON-RPC allows for notifications (data sent to the server that does not require a response) and for multiple calls to be sent to the server which may be answered asynchronously.
In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network), which is written as if it were a normal (local) procedure call, without the programmer explicitly writing the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. This is a form of client–server interaction (caller is client, executor is server), typically implemented via a request–response message-passing system. In the object-oriented programming paradigm, RPCs are represented by remote method invocation (RMI). The RPC model implies a level of location transparency, namely that calling procedures are largely the same whether they are local or remote, but usually, they are not identical, so local calls can be distinguished from remote calls. Remote calls are usually orders of magnitude slower and less reliable than local calls, so distinguishing them is important.
RPCs are a form of inter-process communication (IPC), in that different processes have different address spaces: if on the same host machine, they have distinct virtual address spaces, even though the physical address space is the same; while if they are on different hosts, the physical address space is different. Many different (often incompatible) technologies have been used to implement the concept.
Twirp and gRPC gateway are similar. They both build API services out of a protobuf file definition.
Main differences:
- gRPC only uses protobuf over HTTP2, which means browsers can't easily talk directly to gRPC-based services.
- Twirp works over Protobuf and JSON, over HTTP 1.1 and HTTP2, so any client can easily communicate.
- gRPC is a full framework with many features. Very powerful stuff.
- Twirp is tiny and small. Only has a few basic features but it is a lot easier to manage.
reasons for gRPC over Twirp are:
- gRPC supports streaming.
- gRPC makes wire compatibility promises.
- More functionality on the networking level.
By Carl Mastrangelo (Google) | Wednesday, August 15, 2018
So you’ve bought into this whole RPC thing and want to try it out, but aren’t quite sure about Protocol Buffers. Your existing code encodes your own objects, or perhaps you have code that needs a particular encoding. What to do?
Fortunately, gRPC is encoding agnostic! You can still get a lot of the benefits of gRPC without using Protobuf. In this post we’ll go through how to make gRPC work with other encodings and types. Let’s try using JSON.
gRPC is actually a collection of technologies that have high cohesion, rather than a singular, monolithic framework. This means its possible to swap out parts of gRPC and still take advantage of gRPC’s benefits. Gson is a popular library for Java for doing JSON encoding. Let’s remove all the protobuf related things and replace them with Gson:
- Protobuf wire encoding
- Protobuf generated message types
- gRPC generated stub types
- JSON wire encoding
- Gson message types
Previously, Protobuf and gRPC were generating code for us, but we would like to use our own types. Additionally, we are going to be using our own encoding too. Gson allows us to bring our own types in our code, but provides a way of serializing those types into bytes.
This guide gets you started with gRPC in Python with a simple working example.
This guide gets you started with gRPC in Python with a simple working example.
- Python 3.7 or higher
pipversion 9.0.1 or higher
If necessary, upgrade your version of pip:
$ python -m pip install --upgrade pip
If you cannot upgrade pip due to a system-owned installation, you can run the example in a virtualenv:
$ python -m pip install virtualenv
$ virtualenv venv
$ source venv/bin/activate
$ python -m pip install --upgrade pip
Install gRPC:
$ python -m pip install grpcioOr, to install it system wide:
$ sudo python -m pip install grpcioPython’s gRPC tools include the protocol buffer compiler
protocand the special plugin for generating server and client code from.protoservice definitions. For the first part of our quick-start example, we’ve already generated the server and client stubs from helloworld.proto, but you’ll need the tools for the rest of our quick start, as well as later tutorials and your own projects.To install gRPC tools, run:
$ python -m pip install grpcio-tools
There is no reason to oppose both styles as they are not solving the same problems, even though they are both deeply connected with the Web. The figure below represents their main differences.
Both styles are complementary and can be used together, for example when building a single page web application where the main HTML is loaded through a regular web page (REST style), including some JavaScript (code on demand constraint). This code is then interpreted by the web browser to make AJAX calls back to a Web API, exchanging predefined JSON representations.
Let’s also mention hyperdata as a second form of hypermedia with hypertext, that also offers a comprehensive application of REST. This is the world of the Semantic Web and especially the pragmatic Linked Data movement based on RDF and related media types such as Turtle, JSON-LD or HAL.
In other situations, where the client isn’t a web browser but a native mobile app, a connected device or a program written by a partner to integrate your web site with their own, you only rely on the Web API style, which is fine again. Let’s now step back and see where these new forms of web architectures will lead us.