Skip to main content

DataStax Extends Stargate with GraphQL

DataStax, mostly known for AstraDB the multi-cloud database based on Apache Cassandra, has announced the addition of new capabilities to its Stargate Gateway product.


Stargate is a data gateway deployed between client applications and databases. Its novelty lies in that it exposes the database layer as a multitude of APIs, that way offering flexibility to the way you expose your data. Needless to say, that's a big boon for developers.

full article on i-programmer.infohttps://www.i-programmer.info/news/84-database/14935-datastax-extends-stargate.html

stargatesq

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