Add subZero

[ruslantalpa]

No description provided.

[dbohdan]

This is definitely an interesting project (by a developer I recognize from another awesome project :-)), but I am not sure if it belongs on this list. I am looking for things that are more server-y than framework-y. (My mistake to not state this explicitly from the start. I have since added a CONTRIBUTING file that outlines the requirements.)

I think the deciding criteria here should be whether the user 1) has to write any code that isn't declarative configuration to get started; 2) has to maintain the schema models manually. The README says:

✓ Out of the box GraphQL/REST endpoints created by reflection over a PostgreSQL schema

Does this apply to the initial code generation or is the mapping automatically maintained for the user?

[ruslantalpa]

this is a long discussion :)

General thoughts on the list:
You are looking to create a list of tools that deliver "automatic api" but there is no such thing, you need a "framework-y" thing :) in order to be able to create api's in this manner, you need a collection of tools working together to deliver complete apis capable of replacing the ones built in a traditional way. While tools like PostgREST are the "core tech" enabling this method of developing the server api, they are not the complete picture.

Technically speaking, subzero is a collection of tools/technologies (PostgREST is a important part) stringed together to deliver the end goal that is an GraphQL+REST API, a task that no tool on it's own can accomplish.

Since it's a "framework-y" thing, the github link is a kind of a "base project/starter kit" that puts everything together, but it's "server-y" in a sense that all the pieces run on the server, and it can be pointed to a database and generate an api.

But also note, thinking that you can just point tools like PostgREST/PostgraphQL to ANY database and you get an api ready to expose to the open web is a mistake. Some additional thought needs to go into things like constraints, roles and privileges.

This is also the reason why the starter kit is heavy on the SQL part, there needs to be an order/guide on how to create database schemas to be able to properly leverage tools like PostgREST

in the end, is subZero something that can generate an api based on a database schema? yes.
Is is ONE tool? No, it's OpenResty (with custom code) + PostgREST (with custom code) + PostgreSQL + pg-amqp-bridge + RabbitMQ.

An API is a complex problem and can't be solved with "here, download this executable and run it".
There will always be some amount of code to write to create a specific API, the question is just how much of it.

[ruslantalpa]

To answer the questions you asked specifically:

1. has to write any code that isn't declarative configuration to get started

• short: no, it can be pointed to a database and it will expose a REST/GraphQL api (generate is not the right word for these type of tools)
• long: while most of the functionality comes out of the box based on the database schema, the user needs to make sure that schema follows some "best practices" to safely expose it to the web (however this is the same for all tools in this list). Also some tasks (like sending emails) are accomplished by custom code written by the user so it's not "everything is automated and you only need to configure it"

2. has to maintain the schema models manually.

• no, there are no models (that mirror database objects), the database dictates the shape of the api. This is mostly "middleware" between HTTP and SQL world

[dbohdan]

While tools like PostgREST are the "core tech" enabling this method of developing the server api, they are not the complete picture.

But also note, thinking that you can just point tools like PostgREST/PostgraphQL to ANY database and you get an api ready to expose to the open web is a mistake. Some additional thought needs to go into things like constraints, roles and privileges.

I agree with this. If the list gives off the impression that you can simply fire up one of these tools and expose your database to the Internet with impunity, it is problem I need to fix. Maybe there should be a short introduction at the top telling the reader what basic pitfalls to avoid.

My goal is to catalog what you called the "core tech". You are supposed to put your own code in front of it and slice, dice, filter, or completely rewrite the incoming requests as necessary, but things that only do that fall outside the scope of the list. (I chose to limit the list's scope this way because otherwise it could easily turn into a broad and unfocused overview of REST- and GraphQL-related technology. Something like Zawinski's Law of Software Envelopment might apply here: "A document on a particular part of your stack attempts to expand until it covers your entire stack." Unfortunately, this would also mean that "Those documents which cannot so expand are replaced by ones which can." :-))

To answer the questions you asked specifically: [...]

Okay, to restate: subZero

• can function without the user maintaining any code for either models or routes;
• thanks to the GraphQL support adds value over plain PostgREST even for the user who doesn't want to use the framework-y parts.

