Poprzednia dekada przyniosła programistom rozkwit narządzi typu "bundler".  W okolicach roku 2010 można było jeszcze spotkać, że pliki strony czy appek webowych były przygotowywane ręcznie przez programistów na produkcje.  W roku 2021 żaden chyba profesjonalny developer nie robi manualnie takich procesów jak minimalizacja js, css, konwertowanie js w es6 na es5 czy innych transformacji związanych w tworzeniu tak zwanego "bundle" produkcyjnego.  

Narzędzia takie jak grunt, gulp przyczyniły się do rozwoju obecnie chyba najbardziej wykorzystywanego "bundlera" czyli webpack'a. Webpack i familia  to naprawdę potężna i dobrze działająca machina. Na pewno dobry wybór nawet i do corporate level app, z dobrą dokumentacją oraz bardzo dużym ekosystemem.

Webpack jako "stary wół" jest jednak czasem dość powolny, następne iteracje webpacka wydają się nie wpływać na jego performance, a wręcz przeciwnie jego performance spada tak  jak to sugeruje  strona główna esbuild.

Enter the esbuild

Natrafiłem na esbuild'a już jakiś czas temu, nowej generacji "bundler" o "niesamowitych" osiągach.  Jako że w tamtym czasie był dopiero na początku swojej drogi, nie poświeciłem mu zbytnio dużo czasu.  Pracując ostatnio nad optymalizacją buildu (webpack), w konfiguracji loadera plików ts podmieniłem ts-loader na esbuild-loader, 40%-50% szybszy build time okazał się dużym zaskoczeniem.

Zachęcony wynikami, postanowiłem sprawdzić czy da rade porzucić webpacka na esbuild i jak rożni się praca pomiędzy młodym zawodnikiem (esbuild) a wysłużonym weteranem (webpack v5).

Na cel objąłem full stackowy setup node.js (express) + react.

Pierwsze kroki przygotowania bundle poszły dość bezproblemowo, dość ogarnięta dokumentacja esbuilda pomaga. Esbuild integruje się z TS bez zbędnych pluginów, works out of the box wraz z pobieraniem aliasów z tsconfig.json (np @components)

const { build } = require('esbuild');
const fs = require('fs-extra');
const postCss = require('esbuild-plugin-postcss2').default;
const autoprefixer = require('autoprefixer');
const tailwindcss = require('tailwindcss');

const generateBuild = async () => {
  await fs.rmdirSync('./build/public/static', { recursive: true });

  await build({
    // Bundles JavaScript.
    bundle: true,
    sourcemap: true,
    loader: { '.svg': 'dataurl', '.png': 'dataurl' },
    // Defines env variables for bundled JavaScript; here `process.env.NODE_ENV`
    // is propagated with a fallback.
    define: {
      'process.env.NODE_ENV': JSON.stringify(
        process.env.NODE_ENV || 'development',
      ),
    },
    // Bundles JavaScript from (see `outfile`).
    entryPoints: ['./src/client/index.tsx'],
    // Uses incremental compilation (see `chokidar.on`).
    incremental: true,
    // Removes whitespace, etc. depending on `NODE_ENV=...`.
    minify: true,
    // Bundles JavaScript to (see `entryPoints`).
    outdir: './build/static/',
    plugins: [
      postCss({
        plugins: [autoprefixer, tailwindcss],
      }),
    ],
  }).catch(() => process.exit(1));

  process.exit(0);
};

generateBuild();

(async () => {
  // `esbuild` bundler for JavaScript / TypeScript.
  await build({
    // Bundles JavaScript.
    bundle: true,
    sourcemap: false,
    // set platform for node, default is browser
    platform: 'node',
    loader: { '.svg': 'dataurl', '.png': 'dataurl' },
    // Defines env variables for bundled JavaScript; here `process.env.NODE_ENV`
    // is propagated with a fallback.
    define: {
      'process.env.NODE_ENV': JSON.stringify(
        process.env.NODE_ENV || 'Production',
      ),
    },
    // Bundles JavaScript from (see `outfile`).
    entryPoints: ['./src/server/index.ts'],
    // Uses incremental compilation (see `chokidar.on`).
    incremental: true,
    // Removes whitespace, etc. depending on `NODE_ENV=...`.
    minify: true,
    // Bundles JavaScript to (see `entryPoints`).
    outdir: './build/',
  }).catch(() => process.exit(1));

  process.exit(0);
})();

Webpack-dev-server ?

Ale praca "na projekcie" to nie sam build, o ile nodemon w sprawie serwera daje sobie  spokojnie radę, to pytanie co z HMR, Live relead dla Reacta ? Esbuild może jest i szybki,  ale żaden z devów nie chce klikać refresh co chwilę, dodatkowo gubiąc stan komponentów.

Niestety brakuje esbuildowi rozsądnego rozwiązania czy pluginu z community w temacie live developmentu, na pewno brakuje tutaj jakieś wskazówki, "oficjalnej" konkretnej ścieżki jak można by było osiągnąć hot refreash, ja w końcu zdecydowałem się na bibliotekę "servor", rozgrzewa się na pewno trochę dłużej niż webpack-dev-server ale zdaje egzamin w  sprawie live reloadu.

lukejacksonn/servor

Dependency free file server for single page app development - lukejacksonn/servor

lukejacksonnGitHub

esbuild jest na razie bardzo eksperymentalnym projektem, z bardzo ograniczonym ekosystemem pluginów.  Brakuje mu dużo stabilności i dojrzałości, jest jednak nadzieja na nowej generacji bundler, który jeszcze bardziej przyczyni się do poprawy wydajności pracy programisty w przyszłości.

Do tego czasu, na razie proponuje jednak spróbować esbuild-loader w  waszych ustawieniach webpacka.

Przykładowe repo z ustawieniem esbuild only

MassivDash/typescript-react-express-esbuild

Express.js + React + Typescript + Esbuild + tailwindCss - MassivDash/typescript-react-express-esbuild

MassivDashGitHub

Ostatnio coraz bardziej przekonuje się do nowego javascript frameworka svelte.js (więcej o tym możecie przeczytać na moim blogu, tutaj).

W ramach ćwiczeń i ekspolracji tego nowego narzędzia postanowiłem zrobić mini apkę. Jestem zagorzałem fanem gry w szachy, za młodu próbowałem nawet swoich sił w szelakich turniejach, co zawsze będzie mi się kojarzyło z bardziej profesjonalną grą, to zegar szachowy.

I właśnie taki zegar szachowy postanowiłem przenieść na świat wirtualny. Praca z apką przy użyciu svelte była dla mnie czystą radością. Myśle że ten framework ma dużo do zaferowania pod względem trzymania stanu czy reaktywności komponetów, do tego oferując bardzo dobry performance.

Co według mnie potrzebuje dobry zegar szachowy ? Po pierwsze nie zależny system timerów, często podczas ćwiczeń z lepszymi zawodnikami, ustawiali sobie oni mniej czasu, gra pod presją czasową to zupełnia inna gra w szachy. Tarcze timerów maja możliwość obrotu dając możliwość położenia telefonu obok szachownicy tak aby obydwaj gracze mogli widzieć swój czas. Zmiana tury odbywa sie poprzez dotknięcie tarczy zegara gracza.

Zachecam do korzystania, apka totalnie za free, zero trackerów ani tego typu podobnych rzeczy. Powodzenia w przyszłych grach.

Apka znajduje się tutaj: https://chess-timer.spaceout.pl/

Repo:  https://github.com/MassivDash/Svelte-Chess-Timer

Aplikacja progresywna (progreessive application) to nowy typ aplikacji mocno wspierany przez Google. W założeniu serviceworker.js, skypt oparty na java scriptcie tworzy specjalny gateway, "program" który ma się stać mostem pomiędzy aplikacją w trybie online i offline.

Do tej pory istniały głównie dwa podejścia do budowy aplikacji webowych i mobilnych. Wersja online czyli typowe aplikacja internetowa (netflix, facebook) oraz aplikacje offline (którą trzeba wcześniej ściągnąć).

Tutaj wchodzi service worker i daje 2 dodatkowe możliwości rozwoju aplikacji; Online first oraz offline first, oraz duże możliwości zarządzaniem cache naszej strony / aplikacji.

Możemy przechwytywać żądania użytkownika, zmusić przeglądarkę aby ściągnęła i zachowała treści i zdjęcia. Dodatkowo ustalać zasady dotyczące priorytetu treści online / offline. Service worker odpowiednio skonfigurowany pomoże także w sytuacji "lie-fi" (dobry zasięg a jednak sie nie otwiera ... )

Warto zaznaczyć że jak narazie service worker jest obsługiwany tylko przeglądarkę Chrome (Web / Android), dodatkowym wymogiem jest protokół HTTPS.

Jak to działa ?

W praktyce nasza strona internetowa może zostać pełnoprawną ikonką w momencie otworzenia przez urządzenia mobilne.

Po wejściu w naszą aplikację progresywną, pojawia się wcześniej ustalony splashscreen. Stronę / aplikację możemy pokazywać w wybranej formie: standalone (full screen), Web browser. Ustalić orientację ekranu itp ...

Co najważniejsze i najfajniejsze w tym wszytskim ?

Nasza strona działa w trybie offline na komórki i na komputerze.

Service Worker

Rejestracja serviceworker.js na index.html / index.js
Typowa rejestracja serviceworker następuje przez umieszczenie następującego js scriptu;

if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
  });
}

Przyklad prostego service workera do pracy w trybie offline;

"use strict";

