Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

63 Commits
 
 
 
 
 
 
 
 

Repository files navigation

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.

TODO

  • 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

Inspiracja

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 }

źródło

local file

LIST READ file://domain.txt

or

LIST GET file://domain.txt

Read remote file plik domain.txt zawiera listę adresów URL

LIST GET https://domena.com/domain.txt

file processing

pobierz adres URL z listy LIST

URL FIRST LIST

stwórz screenshoot z adresu URL elementu z listy LIST

IMAGE SCREENSHOT URL

konfiguracja Zapisz do lokalnego pliku o nazwie hosta w formacie PNG

IMAGE FILENAME | HOSTNAME FROM URL
IMAGE MIMETYPE PNG

Zapisz screenshot do folderu i nazwie pliku wczesniej zdefiniowanego

URL FIRST LIST
IMAGE SCREENSHOT URL
FILE PATH_FOLDER file://screenshots/
FILE CONTENT IMAGE
LOG FROM FILE

wnioski

wszelkie 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 FILE
PATH_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 FILE
PATH_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 FILE
PATH_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: FILE
PATH_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: FILE
IMPORT:
    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: PNG
IMPORT:
    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: HD
IMPORT:
    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            

Start

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 FILE

stara wersja:

ITEM 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.txt

bot 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.png

Wykonanie kodu poprzez skrypt z domyślnymi danymi:

./apirpc browser.yaml

lub 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: URL

browser.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: URL

browser.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: URL

environment_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: URL

script.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.apirpc

format danych

dana wyjściowa - komenda - źródło

FILESYSTEM=HTTP alias Commands:

  • CREATE=POST
  • UPDATE=PUT

INTERNAL Commands:

  • OCR - image processing

Data types:

  • 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?all

powyż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

JSON-RPC - Wikipedia

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.

gRPC + JSON

By Carl Mastrangelo (Google) | Wednesday, August 15, 2018

Contents

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.

Contents

Quick start

This guide gets you started with gRPC in Python with a simple working example.

Prerequisites

  • Python 3.7 or higher
  • pip version 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

gRPC

Install gRPC:

$ python -m pip install grpcio

Or, to install it system wide:

$ sudo python -m pip install grpcio

gRPC tools

Python’s gRPC tools include the protocol buffer compiler protoc and the special plugin for generating server and client code from .proto service 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.

7. Comparison with RPC

Releases

Packages

Contributors