Is this right? If so, it sounds good. (And calling it a "boilerplate" in the repository description does the project a disservice.)

[ruslantalpa]

• can function without the user maintaining any code for either models or routes;
  yes
• thanks to the GraphQL support adds value over plain PostgREST even for the user who doesn't want to use the framework-y parts.
  yes

In the last question you touched on the core value proposition, you get free REST (the work i open-sourced through PostgREST, there was no "reflection" before then and no "relations" ) and pay to have GraphQL over the exact same database schema, all the other "framework-y" stuff there is just to show that these types of apis can completely replace a traditional MVC stack.

I understand your concern/confusion with the the specific github project, i submitted this link (and not the main site) because all the other links were to github and thought that's what you are going for and also that this is the easiest way to get started with subZero (instead of downloading and installing each component separately).

Another way to put it is: This specific github project relates to subZero the same way https://github.com/subzerocloud/postgrest-starter-kit relates to PostgREST

[dbohdan]

Oh, looks like I misunderstood subZero's licensing. At first, the README for the starter kit and the "MIT/Commercial" license stated in the YAML file left me with the impression that subZero was open core, that is, that the basic functionality was open source and you paid for more on top of it, but it seems I was mistaken. SubZero does not have an open core.

[ruslantalpa]

It is open core, basic functionality is "REST" and the "more" part is GraphQL

[dbohdan]

basic functionality is "REST"

To be clear, I meant other parts than PostgREST itself. (Edit: Added missing "I".)

[dbohdan]

I see I misinterpreted what you said about the paid functionality. My bad, I was confused about the license for 'all the other "framework-y" stuff' there.

[dbohdan]

Well, this PR caused me a bit of a dilemma. Putting subZero on the main list would have been a departure from what was already on it, and perhaps a step towards scope creep. However, I wanted to mention subZero. That's when I also realized needed a coherent, simple policy on proprietary features. My solution follows. I hope you also find it satisfactory, but I would appreciate honest feedback if you didn't.

The best policy I have come up with is this: when considering a piece of software for inclusion, disregard the proprietary parts. It makes it easy to compare submitted open source and open core software with the perspective in mind of a potential user who prefers open source. From this perspective subZero and PostgREST Starter Kit look rather similar: they enhance PostgREST, but shouldn't have separate list entries from it. So where should they go?

To answer this question, I have created a Related projects wiki page and put a link to it in README.md. The wiki page will be for projects that either use those on the main list as a component (applications, etc.) or help you work with them (client libraries, frameworks, and so on). I've added a link to subZero and to the PostgREST Starter Kit there under "PostgREST". Please edit the link descriptions to improve them.

[dbohdan]

Thank you for a frank reply.

there is a difference between open source and free open source

I believe the common term for the former is "source available".

I see this quite a lot, developers expecting to get paid for their work but when it comes software/tools for them, they "prefer" free open source

This is an interesting topic.

My experience agrees with what you said in the quote. A person I often read complains about it, too. I don't think it's quite accurate to describe this as hypocrisy, though; it's more of a commons dilemma situation. People try to minimize their individual costs today, even if it may cost all of them more tomorrow. On top of that, they are afraid to be mislead into spending unnecessary money. On top of that, developers tend to underappreciate the value of their work (witness the perennial "I feel I don't deserve my [market average] compensation" post) and, by extension, of similar work by others.

Unfortunately, what it implies for someone curating a free educational resource for developers is that including non-FOSS is to his detriment. Readers would perceive such a resource as less trustworthy, and therefore lower-quality. Worse, if you included vendor A, but not vendor B, you would open yourself to suspicions of being a stooge for A. It makes focusing on only FOSS a better default, especially at the start when you have no established reputation. Of course, this is exactly what a smart stooge would do. :-)

Going back to the immediate matter at hand, I am not set against ever adding proprietary software. My plan is to decide at a later date off the PRs and discussions the list gets. If I change my policy, I'll make sure to let you know.

Merry Christmas! 🎄

Thanks! And to you, too.

[dbohdan]

Added in 9bab16e (per #20).