Project name (pREST) and support for other database types besides PostgreSQL

[avelino]

pREST was born with the need to open the Postgres database as a remaining API (in this issue #41 I explain better), with the evolution of the project came the opportunity to support other databases (ex MariaDB/MySQL #239), we modeled the pREST core to accept other database adapters.

Segnified (initial) from the prefix p in the name pREST?

p = Postgres

With support for other databases it no longer makes sense to tie the prefix with Postgres but to be an agnostic name for the database. After reflecting on a resignified p prefix I came up with the following idea - I will try to share it here.

p = Pure

Why Pure? Comes from Pure functions that has lots of properties that are important in functional programming, including referential transparency (you can replace a function call with its resulting value without changing the meaning of the program).

Does it make sense? Leave your comment, recommendation or constructive criticism

[cassiobotaro]

Pure may not be a good value because it would lead you to think that it is a clean implementation of rest, perhaps restful.

And a reminder, maybe the logo should also be modified.

[sebastianwebber]

we can replace pure by powerful or Passionate

other ideas here: https://chi-nese.com/list-of-positive-words-that-start-with-p/

[tiaguinho]

I agree with @cassiobotaro and @sebastianwebber.

Since the project work with databases, I think will make more sense to use the p as persistent.

[fabriziomello]

Hi folks,

For obvious reasons I'm totally skeptical about it and every time I see a multi-database tool sounds like a "one ring to rule them all", and in practice this kind of tool always lack of specific (and cool) database features because of the idea of standardization of API/UI/etc.

Although my skeptical opinion I'm not saying is a bad idea, because thinking from the user/developer perspective we can provide one RESTfull API to be a middle-ware between different database flavors and it's awesome, but anyway I can see some limitations:

• transactions: we can't enable transactions between different adapters... ok depending of the database implementation we can use 2PC (Two-phase Commit) but it's somehow hard to maintain and error prone

• endpoints: different databases have different ways to deal with schemas, so we'll need to think very well about GET /DATABASE/SCHEMA/TABLE

• query statements: can be hard to standardize due to differences of SQL syntax between databases. I know we have the ability to write our own SQL scripts but the idea of a RESTfull API is to avoid it, no?

My two cents!

[avelino]

I liked the @fabriziomello provocation, it made me think a lot about the future of pREST and which way it should go - that's why I took so long to answer.

I have a way of premising whether quality software and ensuring quality in software with multiple media is not a simple journey.
pREST will keep the name pREST focused on Postgres, in the future we will support extensions (it has to be developed, we don't have anything ready - not even draft), where we can have initiatives to support other relational databases (maybe NoSQL).