Skip to main content

DataStax Adds gRPC To Stargate For Performant Microservices

You can now interact with the AstraDB multi-cloud DBaaS that is built on Apache Cassandra, through gRPC. This is a welcome addition to the already rich collection of APIs for accessing AstraDB over Stargate.


This new API is added to Stargate Gateway, DataStax's data gateway that gets deployed between client applications and databases which, as we explained in "DataStax Extends Stargate" exposes the database layer as a multitude of APIs.


full article on i-programmer:

https://www.i-programmer.info/news/84-database/15024-datastax-adds-grpc-to-stargate-for-performant-microservices.html



astradb

Comments

Popular posts from this blog

Headless Chrome and the Puppeteer Library for Scraping and Testing the Web

With the advent of Single Page Applications, scraping pages for information as well as running automated user interaction tests has become much harder due to its highly dynamic nature. The solution? Headless Chrome and the Puppeteer library. While there's always been Selenium, PhantomJS and others, and despite headless Chrome and Puppeteer arriving late to the party, they make for valuable additions to the team of web testing automation tools, which allow developers to simulate interaction of real users with a web site or application. Headless Chrome is able to run without Puppeteer, as it can be programmatically controlled through the  Chrome DevTools Protocol , typically invoked by attaching to a remotely running Chrome instance: chrome --headless --disable-gpu                      --remote-debugging-port=9222 Subsequently loading the protocol's sideckick module 'chrome-remote-interface' which provides  a simple abstraction of commands and notifications using

Upgrading to a newer Ingres version breaks SQL query

The following query (ignore most fields,just pay attention to d1.last_aa )   Q1   select d1.last_aa,           m.c_ylikoy as c_ylikoy,           n_ylikoy = m.n_ylikoy,           c_typ_ylik=tf.c_typ_ylik,           n_typ_ylik = tf.n_typ_ylik,           tm_mesh=m.tm_mesh,           pt_fpa=m.pt_fpa,           pt_fpa_last= d1.pt_fpa,           end_eis_ex = d.end_eis_ex,           ps_diaqesh = sum(d.ps_diaqesh),                    tm_monadas = avg(d.tm_monadas),           c_mon_metr = m.c_mon_metr,           c_typ_gmdn = m.c_typ_gmdn,           c_loga = m.c_loga,           c_cpv = c.c_cpv,           n_cpv = c.n_cpv,           c_prom = h1.c_prom,           c_loga_dls = ss.c_loga_dls,           tm_mm_last = max(decimal (d1.timh_symb /s.periektiko, 16, 4)),           tm_mm_fpa_last = max(( d1.timh_symb /s.periektiko) * (100.0 +d1.pt_fpa) / 100)        from hi_denyl d  inner join hi_henyl h on             d.c_entyp = h.c_entyp and             d.last_year = h.last_year and             d.las

Book Review : How To Create Pragmatic, Lightweight Languages

At last, a guide that makes creating a language with its associated baggage of lexers, parsers and compilers, accessible to mere mortals, rather to a group of a few hardcore eclectics as it stood until now. The first thing that catches the eye, is the subtitle: The unix philosophy applied to language design, for GPLs and DSLs" What is meant by "unix philosophy" ?. It's taking simple, high quality components and combining them together in smart ways to obtain a complex result; the exact approach the book adopts. I'm getting ahead here, but a first sample of this philosophy becomes apparent at the beginnings of Chapter 5 where the Parser treats and calls the Lexer like  unix's pipes as in lexer|parser. Until the end of the book, this pipeline is going to become larger, like a chain, due to the amount of components that end up interacting together. The book opens by putting things into perspective in Chapter 1: Motivation: why do you want