console.log('WORKER: executing.');

/* Numer wersji może się okazać pomocny podczas updatu naszego service workera. 
*/
var version = 'v1::';

/* Poniższe zasoby będą ściągane podczas instalacji naszej progresywnej appki na komputer czy komórkę. Jeżeli coś się nie powiedzie, service worker nie zostanie zainstalowany.
*/
var offlineFundamentals = [
  '',
  '/assets/css/style.css',
  '/assets/js/global.js'
];

/*  Instalacja zostanie rozpoczęta, gdy serviceworker.js zostanie najpierw zainstalowany. Możesz użyć "event listener", aby przygotować sw.js do obsługi
   plików, gdy odwiedzający są w trybie offline.
*/
self.addEventListener("install", function(event) {
  console.log('WORKER: install event in progress.');
  /* Użycie event.waitUntil(p) blokuje instalacje na poniższym "promise" czyli 
     asychonicznym wezwaniu. Jeżeli "promise" zostanie odrzucony, service worker nie będzie zainstalowany.
  */
  event.waitUntil(
    /* Wbudowany API "Cache" oparty na "promise" pomaga w cachowaniu odpowiedzi, znajdowaniu i usuwaniu plików.
    */
    caches
      /* To pozwala aby otwierac cache po nazwie, ta metoda także zwraca "promise". Możemy używać "versioned cache name", przypisanej nazwy cache aby poźniej pozbywac się starszych wpisów / "entries" z cache'u, kiedy będziemy wprowadzać nowego service workera. 
      */
      .open(version + 'fundamentals')
      .then(function(cache) {
        /* Po otworzeniu cache, możemy go uzupełnić z zapisanymi wcześniej "offline fundamentals".
        */
        return cache.addAll(offlineFundamentals);
      })
      .then(function() {
        console.log('WORKER: install completed');
      })
  );
});

/* Zdarzenie pobierania jest wywoływane za każdym razem, gdy strona kontrolowana przez tego serviceworker.js żada zasoby (request) zasób. Nie jest to tylko  ograniczone do żądania  `fetch` lub nawet XMLHttpRequest, ale nawet do request'u strony HTML przy pierwszym załadowaniu, plików JS, CSS, fontów czy obrazów itp.
*/
self.addEventListener("fetch", function(event) {
  console.log('WORKER: fetch event in progress.');

  /* Powinnismy cacho'wac tylko "GET request", resztą niech zajmie się przeglądarka poprzez zarządzanie (handling) nieudanymi requestów "POST,PUT,PATCH, itp".
  */
  if (event.request.method !== 'GET') {
    /* 
Jeśli nie zablokujemy zdarzenia, jak pokazano poniżej, żądanie zostanie wysłane przez sieć jak zwykle.
    */
    console.log('WORKER: fetch event ignored.', event.request.method, event.request.url);
    return;
  }
  /* Podobnie jak "event.waitUntil", blokujemy zdarzenie pobierania na "promise" 
     Wynik realizacji zostanie użyty jako odpowiedź, a odrzucenie zakończy się na
     Odpowiedzi (http) informująca o awarii.
  */
  event.respondWith(
    caches
      /* 
Ta metoda zwraca "promise", która rozwiązuje problem z dopasowaniem wpisu pamięci podręcznej (cache) do naszego request'u. Gdy "promise" zostanie spełniony, będziemy mogli udzielić odpowiedzi na żądanie pobrania.
      */
      
      .match(event.request)
      .then(function(cached) {

/* Nawet jeśli odpowiedź znajduje się w naszej pamięci podręcznej, robimy wezwanie także do do sieci. Ten wzorzec jest znany z wywoływania "świeżych" reakcji,gdzie natychmiast zwracamy buforowane odpowiedzi, a tymczasem ciągniemy odpowiedź sieciowa i zapisz ją w pamięci podręcznej.
*/
        var networked = fetch(event.request)
          // We handle the network request with success and failure scenarios.
          .then(fetchedFromNetwork, unableToResolve)
          // We should catch errors on the fetchedFromNetwork handler as well.
          .catch(unableToResolve);

        /* We return the cached response immediately if there is one, and fall
           back to waiting on the network as usual.
        */
        console.log('WORKER: fetch event', cached ? '(cached)' : '(network)', event.request.url);
        return cached || networked;

        function fetchedFromNetwork(response) {
        
/* Klonujemy  "response". To jest odpowiedź, która będzie przechowywana w pamięci podręcznej ServiceWorker. */

          var cacheCopy = response.clone();

          console.log('WORKER: fetch response from network.', event.request.url);

          caches
            //Otwieramy pamięć podręczną, aby zapisać odpowiedź na to żądanie. 
            
            .open(version + 'pages')
            .then(function add(cache) {
            
              /* Przechowujemy odpowiedź na to żądanie. Później ta odpowiedz będzie  dostępna dla wywołań caches.match (event.request) podczas wyszukiwania zbuforowanych odpowiedzi. 
              */
              return cache.put(event.request, cacheCopy);
            })
            .then(function() {
              console.log('WORKER: fetch response stored in cache.', event.request.url);
            });

          // Zwróć odpowiedź, aby obietnica została spełniona.
          return response;
        }

        /* Gdy wywoływana jest ta metoda, oznacza to, że nie jesteśmy w stanie wytworzyć odpowiedzi z pamięci podręcznej lub sieci. Dobra okazja do wyświetlenia jakies wiadomosci jeżeli wszystko inne zawiedzie. Typu "Usługa niedostępna" lub ogólna wiadomość błędu.
        */
        function unableToResolve () {
       

          console.log('WORKER: fetch request failed in both cache and network.');

          /* Tutaj programujemy odpowiedź. Pierwszym parametrem jest
             treść odpowiedzi, a druga określa opcje odpowiedzi.
          */
          
          return new Response('<h1>Service Unavailable</h1>', {
            status: 503,
            statusText: 'Service Unavailable',
            headers: new Headers({
              'Content-Type': 'text/html'
            })
          });
        }
      })
  );
});

/* Zdarzenie activate uruchamia się po pomyślnym zainstalowaniu modułu serwisowego.
Jest to najbardziej przydatne przy wycofywaniu starszej wersji, jeżeli serviceworker.js został zainstalowany poprawnie. W tym przykładzie usuwamy stare pamięci podręczne, które nie pasują do wersji w właśnie zakończonym procesie instalacyjnym.
*/
self.addEventListener("activate", function(event) {
  /* Podobnie jak w przypadku instalacji, event.waitUntil aktywuje się na "promise".  Aktywacja zakończy się niepowodzeniem, dopóki "promise" nie zostanie spełniony.
  */
  console.log('WORKER: activate event in progress.');

  event.waitUntil(
    caches
      /* 
Ta metoda zwraca obietnicę, która rozwiąże "array"" dostępnych
         kluczy pamięci podręcznej
      */
      .keys()
      .then(function (keys) {
        // Zwracamy "promise", która "settle"  się po usunięciu wszystkich nieaktualnych pamięci podręcznych. 
        return Promise.all(
          keys
            .filter(function (key) {
              //Filtruj według kluczy, które nie rozpoczynają się od prefiksu najnowszej wersji.
              return !key.startsWith(version);
            })
            .map(function (key) {
              /* Zwróc "promise" która zostala spelniona po tym jak przestarzaly cache zostal zwrocony.
              */
              return caches.delete(key);
            })
        );
      })
      .then(function() {
        console.log('WORKER: activate completed.');
      })
  );
});

Więcej informacji na temat serviceworker.js:

https://developers.google.com/web/fundamentals/codelabs/

https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

Jeżeli do waszych Reactowych aplikacji podłączaliście niezliczone dodatkowe moduły takie jak serwery (express, koa), klientów lub serwery apollo, konfiguracje webpacka, pisaliście funkcje SSR (sever side render), oraz łączyliście to w całość, to na pewno zdajecie sobie sprawę z czasochłonności całego tego procesu. Gatsby.js może okazać się rozwiązaniem na te wszystkie problemy.

Development

Gatbsy.js to głównie React, Webpack i GraphQL, jeżeli znacie ten stack to właściwe cały system stoi przed was otworem, z automatu mamy dostęp do pisania (develop) w trybie Hot Module Reloading ( ten tryb jednak wymaga czasami restartu) i budowy plików statycznych. Piszemy w react'cie normlanie, dostraczamy dane lub treść za pomocą GraphQL, webpack nam to wszytsko \"bundeluje\" do kupy i tak w ten sposób mam prawie gotowy produkt.

Gatsby zdobył już ogromną popularność i posiada wiele gotowych rozwiązań, ekosystem pluginów jest naprawdę duży. SASS, LESS, CSS Inline, PWA - Offline,Css modules, transformer-remark, gatsby sharp image, tego wszystkiego jest naprawdę dużo. Oficjalna lista pluginów na https://www.gatsbyjs.org/plugins/.

To właśnie ten ekosystem gotowych rozwiązań skusił mnie najbardziej do zastosowania gatsby.js w komercyjnych projektach. Dość szybka implementacja wszystkich niezbędnych funkcji aplikacj React, zautomatyzowaniu procesu podłączenia (service.worker.js) Proggressive Web App, super szybkich przejść pomiędzy stronami (pre-fetch, za pomocą \"native\" gatsby-router-link) oraz wielu innym gotowym rozwiązaniom sprawił, że zakochałem się w tym systemie tworzenia stron internetowych. Jest on kompilacją wszystkich moich ulubionych narzędzi, jakich używałam wcześniej, ale teraz nie muszę się nimi opiekować i aktualizować na bieżąco.\

Muszę też przyznać, że dokumentacja techniczna jest dość dobrze i przejrzyście zorganizowana. I wszystko dział, jak trzeba. Nie doświadczyłem większych problemów przy tworzeniu aplikacji webowych w ten sposób. Z szybkich rad mogę tylko zwrócić uwagę na to, że przy stosowaniu css modules, pliki muszą mieć końcówke cośtam.modules.css (lub .scss). W wersji developerskiej plik bez koncówki \"modules\" działa zaś przy wersji produkcyjnej nie. Spędziłem trochę czasu zanim wychwyciłem o co chodzi.

Gatsby produkuje pliki statyczne, ale czy to znaczy, że możemy je wcisnąć na każdy serwer hostingowy, jaki jest dostępny w Polsce ? Polecałbym zastosowanie serwera z silnikiem node.js. Jednakże wszytsko także zależy od pluginów i naszej strony. Może okazać się, że zwykła strona na gatsby, pojdzie na każdy serwerze.\n\nSam stawiając stronę wybrałem operatora https://netlify.com. Możemy na nim postawić \"mniejszą\" stronę za darmo (do 100 000 wejśc w mieśiącu) wraz z certyfikatem SSL( za darmo Let's Encrypt), oraz możliwą integracją z ich dość prostym system CMS, Netlify CMS. To dość prosty panel do obsługi treści, będzię wymagał od nas konfiguracji, zrobienia podglądu wpisów. Działa on zasadzie edycji projektu przez wersji GIT, a dokładnie na edycji plików markdown, które są jednym ze sposobów dostarczania treści w frameworku Gatsby.

Jednakże, dlatego że GraphQL jest głównym silnikiem treści w Gatsby.js, mamy dowolność w podłączaniu jakichkolwiek danych, jakie będą nam potrzebne, z automatu mamy dostęp do pluginów, które pomagają połączyć się z Wordpressem, Drupal, GraphCMS, itd.

Beyond Static

Warto zauważyć, że pomimo tego, iż jest to generator stron statycznych, nasza aplikacja nie musi być statyczna, co często chyba się zdarzać mysleć deweloperom.\nCiągle możemy zstosować gatsby.js do sklepów, czatów ... i bardziej dynamicznych aplikacji. Ciągle mamy dostęp do wszystkich component life cycles w React. Musimy wtedy dostarczyć baze pod aplikacje, a resztę doładujemy w Component Did Mount na bieżąco. Jednakże ze względu na SEO, musimy pamiętać że ta dynamiczna treśc nie będzie czytna przez roboty i crawlery.

Produkt końcowy i szybkość\nGatsby.js urzeka szczególnie swoją prostotą obsługi oraz tym, że za pomocą dużego systemu pluginów skraca pracę deweloperom. Może się okazać bardzo cennym narzędziem nawet przy budowie dużych aplikacji webowych.\n\nGatsby.js chwali się swoją zawrotną szybkością i jest ona rzeczywiście odczuwalna, szczególnie przy ładowaniu czy nawigowaniu stron aplikacji. Nie znaczy to jednak, że z automatu osiągniemy wynik 100 / 100 w Google Page Speed Insights. Nad tym wynikiem będziemy musieli sami pracować, używając własnych narzędzi lub niektórych z pluginów gatsby (Uncss, Css-inline, Gatsby-Image).

Jeżeli lubicie pracować z React.js, a chcielibyście sobie skrócić czas robienia aplikacji webowych to gorąco polecam gatsby.js. Na moim koncie w github, znajdziecie parę projektów zbudowanych o gatsby.js wraz z mini starterem gatsby.js z trochę większa ilością pluginów niż tzw golas.

docker build

docker build [options] .
  -t "app/container_name"    # name

Stwórz image z pliku Dockerfile.

docker run

docker run [options] IMAGE
  # see `docker create` for options

Zarządzanie konetnerami

docker create

docker create [options] IMAGE
  -a, --attach               # attach stdout/err
  -i, --interactive          # attach stdin (interactive)
  -t, --tty                  # pseudo-tty
      --name NAME            # name your image
  -p, --publish 5000:5000    # port map
      --expose 5432          # expose a port to linked containers
  -P, --publish-all          # publish all ports
      --link container:alias # linking
  -v, --volume `pwd`:/app    # mount (absolute paths needed)
  -e, --env NAME=hello       # env vars

Przykład

Stwórz container z image.

$ docker create --name app_redis_1 \
  --expose 6379 \
  redis:3.0.2

docker exec

docker exec [options] CONTAINER COMMAND
  -d, --detach        # run in background
  -i, --interactive   # stdin
  -t, --tty           # interactive

Przykład

Komendy w container.

$ docker exec app_web_1 tail logs/development.log
$ docker exec -t -i app_web_1 rails c

Start/stop a container.

docker start

docker start [options] CONTAINER
  -a, --attach        # attach stdout/err
  -i, --interactive   # attach stdin

docker stop [options] CONTAINER

Zarządzanie container przy pomocy ps/kill.

docker ps

$ docker ps
$ docker ps -a
$ docker kill $ID

Obrazy

Zarządzanie image

docker images

$ docker images
  REPOSITORY   TAG        ID
  ubuntu       12.10      b750fe78269d
  me/myapp     latest     7b2431a8d968

$ docker images -a   # also show intermediate

Kasowanie image

docker rmi

docker rmi b750fe78269d

Zobacz także

• Getting Started (docker.io)

Dockerfile

Inheritance

FROM ruby:2.2.2

Variables

ENV APP_HOME /myapp
RUN mkdir $APP_HOME

Initialization

RUN bundle install

WORKDIR /myapp

VOLUME ["/data"]
# Specification for mount point

ADD file.xyz /file.xyz
COPY --chown=user:group host_file.xyz /path/container_file.xyz

Onbuild

ONBUILD RUN bundle install
# when used with another file

Commands

EXPOSE 5900
CMD    ["bundle", "exec", "rails", "server"]

Entrypoint

ENTRYPOINT ["executable", "param1", "param2"]
ENTRYPOINT command param1 param2

Konfiguruje kontener, który będzie działał jako plik wykonywalny.

ENTRYPOINT exec top -b

Spowoduje to użycie przetwarzania powłoki do podstawienia zmiennych powłoki i zignoruje wszelkie argumenty wiersza poleceń uruchamiane przezCMD lub docker run

Metadata

LABEL version="1.0"

LABEL "com.example.vendor"="ACME Incorporated"
LABEL com.example.label-with-value="foo"

LABEL description="This text illustrates \
that label-values can span multiple lines."

Zobacz także

• https://docs.docker.com/engine/reference/builder/

docker-compose

Podstawowy przykład

# docker-compose.yml
version: '2'

services:
  web:
    build: .
    # build from Dockerfile
    context: ./Path
    dockerfile: Dockerfile
    ports:
     - "5000:5000"
    volumes:
     - .:/code
  redis:
    image: redis

Komendy

docker-compose start
docker-compose stop

docker-compose pause
docker-compose unpause

docker-compose ps
docker-compose up
docker-compose down

Referencje

Budowa

web:
  # build from Dockerfile
  build: .

  # build from custom Dockerfile
  build:
    context: ./dir
    dockerfile: Dockerfile.dev

  # build from image
  image: ubuntu
  image: ubuntu:14.04
  image: tutum/influxdb
  image: example-registry:4000/postgresql
  image: a4bc65fd

Porty

  ports:
    - "3000"
    - "8000:80"  # guest:host

  # expose ports to linked services (not to host)
  expose: ["3000"]

Komeny

  # command to execute
  command: bundle exec thin -p 3000
  command: [bundle, exec, thin, -p, 3000]

  # override the entrypoint
  entrypoint: /app/start.sh
  entrypoint: [php, -d, vendor/bin/phpunit]

Zmienne środowiskowe

  # environment vars
  environment:
    RACK_ENV: development
  environment:
    - RACK_ENV=development

  # environment vars from file
  env_file: .env
  env_file: [.env, .development.env]

Zależności / Dependencies

  # makes the `db` service available as the hostname `database`
  # (implies depends_on)
  links:
    - db:database
    - redis

  # make sure `db` is alive before starting
  depends_on:
    - db

Inne opcje

  # make this service extend another
  extends:
    file: common.yml  # optional
    service: webapp

  volumes:
    - /var/lib/mysql
    - ./_data:/var/lib/mysql

Opcje zawansowane

Labels

services:
  web:
    labels:
      com.example.description: "Accounting web app"

DNS servers

services:
  web:
    dns: 8.8.8.8
    dns:
      - 8.8.8.8
      - 8.8.4.4

Devices

services:
  web:
    devices:
    - "/dev/ttyUSB0:/dev/ttyUSB0"

External links

services:
  web:
    external_links:
      - redis_1
      - project_db_1:mysql

Hosts

services:
  web:
    extra_hosts:
      - "somehost:192.168.1.100"

Serwisy

Sprawdź wszytskie serwisy

docker service ls 

Aby zobaczyć wszystkie uruchomione usługi wraz z zaawansowanymi funkcjami

docker stack services stack_name

wszytskie logi

docker service logs stack_name service_name 

Aby szybko skalować usługi w kwalifikowanym węźle

docker service scale stack_name_service_name=replicas

clean up

Skasuj nie używane obrazy

docker image prune 

Skasuj wszystkie obrazy, które nie są używane w kontenerach

docker image prune -a 

Wyczyść system

docker system prune 

Wyjdz z ze swarm'a

docker swarm leave  

Usuń cały swarm wraz z całymi wolumenami i bazami danych

docker stack rm stack_name  

Zniszcz (kill) wszystkie kontenery

docker kill $(docekr ps -q ) 

Jeżeli używacie centos 8 i macie problem z podłączeniem swoich słuchwek bluetooth, poniższa konfiguracja powinna działać na każdym systemie linuks, który posiada gnome-bluetooth

sudo nano /etc/bluetooth/audio.conf

oraz dodać poniższy config

[General]
Disable=Socket
Disable=Headset
Enable=Media,Source,Sink,Gateway
AutoConnect=true
load-module module-switch-on-connect

Następnie zedytować  /etc/bluetooth/main.conf na lini

# Restricts all controllers to the specified transport. Default value
# is "dual", i.e. both BR/EDR and LE enabled (when supported by the HW).
# Possible values: "dual", "bredr", "le"
ControllerMode = bredr

Aby właczyć auto łączenie systemu zedytuj linie

# AutoEnable defines option to enable all controllers when they are found. 
# This includes adapters present on start as well as adapters that are plugged 
# in later on. Defaults to 'false'. 
AutoEnable=true

Teraz reboot systemu i połaczyć się po raz pierwszy ze słuchawkami

Jak szybko stworzyć własne CLI, które przyda nam się przy naszych codziennych zadaniach ? Odpowiedź to inquire.js (i dobry pomysł na nasze CLI).

W większości nowych instalacjach np. Gatsby.js czy Ghost.js,  mamy już gotowe implementacje modułu optymalizacji zdjęć i nie musimy się tym przejmować po za początkową konfiguracją. Jednakże moje starsze instalacje albo wordpressy nie mają tego szczęścia.

Mój problem był dość prosty, od czasu do czasu potrzebowałem narzędzia, które uruchomię na dowolnym folderze, które pozwoliło by mi szybko, bez bólu i bez pamiętania konfiguracji, komend, itp. przyciąć, zoptymalizować lub zmienić format zdjęć, które znajdują się wybranym folderze.

Szukając gotowych rozwiązań, upewniłem się tylko w przekonaniu, że nie ma nic na internecie co by sprostało moim wymaganiom, szczególnie jeżeli chodzi możliwość optymalizacji całego folderu i swego rodzaju UX całej operacji. Większość tools'ów wymaga dodatkowych argumentów, opcji do wpisania wraz z komendą, co powoduję, że za każdym razem muszę przeglądać dokumentacje w poszukiwaniu właściwej konfiguracji.

Tak zrodził się pomysł na mały program, który nazwałem Sharp Machine. Zdecydowałem się na lovell/sharp:

"High performance Node.js image processing, the fastest module to resize JPEG, PNG, WebP and TIFF images. Uses the libvips library."

ze względu na jego szybkość i znajomość biblioteki (Gatsby.js korzysta z sharpa'a).

Budowa własnego CLI

Budowa własnego CLI, okazała się dobra zabawą dzięki gotowym rozwiązaniom dostępnym w internecie. Szczególnie, mogę pochwalić bibliotekę Inquirer.js, która czyni tworzenie interaktywnych pytań i uzyskiwanie odpowiedzi od użytkownika dość trywialnym procederem.

index.js

const inquirer  = require('./libs/inquirer');

const run = async () => {
 const location = await inquirer.askInputQuestions(); 
};

run(); 

inquirer.js

const inquirer = require('inquirer');

module.exports = {
  askInputQuestions: () => {
    const questions = [
      {
        name: 'inputDir',
        type: 'input',
        message: 'Enter input directory (type . for current folder): ',
        validate: function( value ) {
          if (value.length) {
            return true;
          } else {
            return 'Gotta type in something';
          }
        }
      },
      {
        name: 'outputDir',
        type: 'input',
        message: 'Enter output directory :',
        validate: function(value) {
          if (value.length) {
            return true;
          } else {
            return 'Please Enter output directory';
          }
        }
      }
    ];
    return inquirer.prompt(questions);
  },
};

Po uruchomieniu programu i odpowiedzeniu na przygotowane pytania. W naszej zmiennej location przechowywane są odpowiedzi użytkownika. Na ich podstawie zadajemy kolejne pytania lub uruchamiamy odpowiednie procesy. W moim przypadku jest to sprawdzenie podanego folderu pod kątem obecności zdjęć oraz dalsze operacje i pytania o zadania dla modułu sharp. Inquirer.js posiada w swoim api, pytania; input, list, checkbox, expand, ... oraz editor. Ta ostatnia opcja okazała się doskonałym rozwiązaniem dla stworzenia custom configu do Sharp Machine. Ten typ pytania powoduje otwarcie ulubionego edytora tekstu oraz możliwość edycji pełnego obiektu konfiguracyjnego, które sprawia, że łatwo dostosować sharp machine do swoich potrzeb.

Do dalszych prac na interfejsem swojego CLI wykorzystałem:  

• Chalk.js: daje możliwość ostylowania naszych wiadomości pokazywanych w konsoli.
• Figlet.js: daje możliwość zrobienia consolowego splash screena / tytułu naszego programu CLI
• Clui.js: daje możliwość dołączenia spinnera, progress bar'a  podczas operacji CLI

Sharp Machine został przemyślany jako moduł  do pracy globalnej, aby upewnić się, że nasz moduł będzie odpowiednio działać, warto pamiętać aby dodać do index.js (na samej górze pliku)

#!/usr/bin/env node

oraz do pliku package.json

  "bin": {
    "nazwa_naszego_pakietu": "./index.js"
  }

Tworzenie własnego CLI to dobre ćwiczenie do pracy z czystym node.js oraz asynchronicznymi działaniami. Polecam dla każdego kto uwielbia zabawy i pracę z node konsolą.    

Pełne źródło SharpMachine na githubie lub do przetestowania samemu

npm i -g sharpmachine
sharpmachine

Pozdrawiam

Krąży wiele żartów po sieci, że prawie codziennie powstaje nowy framework JS. Mamy już święta trójce współczesnego frontendu;  Reacta, Angular i Vue oraz wiele wiele innych.

Do grona najlepszych ma zamiar dołączyć Svelte.js jednak w przeciwieństwie do Reacta, svelte.js nie używa techniki podmiany prawdziwego DOM z tym wirtualnym a metody kompilacji możliwych zmian w aplikacji o wstrzykiwaniu go bezpośrednio do kodu strony podczas budowy aplikacji.

Twórcy svelte.js przekonują, że używanie metody wirtualnego DOMu jest nie efektywne oraz wręcz nie potrzebne.

Więc ... czy wirtualny DOM jest wolny?

„Wirtualny DOM jest zwykle wystarczająco szybki”, ale z pewnymi zastrzeżeniami.

Tradycyjne frameworki umożliwiają pisanie deklaratywnego kodu sterowanego stanem, ale istnieje kara: przeglądarka musi wykonać dodatkową pracę, aby przekonwertować te deklaratywne struktury na operacje DOM, wykorzystując tzw Virtual DOM

Oryginalną obietnicą React'a było to, że mogłeś ponownie wy-renderować całą aplikację przy każdej zmianie stanu bez obawy o wydajność. Gdyby tak jednak było, nie byłoby potrzeby takich optymalizacji, jak shouldComponentUpdate albo pureComponent. Nawet w przypadku shouldComponentUpdate aktualizowanie wirtualnego DOM całej aplikacji za jednym razem to dużo pracy. Jakiś czas temu zespół React'owy wprowadził React Fibre, które pozwala podzielić aktualizację na mniejsze części. Oznacza to (między innymi), że aktualizacje nie blokują głównego wątku (main thread) przez długi czas, chociaż nie zmniejsza to całkowitej ilości pracy ani czasu potrzebnego na aktualizację prawdziwego DOMu

Zamiast tego Svelte działa podczas kompilacji, przekształcając komponenty w wysoce wydajny kod imperatywny, który chirurgicznie aktualizuje DOM. W rezultacie możesz pisać ambitne aplikacje o doskonałych parametrach wydajnościowych.

Cybernetyczne appki webowe ?

Svelte.js używa własnego typu plików ".svelte", który przyjmuje 3 bloki kodu (style, code, html markdown, przykład poniżej). Svetle w swej ideologii chcę aby programista pisał jak najmniej kodu, gdyż to zwiększa jego czytelność, nadzór i późniejsze rewizję, zamieszczam poniżej ten sam komponent w React'cie, Vue oraz Svelte.

Svetle

<style>
  p {
  color: red;
  }
</style>
<script>
	let a = 1;
	let b = 2;
</script>

<input type="number" bind:value={a}>
<input type="number" bind:value={b}>

<p>{a} + {b} = {a + b}</p>

React

export default () => {
  const [a, setA] = useState(1);
  const [b, setB] = useState(2);

  function handleChangeA(event) {
    setA(+event.target.value);
  }

  function handleChangeB(event) {
    setB(+event.target.value);
  }

  return (
    <div>
      <input type="number" value={a} onChange={handleChangeA}/>
      <input type="number" value={b} onChange={handleChangeB}/>

      <p>{a} + {b} = {a + b}</p>
    </div>
  );
};

Vue

<template>
  <div>
    <input type="number" v-model.number="a">
    <input type="number" v-model.number="b">

    <p>{{a}} + {{b}} = {{a + b}}</p>
  </div>
</template>

<script>
  export default {
    data: function() {
      return {
        a: 1,
        b: 2
      };
    }
  };
</script>

Jak widać kod "Reactowy" jest prawie 3 dłuższy. Dodatkowo według oficjalnej dokumentacji svelte, możemy zapomnieć o manualnej optymalizacji komponentów za pomocą takich funckji jak useMemo, useEffect, useCallback. Svelte ma wbudowane wszystkie rozwiązania w swój compiler.  

Svelte jako compiler , który następnie pakuje swoje pliki do czystego vanilla JS, html i css, ma dość bogate wbudowane API, od bindingów danych, animacje i przejścia między komponentami, moduły odpowiadające głównym reactowym bibliotekom takim jak wbudowany store (reactowy redux lub context api jak kto woli), head (react helmet) oraz wiele innych. Sprawdź więcej na oficjalnej dokumentacji svelte w języku angielskim .

Podsumowanie

Svelte obecnie (01.11.2019) jest w swojej wersji 3.0, ale wydaje mi się, że jeszcze przed nim długa droga rozwijania samego "compilera", społeczności oraz koncepcji nie używania wirtualnego DOM'u. W testach prezentowanych przez jednego z twórcą Rich Harris, svelte pokonuje wszystkie dostępne frameworki JS zarówno pod względem rozmiaru paczki jak i samej szybkości działania aplikacji , co może się okazać kluczową sprawą podczas budowania i projektowania aplikacji na urządzenia IoT (internet of things). Na teraz nadaję się raczej do budowania prostych aplikacji i stron statycznych, niż pełno flagowych aplikacji webowych.

W 2009 roku wraz z wydaniem ES5, JS dodał tryb ścisły jako mechanizm opt-in do zachęcania programistów do pisania lepszych programów JS.

Korzyści z trybu ścisłego znacznie przewyższają koszty, ale stare nawyki umierają ciężko, a "naprawa" istniejących („legacy) baz kodu jest naprawdę trudna. Niestety, ponad 10 lat później, opcjonalność trybu ścisłego oznacza, że ​​nadal niekoniecznie jest on domyślny dla programistów JS.

Dlaczego tryb ścisły? Tryb ścisły nie powinien być traktowany jako ograniczenie tego, czego nie możesz zrobić, ale raczej jako przewodnik po najlepszym sposobie robienia rzeczy, aby silnik JS miał najlepszą szansę na optymalizację i wydajne działanie kodu.

Większość elementów sterujących w trybie ścisłym ma postać wczesnych błędów, co oznacza błędy, które nie są błędami ściśle składniowymi, ale wciąż są zgłaszane w czasie kompilacji (przed uruchomieniem kodu). Na przykład tryb ścisły uniemożliwia nazywanie dwóch parametrów funkcji tak samo i powoduje błąd. Niektóre inne kontrolki trybu ścisłego są obserwowalne tylko w czasie wykonywania, na przykład domyślna wartość słowa "this" jako niezdefiniowana (undefinded).

Zamiast walczyć i kłócić się w trybie ścisłym, jak dziecko, które chce po prostu przeciwstawić się temu, co mówią im rodzice, najlepszym sposobem myślenia o trybie "ścisłym" jest to, że jest on jak liniowiec przypominający, jak JS powinien być napisany, aby mieć najwyższą jakość oraz najlepszą szansę na wydajność. Jeśli czujesz się zakuty w kajdanki, próbując obejść tryb ścisły, powinna to być czerwona flaga ostrzegawcza, którą sygnalizuje, że musisz przemyśleć całe podejście.

Tryb ścisły jest włączony dla każdego programu (dla pliku!) W następujący sposób:

// only whitespace and comments are allowed
// before the use-strict pragma

"use strict";

// everything in this file runs in strict
// mode

W górnej części pliku musi pojawić się pragma trybu ścisłego, z dozwolonymi tylko białymi spacjami lub komentarzami.

Niewielką sprawą, o której trzeba pamiętać, jest, że nawet zabłąkany ";" uczyni pragmię bezużyteczną; nie są zgłaszane żadne błędy, ponieważ poprawne JS ma wyrażenie dosłowne w pozycji instrukcji, ale po cichu nie włączy trybu ścisłego!

Tryb ścisły można alternatywnie włączyć w zależności od zakresu (scope) funkcji, z dokładnie tymi samymi regułami / upomnieniami dotyczącymi jego pozycjonowania):

function someOperations() {
    // whitespace and comments are fine here
    "use strict";

    // all this code will run in strict mode
}

Co ciekawe, jeśli cały plik ma włączony tryb ścisły, trybu ścisły na poziomie funkcji jest niedozwolony. Więc musisz wybrać jedno lub drugie.

Jedynym uzasadnionym powodem zastosowania podejścia do trybu ścisłego dla poszczególnych funkcji jest konwertowanie istniejącego programu  i konieczne jest stopniowe wprowadzanie zmian w miarę upływu czasu. W przeciwnym razie znacznie lepiej jest po prostu włączyć tryb ścisły dla całego pliku / programu.

Wielu zastanawia się, czy JS kiedykolwiek nada trybowi domyślnemu tryb ścisły? Odpowiedź brzmi: prawie na pewno nie. Jak już wcześniej mówilIstnieje jednak kilka czynników, które zmniejszają przyszły wpływ tego niewystarczającego „zaciemnienia” trybu ścisłego.iśmy o kompatybilności wstecznej, jeśli aktualizacja języka JS oznaczyła by, że każdy kod jest trybem ścisłym, wtedy wszystkie kody "legacy" nie przechodziły by nowej walidacji silnika JS.

Warto zaznaczyć, że praktycznie cały transpilowany kod kończy się w "trybie ścisłym", nawet jeśli oryginalny kod źródłowy nie jest zapisany jako taki. Większość produkowanych kodów JS została przetranspilowana, co oznacza, że ​​większość kodu JS na www, już przestrzega trybu ścisłego.

Co więcej, zachodzi szeroka zmiana w kierunku pisania nowego kodu JS przy użyciu formatu ES6. Moduły ES6 przyjmują tryb ścisły, więc cały kod w takich plikach jest automatycznie domyślnie ustawiany na ten tryb.

Tryb ścisły jest w dużej mierze de facto domyślny, chociaż technicznie tak naprawdę nie jest domyślny.

Czas na kolejną batalie między konkurencyjnymi systemami (sprawdź także REST vs GraphQL) , tym razem na warsztat idą bazy danych.  Prędzej czy później każdy system, aplikacja czy instalacja webowa potrzebuje zachowywać i pobierać dane, przed projektantem systemowym staje dość trudne i istotne pytanie; Jaki typ bazy danych wybrać SQL czy NoSQL ?

Warto zaznaczyć, że nie ma tutaj jednej właściwej odpowiedzi, a raczej zestaw czynników, które trzeba wsiąść pod uwagę.

SQL  

Baza danych SQL doskonale nadaje się do systemów zorientowanych na transakcje, takich jak narzędzia do zarządzania relacjami z klientami, oprogramowanie księgowe i platformy handlu elektronicznego. Każdy wiersz w bazie danych SQL jest odrębnym podmiotem (np. Klientem), a każda kolumna jest atrybutem opisującym ten podmiot (np. Adres, stanowisko, zakupiony towar itp.).

Ze względu na te odrębne, u strukturyzowane relacje między wierszami i kolumnami w tabeli, bazy danych SQL są najlepsze, gdy potrzebujesz zgodności z ACID compliance:

Atomowość (Atomicity) - każda transakcja kończy się powodzeniem lub jest całkowicie wycofywana.

Spójność - dane są zapisywane w bazie danych muszą być prawidłowe zgodnie ze wszystkimi zdefiniowanymi regułami.

Izolacja - gdy transakcje są uruchamiane jednocześnie, nie konkurują ze sobą i działają tak, jakby były uruchamiane sekwencyjnie.

Trwałość - po zatwierdzeniu transakcji w bazie danych jest ona uznawana za trwałą, nawet w przypadku awarii systemu.

Zgodność z ACID chroni integralność danych poprzez dokładne określenie, czym jest transakcja i jak wchodzi ona w interakcję z bazą danych. Pozwala to uniknąć synchronizacji tabel bazy danych, co jest bardzo ważne w przypadku transakcji finansowych. Zgodność z ACID gwarantuje ważność transakcji nawet w obliczu błędów, awarii technologii, katastrofalnych zdarzeń itp.

Jeśli Twoje dane są bardzo u strukturyzowane, a zgodność z ACID jest koniecznością, SQL jest doskonałym wyborem. Z drugiej strony, jeśli Twoje wymagania dotyczące danych nie są jasne lub jeśli Twoje dane są niestrukturyzowane, NoSQL może być najlepszym rozwiązaniem.

Dane przechowywane w bazie danych NoSQL nie potrzebują przedefiniowanego schematu, jak w przypadku bazy danych SQL. Dane mogą być raczej składami kolumn, parami zorientowanymi na dokument, opartymi na wykresach lub klucz-wartość. Zapewnia to znacznie większą elastyczność i mniej planowania z góry podczas zarządzania bazą danych.

Na NoSQL możesz:

Tworzyć dokumenty bez wcześniejszego dokładnego definiowania ich struktury

Dodawać pola do bazy danych bez zmiany pól istniejących dokumentów

Przechowywać dokumenty, które mają swoją unikalną strukturę

Posiadać wiele baz danych o różnych strukturach i składni

Baza danych NoSQL najlepiej nadaje się do przechowywania danych, takich jak treść artykułów, posty w mediach społecznościowych, dane z czujników i inne rodzaje danych niestrukturyzowanych, które nie mieszczą się w tabeli. Bazy danych NoSQL zostały zbudowane z myślą o elastyczności i skalowalności i są zgodne z modelem spójności BASE, co oznacza:

• Podstawowa dostępność (Basic Availability) - oznacza to, że chociaż baza danych gwarantuje dostępność danych, baza danych może nie uzyskać wymaganych danych lub dane mogą być w stanie zmieniającym się lub niespójnym.
  
• Stan miękki (Soft State) - Stan bazy danych może się zmieniać z czasem.
• Ostateczna spójność (Eventual consistency) - Baza danych ostatecznie stanie się spójna, a dane będą propagowane wszędzie w dowolnym momencie w przyszłości.

Struktura danych jest najważniejszym czynnikiem decydującym o tym, czy użyć bazy danych SQL, czy NoSQL, więc zastanów się nad tym przed podjęciem decyzji.

Możliwość zapytania danych

Następnym czynnikiem, który należy wziąć pod uwagę, jest częstotliwość wysyłania zapytań do danych, szybkość uruchamiania zapytań i kto będzie odpowiedzialny za ich uruchamianie.

Ponieważ twoje dane są ładnie u strukturyzowane i zorganizowane, bardzo wydajne jest wyszukiwanie danych w bazie danych SQL.

SQL jest popularnym językiem programowania, który istnieje od ponad 45 lat, więc jest niezwykle dojrzały i dobrze znany. Wydajnie wykonuje zapytania oraz szybko pobiera i edytuje dane. Jest bardzo lekki i deklaratywny, a zatem łatwy do nauczenia. Dlatego zapytania mogą być uruchamiane przez mniej techniczny personel, taki jak analitycy biznesowi i marketerzy.

Baza danych NoSQL zapewnia ogromną elastyczność w zakresie typów danych, które można przechowywać, ale ze względu na potencjalnie duże różnice w strukturach danych zapytania nie są tak wydajne, jak w przypadku bazy danych SQL.

Podczas budowania technologii baz danych NoSQL programiści skupili się na skalowalności i elastyczności, a nie na wydajności zapytań.

Skalowanie

Bazy danych SQL i NoSQL skalują się w różny sposób. Bazy danych SQL są skalowane w pionie, co oznacza, że ​​musisz zwiększyć pojemność jednego serwera (zwiększenie procesora, pamięci RAM lub SSD), aby skalować bazę danych. Bazy danych SQL zostały zaprojektowane do działania na jednym serwerze w celu zachowania integralności danych, więc nie są łatwe do skalowania.

Bazy danych NoSQL skalują się w poziomie, co oznacza, że ​​możesz dodać więcej serwerów, aby zasilać rosnącą bazę danych. Jest to ogromna przewaga, jaką NoSQL ma nad SQL.

Zdolność baz danych NoSQL do skalowania w poziomie wiąże się z brakiem struktury danych. Ponieważ NoSQL wymaga znacznie mniej struktury niż SQL, każdy przechowywany obiekt jest prawie samowystarczalny i niezależny. W ten sposób obiekty mogą być łatwo przechowywane na wielu serwerach bez konieczności łączenia. Nie dotyczy to SQL, w którym każdy wiersz tabeli i kolumna muszą być powiązane.

W miarę rozwoju firmy rośnie również baza danych. Upewnij się, że bierzesz pod uwagę swoje potrzeby skalowania.

Konwergencja SQL i NoSQL

Zarówno bazy danych SQL, jak i NoSQL mają swoje zalety i wady. W związku z tym nastąpił ruch, aby wziąć najlepsze cechy obu typów baz danych i zintegrować je, aby użytkownicy mogli realizować to, co najlepsze z obu światów.

Na przykład MySQL, najpopularniejsza relacyjna baza danych typu open source, oferuje MySQL Document Store. Zapewnia to strukturę bazy danych MySQL w połączeniu z elastycznością i wysoką dostępnością NoSQL bez konieczności wdrażania oddzielnej bazy danych NoSQL.

MongoDB, jedna z najpopularniejszych baz danych NoSQL, oferuje transakcje wielodokumentowe ACID.

DynamoDB, zarządzana przez AWS baza danych NoSQL, zapewnia także funkcje transakcyjne zgodne z ACID.

A dzięki łatwej konfiguracji bazy danych oferowanej przez dostawców usług w chmurze masz możliwość korzystania z bazy danych SQL i NoSQL w architekturze chmury w celu zaspokojenia potrzeb w zakresie przechowywania danych.

Teraz masz znacznie większą elastyczność, niezależnie od tego, czy wybierzesz bazę danych SQL, czy NoSQL, i na pewno będą bardziej elastyczne opcje w przyszłości.

Opcje bazy danych

Niezależnie od tego, czy korzystasz z bazy danych SQL, czy NoSQL, istnieje wiele opcji do wyboru.

Lokalne oferty baz danych SQL obejmują:

• MySQL - jak wspomniano wcześniej, najpopularniejsza relacyjna baza danych typu open source
  
• Serwer Microsoft SQL - korporacyjna wersja SQL firmy Microsoft
  
• PostgreSQL - oraz korporacyjna baza danych typu open source skoncentrowana na rozszerzalności
  
• Oracle - kompleksowa (i droga) opcja SQL
  
• MariaDB - ulepszona wersja MySQL, stworzona przez oryginalnych programistów MySQL

Główne platformy usług w chmurze mają własne opcje SQL:

AWS ma:

• RDS
• Aurora, która koncentruje się na zwiększonej przepustowości i skalowalności

Microsoft Azure ma:

• Baza danych Azure SQL, zarządzana baza danych jako usługa (SAAS)
• Baza danych Azure dla MySQL,
• PostgreSQL  
• MariaDB

Google Cloud Platform (GCP) ma:

• Cloud SQL, którego możesz używać dla MySQL i
• PostgreSQL
• Cloud Spanner, który łączy elementy SQL i NoSQL

Lokalne opcje bazy danych NoSQL obejmują:

• MongoDB - zdecydowanie najpopularniejsza baza danych NoSQL
  
• Redis - superszybka, rozproszona baza danych z kluczami i wartościami w pamięci
  
• Cassandra - darmowa, otwarta baza danych NoSQL stworzona przez Facebooka, która koncentruje się na skalowalności i wysokiej dostępności
  

Dostawcy usług w chmurze oferują również wiele opcji NoSQL:

AWS ma:

• DynamoDB, zarządzana baza danych NoSQL
  
• DocumentDB, szybka, skalowalna, wysoce dostępna baza danych zgodna z MongoDB

Microsoft Azure oferuje:

• CosmosDB, globalnie dystrybuowana, wielomodelowa baza danych

Google Cloud ma:

• Bigtable, szerokokolumnowa usługa bazy danych NoSQL
  
• Cloud Datastore, usługa bazy danych dokumentów NoSQL
  
• Cloud Firestore, natywna dla chmury baza danych dokumentów NoSQL, która pomaga przechowywać i przeszukiwać dane aplikacji

Podsumowanie

Istnieje wiele mitów i nieporozumień dotyczących SQL; na przykład, że SQL jest przestarzały i powinien być zastąpiony przez NoSQL, gdy tylko jest to możliwe. Oczywiście to nie prawda. Obecnie nie ma wyraźnego lidera wśród nich, każdy z nich jest bardziej odpowiedni dla niektórych projektów i mniej odpowiedni (lub wręcz nieodpowiedni) w innych sytuacjach. Dlatego nie ma uniwersalnego idealnego wyboru.

Zanim przejdę do dokładnego, subiektywnego omówienia różnic pomiędzy tymi dwoma podejściami zapytań serwera / backendu warto zaznaczyć, że żadna z tych technologii nie jest lepsza lub gorsza od drugiej. To są zupełnie 2 różne technologie i podejścia do budowy systemu aplikacji webowej.  

Pierwsze różnice ...

REST to architektoniczny koncept budowy systemów internetowych, nie ma oficjalnych narzędzi oraz specyfikacji . Zaprojektowany z myślą aby rozłączyć (decouple) API od klienta (frontu). W przeciwieństwie do GraphQl może nie tylko posługiwać się HTTP, jego zadaniem jest budowa stabilnej i trwałej architektury systemu.

GraphQL to język zapytań  "query language", specyfikacji i narzędzi zbudowanych z myślą o optymalizacji  dostarczania danych poprzez jeden endpoint HTTP.

Jedną z głównych zasad konwencji REST, jest to aby używać wszystkich dostępnych protokołów. REST używa HTTP content-types, caching, status codes. GraphQL używa swoich własnych konwencji

W poście postaram się pokazać wam właśnie te różnice w podejściu do budowy aplikacji. Warto pamiętać, że pod koniec dnia jaka technologia jest lepsza zależy od tego co robicie ze swoją aplikacją, dla niektórych rzeczy GraphQL będzie lepszy, dla innych REST, dla jeszcze innych obydwa podejścia mogą okazać się tak samo frustrujące.

Czy API to tylko transfer danych ?

Jedną z podstawowych zadań REST API to tzw operacje CRUD (create, read, update, delete) poprzez plik JSON. Jedną zalet REST jest łatwe i szybkie przesyłanie plików

Przykładowy przesył pliku jpeg

POST /avatars HTTP/1.1
Host: localhost:3000
Content-Type: image/jpeg
Content-Length: 284

raw image content

Korzystając z protokołu HTTP (a zatem i REST), programiści mogą obsługiwać żądania aplikacji / json na tym samym punkcie końcowym, można także oferować przesyłanie na podstawie adresu URL:

POST /avatars HTTP/1.1
Host: localhost:3000
Content-Type: application/json

{
  "image_url" : "https://spaceout.pl/pic.png"
}

Gdybyśmy mówili o przesyłaniu filmów lub innych dużych plików zaproponowałbym inne podejście i miałbym dedykowaną usługę, która obsługuje przesyłanie, pozostawiając główny interfejs API akceptujący tylko metadane; tytuł, opis, tagi itp.

W przypadku GraphQL takie podejście to nasz jedyny wybór, ponieważ możesz komunikować się z GraphQL tylko w zakresie pól:

POST /graphql HTTP/1.1
Host: localhost:3000
Content-Type: application/graphql

mutation addAvatar {
  addProfileImageFromUrl(image_url: "https://spaceout.pl/pic.png") {
    id,
    image_url
  }
}

Niektórzy twierdzą, że jest to bardziej „czyste”, ale zmuszenie do stworzenia innej usługi jest przesadą w przypadku mniejszych obrazów, szczególnie na początku projektu.

Innym podejściem jest przesyłanie bezpośrednio np do Amazon S3, wymuszając zależność od klientów i potencjalnie pozwalając na wyciek tokenów.

Jednym z obszarów, w którym GraphQL wyróżnia się, jest niezwykle łatwe monitorowanie wykorzystania pola na poziomie technicznym. Klienci GraphQL są zmuszeni do określenia pól, które mają zostać zwrócone w zapytaniu:

POST /graphql HTTP/1.1
Host: localhost:3000
Content-Type: application/graphql

{
  spaceships(id: "123") {
    length,
    width,
    power
  }
}

Śledzenie tego byłoby trywialne, ale interfejs API REST działa nieco inaczej. Podczas gdy wszystkie interfejsy API REST udostępniają podstawowy punkt końcowy za pośrednictwem/spaceships/123, nie wszystkie interfejsy API oferują rzadkie zestawy pól: /spaceships/123?fields=length,width,intelligence.

Jeśli klient interfejsu API REST wywołuje /spaceships/123, może używać dowolnego pola w tej odpowiedzi. Wyobraź sobie, że API planuje pozbyć się power , skąd programiści API wiedzą, którzy klienci używają tego pola?

Najczęściej rozwiązuje się ten problem przez utworzenie nowego punktu końcowego / /getSpaceships2 (lub /v2/spaceships/123) i poleceniu innym użytkownikom korzystania z tego nowego.

Innym podejściem byłoby utworzenie nowej wersji zasobu, co oznacza, że ​​zamiast wywoływać  GET za pomocą  Accept: application/vnd.spaceout.pl+v1+json, teraz muszą używać Accept: application/vnd.spaceout.pl+v1+json

GraphQL stawia na wydajność
GraphQL jest zawsze najmniejszym możliwym żądaniem, podczas gdy REST zazwyczaj domyślnie zwraca cały endpoint.

Kiedy aplikacja chce banana, REST zwraca Goryla z dżunglą, trzymającego banana"  

Nawet jeśli interfejs API REST domyślnie zwraca tylko podstawowe częściowe, nadal domyślnie przesyłanych jest więcej bitów niż w przypadku metody GraphQL. Jeśli klient potrzebuje pola, zażąda go, a jeśli interfejs API doda nowe pole, klienci go nie otrzymają.

REST sprawia, że ​​buforowanie jest łatwiejsze na wszystkich poziomach

W interfejsie API opartym na punkcie końcowym klienci mogą korzystać z buforowania HTTP, aby uniknąć ponownego pobierania zasobów oraz do  identyfikowania, kiedy dwa zasoby są identyczne. Jednak w GraphQL nie ma elementu podstawowego podobnego do adresu URL, który zapewnia ten globalnie unikalny identyfikator dla danego obiektu. Dlatego najlepszą praktyką dla API jest ujawnianie takiego identyfikatora do użycia przez klientów. - Źródło: graphql.org

REST przez HTTP wykorzystuje cały stos konwencji HTTP, które sprawiają, że istniejący klienci HTTP, serwery proxy pamięci podręcznej HTTP itp. Działają łatwo, zapewniając korzyści zarówno klientom API, jak i serwerom API, ale z GraphQL… trudnym. Zreorganizuj swoje magazyny danych, użyj kilku Redis i mam nadzieję, że klienci też będą buforować.

GraphQL to język zapytań

Bardzo podstawową różnicą jest tutaj to, że tylko jeden z nich jest językiem zapytań. Interfejsy API REST są często tworzone początkowo proste, a następnie z czasem wprowadzane są coraz więcej funkcji podobnych do języka zapytań.

Najbardziej rozsądnym sposobem dostarczenia argumentów dla zapytań w REST jest umieszczenie ich w ciągu zapytania. Może? ?status=active, aby filtrować według statusu, a następnie prawdopodobnie sort=created, ale klient potrzebuje kierunku sortowania, więc dodaje się sort-dir=desc.
Niektóre używane interfejsy API kończą się także argumentami w ciągu zapytania, które nie są związane z filtrowaniem, a bardziej opcjami.

W przykładzie GraphQL określają jednostkę, w której mają być zwrócone height:

{
  human(id: "1000") {
    name
    height(unit: FOOT)
  }
}

{
  "data": {
    "human": {
      "name": "Luke Skywalker",
      "height": 5.6430448
    }
  }
}

Z REST przy takim zapytaniu mamy trochę bałagan; ?status=active jako filtr, ?unit=foot jako dodatkowa opcja wyświetlania danych. Nasze API /unit=foot?status=active, szybko korzystanie z takich rozwiązań kończy się bólem głowy bez dokumentacji czy jakieś konwencji w budowaniu naszego API.

GraphQL wyprzedza interfejsy API REST, które próbują ręcznie wprowadzić własną funkcjonalność języka zapytań. GraphQL zapewnia składnię języka zapytań oraz zestawy SDK, potrzebne front-end developerowi. Jeżeli planujesz wysoce konfigurowalny interfejs API, jest to kolejny powód do wybrania GraphQL.

Dostosowanie API

Inną kwestią związaną z dostosowywaniem naszego API,  jest to, kiedy zaoferować uwzględnione relacje a kiedy użyć innego punktu końcowego. Może to być trudny wybór projektowy, interfejs API powinien być elastyczny i wydajny.

Zaczynasz od  /users?include=comments,posts a tu jeszcze profile, settings ...  i więcej informacji które potrzebuje klient. Tutaj znowu pojawia się problem banana z gorylem i dżungla. Czasami potrzebne są tylko szczątkowe informacje potrzebne z każdego obiektu.

GraphQL nie tylko usuwa to pytanie projektowe, ale wymusza podejście uwzględniające i zmusza do rozważenia wydajnych sposobów pobierania tych danych. Jest to duża wygrana dla GraphQL,  będzie on zarówno wydajny, jak i spójny.

GraphQL nie pomoże w zapytaniach do bazy danych, więc nadal musisz dostroić te indeksy i buforować fragmenty danych w inteligentny sposób.

Dlaczego nie skorzystać z obu?

Obydwa podejścia mają swoje wady i zalety, nie znaczy jednak, że musimy się decydować na tylko jedno z nich. REST API świetnie posłuży do przesyłania zdjęć, potwierdzania tokenów, resetu hasła ..., GraphQL jest wydajnym klientem dostarczającym treść i dane potrzebne dla każdego zaplanowanego widoku strony internetowej czy aplikacji.  

Robiąc dobry Front End trzeba pamiętać o wszystkich przeglądarkach, pollyfilach i cross-browserowych sprawach. Jednym z najtrudniejszych zadań zawsze dla mnie było radzenie sobie z przeglądarką safari oraz system macOS. Nie jestem fanem maców, uważam, że trochę za bardzo cenią sobie swoje produkty,  nie można ukryć, że jest na wiele świecie wiele zadowolonych użytkowników iPhona, którzy nie zamierzają przerzucać się na andro. Warto zadbać aby nasza strona prezentowała się w safari tak jak powinna.

Safari mobile jak i jego desktopowa wersja, zawszę była w tyle do chrome czy nawet samego firefoxa, późniejsza implementacja flexboxa, grida, filtrów css jak i wiele bugów w samym odczycie css przyprawiało mnie o koszmary podczas finalnych oględzin stron do oddania.

Natrafiłem jednak na narzędzie, które pomogą w debugowaniu stron i aplikacji w chrome, firefox i vs code. Ciągle potrzebny jest nam telefon iPhone ale to wydaje mi się łatwiejsze do ogarnięcia niż nowy macbook z wystarczająca ilością ramu do odpalenia programu xcode i symulatora iOS.

Projekt jest trudny w konfiguracji, wymaga dostępu do powershella windowsa, instalacji scoop'a. Najlepiej postępować według oryginalnej dokumentacji projektu.

https://github.com/RemoteDebug/remotedebug-ios-webkit-adapter

Aby debugować iOS, po zmianach w 12 >, projekt który chcecie ściągnąć to fork od  https://github.com/fishbone1/remotedebug-ios-webkit-adapter.

Musicie przejść przez kroki przygotowania systemu i instalacji samej paczki oraz libimobile, sklonować projekt oraz wykonać polecenia, npm install i start. Warto także pamiętać aby ustawić port w " Discover network targets" w opcjach chrome://inspect  

Wygląda na to, że nikt się zbytnio nie zajmuje projektem jednakże myślę, że to bardzo ciekawy projekt. Korzysta z websocetsów aby transportować dane między komputerem a telefonem. Uratował mnie już nie jeden raz przed notorycznymi problemami na telefonach iphone.

Czy zdarzyło się wam grzebać lub poprawiać coś w instalowanych paczkach na swoim projekcie ? Jeżeli tak to dobrze wiecie, że jakiekolwiek zmiany zapisane bezpośrednio w folderze node_modules nie maja prawa bytu ze względu na to, że zostaną nadpisane przy jakiekolwiek zmianie / instalacji projektu. Na szczęście przychodzi nam na ratunek moduł patch-package.

Normalnie gdy odkryjemy jakiś błąd lub chcielibyśmy dodać jakikolwiek feature do jednych z bibliotek, które znajdują się u nas w folderze node_modules, musimy z "forkować" oryginalną bibliotekę, nanieść zmiany i dać pr merge na githubie. Ale jeżeli poprawiamy jakiś błąd na dużym projekcie, takie rozwiązanie może trwać pare dni, jeżeli nie tygodni. Testy, review team itd. Co jak nie chcemy się w to bawić, albo porostu nie mamy na to czasu ?

patch-package

Dla przykładu chcemy edytować paczkę przykład-lib

1. Instalacja patch-package

yarn add --dev patch-package postinstall-prepare

instalacja postinstall-prepare musi zostać dołączona ze względu na to aby upewnić się, że patch-package zostanie uruchomiony nawet po komendzie yarn remove

2. Zmiana plików w przykład-lib

Edytujemy i zapisujemy zmiany normalnie tak jakby by były częścią projektu.

3. Uruchomienie patch-package

yarn patch-package przykład-lib

Patch-package wychwyci zmiany w przykład-lib, da znać na terminalu, że zmiany zostały zapisane, dodatkowo dołoży nam folder do projektu "/patches", gdzie przechowuje nasze zmiany.

4. Edycja pliku package.json

Ostatnim krokiem instalacji patch-package jest dodanie skryptu "prepare" do naszego pliku package.json. Dzięki temu poleceniu nasz projekt zawsze będzie niezależnie i automatycznie dodawał nasze zmiany przy poleceniach yarn czy npm install.

"scripts": {
  "prepare": "patch-package"
}

To już wszystko co trzeba zrobić aby móc dowolnie patchować 3rd party libraries. Dla mnie ta opcja jest bardzo pomocna, jednakże nie wolno zapominać, że najlepszym rozwiązaniem jest ciągle "forkowanie" bibliotek i nanoszenie zmian dla nas wszystkich.  Open source górą.

Jak zwykle pozdrawiam serdecznie.

Aplikacje, serwery, endpointy czy wszelkiego rodzaju instalacje webowe zazwyczaj kończą swój cykl developerski w chmurzę, dedykowanych serwerach czy vps-ach (virtual private server). Centos 7 to stabilny system operacyjny oparty o RHEL Red Hat Enterprise Linux (RHEL).  Jest to mój ulubiony system pod testowanie aplikacji webowych. Jakiś czas temu przerobiłem starego laptopa na serwer oparty o Centos 7. Dużo integruje w ten system, aby znaleźć optymalne ustawienia wydajności i bezpieczeństwa.  Ostatnio strasznie popsułem ustawienia, dlatego postanowiłem zainstalować Centosa od nowo oraz zapisać sobie proces instalacyjny, żebym nie musiał biegać po googlu jak szalony.

Centos 7  

Centosa najlepiej się chyba ściga przez torrenty, można znaleźć plik torrent w każdym z oficjalnych mirror'ów strony oficjalnej .

Program Rufus do robienia USB BOOT UEFI na Win

Linux, można od wersji centos 6 można kopiować obraz bezpośrednio na USB  

dd if=CentOS-6.5-x86_64-bin-DVD1.iso of=/dev/sdb

Instalacja

Wersja 7.4 DVD Iso posiada graficzny interfejs instalacyjny, ustawiamy ścieżkę do dysku oraz pakiety jakie chcemy zainstalować.  Centos 7 zawiera pakiety dla developerów, pod server, gnome desktop, itd.

Po instalacji systemu osobiście instaluje także:

Node.js

Centos 7, zależnie od pakietów wybranych przy instalacji systemu posiada, już node.js, jednakże jest to wersja 6. (Ostatnia poważna aktualizacja systemu Centos 7 była w 2014 roku). Aby zainstalować nowe wersje musimy dodać repo do bazy Centos 7.

Najnowszy node(12):

yum install -y gcc-c++ make 
curl -sL https://rpm.nodesource.com/setup_12.x | sudo -E bash -

Stable:

yum install -y gcc-c++ make 
curl -sL https://rpm.nodesource.com/setup_10.x | sudo -E bash -
 

*Możliwe są dalsze problemy instalacyjne node, najczęściej system wywala się podczas instalacji nowszej wersji node.js

Workaround:

Instalujemy nowy node przez npm oraz podmieniamy ścieżki (system link do nowej wersji node)

npm cache clean -f
npm install -g n
ln -sf /usr/local/n/versions/node/(wersja node, np:)10.15.3/bin/node /usr/bin/node
node -v (sprawdzamy wersje)

Yarn

Trzeba dodać repo yarn

curl --silent --location https://dl.yarnpkg.com/rpm/yarn.repo | sudo tee /etc/yum.repos.d/yarn.repo
yum -y install yarn

Git

Z git możemy mieć problem z dostępem do najnowszej wersji. Centos 7 może nam uparcie mówić, że wersja 1.8 to najnowsza wersja. W takim razie musimy usunąć gita, i zainstalować nowszą wersje od iuscommunity

sudo yum remove git
sudo yum -y install  https://centos7.iuscommunity.org/ius-release.rpmsudo yum -y install  git2u-all
$ git --versiongit version 2.16.5

Docker i Docker Compose

Dodajemy odpowiednie repa do yum config, oraz instalujemy docker-ce

sudo yum install -y yum-utils device-mapper-persistent-data lvm2
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum install docker-ce
sudo usermod -aG docker nazwa_użytkownika
sudo systemctl enable docker.service
sudo systemctl start docker.service

Docker Compose

sudo yum install epel-release
sudo yum install -y python-pip
sudo pip install --upgrade pip
sudo pip install docker-compose
sudo yum upgrade python*
docker-compose version

*Problem GSSException przy sprawdzaniu wersji można rozwiązać przez usunięcie pakietu python-gssapi

sudo yum remove python-gssapi

Google Chrome

Musimy stworzyć własny plik z info o repo Googla, w ten sposób będziemy mogli robić update Chrome przez komendy.

cd /etc/yum.repos.d/
sudo nano google-chrome.repo

Dodać plik o treści

[google-chrome]
name=google-chrome
baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64
enabled=1
gpgcheck=1
gpgkey=https://dl.google.com/linux/linux_signing_key.pub

Visual Studio Code

Dodajemy repo, VS code

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
sudo sh -c 'echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/vscode.repo'

Sprawdzamy i instalujemy code

yum check-update
sudo yum install code

Konfiguracja Sieci

Ostanie co musimy zrobić to ustawić naszą sieć lokalną oraz zasady firewall aby nasze aplikacje uruchomione na Centos 7 były dostępne z innych urządzeń. Zazwyczaj musimy otworzyć porty używane podczas cyklu developerskiego  (8000) i produkcyjnego (3000).

firewall-cmd --zone=public --permenent --add-service=https
firewall-cmd --zone=public --permenent --add-service=http
firewall-cmd --zone=public --permenent --add-service=ssh
firewall-cmd --zone=public --permenent --add-port=(numerPortu)/tcp
firewall-cmd --reload

Teraz nasze apki już powinny być dostępne dla sieci lokalnych.

Centos oraz systemy linkusowe są o wiele bardziej dostosowane do współpracy z node niż Windows według mojej opinii, starszy komputer z i5 radzi sobie lepiej, szybciej buduje i serwuje pliki niż i7 z windowsem. Dodatkowo natywne mamy obsługę dockera, która przydaje się podczas końcowego etapu deweloperskiego aplikacji.

Pozdrawiam

O Zaletach gatsby.js rozpisywałem się już na swoim blogu wielokrotnie, to generator stron statycznych, w którym mamy możliwość zaciągania danych z dowolnego API.

Wordpress pomimo sowich wielu wad, to jednak stary i sprawdzony muł, jest idealnym kandydatem do systemu CMS. Wiele osób z niego korzysta, można dość szybko dostosować jego możliwości backendowe.

WooCommerce jest jedna z takich możliwości, w szybki i tani sposób mamy cały system sklepowy, który integruje się z system REST API wordpressa co oznacza, że nasza instalacja jest właściwie gotowa do przyjęcia dowolnego klienta.

Ja do frontu zazwyczaj korzystam z gatsby.js, jakby ktoś chciał skorzystać z takiego rozwiązania to mam własnego forka, https://github.com/MassivDash/gatsby-source-woocommerce. Dałem jakieś tam małe usprawnienia ale przedrzymskim dodałem funkcje kontroli zaciągania produktów jakiej brakuje głównemu repo.

Plugin korzysta z oficjalnego node api wordpressa, zaciąga dane o produktach następnie przetwarza je na graphql endpoint dla naszego gatsby.js. Podczas local developmentu mamy już pełny set danych i nic nam nie stoi na przeszkodzie zbudowania stron produktów czy głównej sklepu.

Dzięki takiemu rozdzieleniu instalacji, możemy zbudować nasz front w technologii react oraz wyrzuć nasz sklep na dowolny serwer.