ruslan_talpa

you don't expose your tables directly, you expose a schema that consists only of views and stored procedures. If you really need a totally different version then you jsut exppose a new schema but more often it's the same situation as in graphql ecosystem, you jsut add a new column/view/procedure and don't delete the old one. Postgrest has the same power to describe what you want as a graphql api woudl have (by using it's select parameter)

That was the surprise part behind my other (downvoted) comment, surprised that it still comes up on homepage with direct links (as oposed to some new development around it)

Yeah i know, didn’t know ho to exactly express the feeling (nice surprise)

It’s not marketing (100% sure :). Do you have some info on it’s usage in production?

This is a solved problem https://github.com/subzerocloud/postgrest-starter-kit

It’just the tools you linked didnt prioritize the development workflow from the point of view od a backend developer (code in files, git, tests, migrations) but from the frontend developer perspective (ui to create tables)

Nothing wrong with it, it’s just weird to me seing a link directly to the homepage of a product that’s been around for 5 years now, and not something like “how to do x with postgrest”. Don’t get me wrong, it’s a good thing, just a little weird (in a good way) to me

Have you just discovered this and posted to HN? :)

I am not sure i get the idea, can you be more specific? + do you know ML :)?

The idea looks researched a bit. Send me over email the database table definitions an we can take it from there. One thing i suggest to donfirst is to spin up a wordpress and use that as an admin interface for your fruends to fill in the data, then we’ll only need to import it and create an api over it.

What’s the project about?

It was meant in the style of "Setup and .. NginX/Redis/PostgreSQL", it assumed the reader knows about PostgREST (that's why the link is to a landing page and not to the homepage). subzero.cloud is BaaS (GraphQL & Rest api for your database).

Your comment is valid though, not everybody knows about PostgREST (but you should check it out :) http://postgrest.org/)

* only simple CRUD apps - I've implemented with this type of stack a service similar to Parse/Firebase. I've also designed/implemented something like Basecamp+Freshbooks (in traditional PHP style, not a toy/demo app) and i know this type of stack can power just fine services like that (with a lot less code), i.e. your statement "simple CRUD apps" is not true

* monitoring - easily implemented in the proxy (can be as simple as $request_time in logs)

* multiple databases (I take it you mean read replicas) - tie each process (very lightweight process ... something like 5Mb memory) like this one to a particular db replica than use roundrobin in nginx upstream. So, to go from one db to multiple one you just need a different production config, no new code.

* use views/stored procedures to expose as an api then change your underlying tables (data storage format) to your hearts desire.

* Integrate 3rd ... - You are thinking/comparing tools like this to languages/stacks like php/node/ruby when infact you should compare them to things like active record. In traditional stack you don't integrate 3rd party at the same level as active record (in active record code), you do it either above or below this level. It's the same here only above means client code or (scriptable) proxy level (see openresty and njs) and below means database level (PostgreSQL is much more then SELECT ) or some worker process that reacts to system events that can be as simple as a events table or as complex as message broker.

SELECT * FROM reset_user_password() works in sql too

How is it different/better then apgdiff?

Can you share what tool was the final choice and what were the quirks that influenced your decision?

This is nothing like postgrest :) In postgrest the query is mostly determined by the the user calling the API, in SQLer the query is hardcoded by the api developer, the user just supplies the parameters to the query.

permissions are not a problem, you can specify exactly down to a cell what permissions a user has (read/write/delete). The problem is D.O.S., One can write a query that takes down any database without having access to any tables/data.

Slightly related question about chinese products and their quality. I am planning on buying (from china) a flatbed food printer based on epson print head. Is it a good idea? It’s about 2k.

Anyone know a us/eu manufacturer that makes/sells them (i would prefer spending 1k more in return for product quality)

> I haven't seen a single backend framework which doesn't actively encourage an N+1 problem on any query which returns multiple objects of data

Well then you haven't really looked :)

https://join-monster.readthedocs.io/en/latest/

https://github.com/graphile/postgraphile

https://www.prisma.io/

https://subzero.cloud/

These are all examples of tools/libs that implement a graphql api without a N+1 issue

The comparison is quite unfair. Elm manages a system of 1k nodes accessed by one user while sql manages a system of 1m records accessed by 1k users (i am counting browsers) soo... yeah, leaky. You never ever have to optimize anything in sql when you have tables with 1k rows. It’s the scale of things that forces you to optimize.

in relation to your concerns about PostgREST check out these links http://docs.subzero.cloud/postgrest-starter-kit/ http://docs.subzero.cloud/architecture-and-project-structure...

is it a legacy db? can you give more details as to in what domain you have hundreds of tables? with postgraphile, are you exposing your tables directly or did you create a special "api" schema with only views and functions that is exposed as an api?

as for your migrations problems, a combination of sqitch and apgdiff provides a way to work with sql similar to other languages (migration files are created automatically and managed by sqitch)

It’s miserable when your starting point is the default js implementation for the executor, but if you write your own executor you have a lot of freedom to do cool stuff.

I’ve built a graphql interface here https://subzero.cloud on top of the powerful rest interface of https://postgrest.com which in turn sits on top of postgresql.

The end result is you define your tables/views/functions in sql and on the other end you get rest+graphql api to your data

translate from REST to SQL is exactly what PostgREST is doing and you get the same flexibility as with graphql

Usually people say the opposite, logic in db does not scale, though i don't know what scale are they talking about when modern databases (PostgreSQL/MySQL), on a single decent box can handle 1M+ TPS (and that is before using replicas to scale reads).

As to your comment, nothing is black and white, but if the logic operates strictly on the data (not interfacing with 3rd party systems), having it in the db imo is better/less complex.

When you say "logic" in your database, that usually means views/triggers/functions. I don't see why you can not version them, keep them in git and treat as any other code. Yes there are edge cases where there are some interdependencies, or that it's harder to "replace" functions when the signature changes, but if you are just a bit careful, and try to keep your views/functions (logic) a bit separate from tables (state), then in most cases you can just replace them, sort fo like copying a new version of a file.

I would say that the tooling is lacking in this area but there is no big underlying obstacle that would prevent you from working with code in the database the same as with code in other envs. For PostgreSQL in particular, a combination of Sqitch and Apgdiff works quite nicely. I've combined them for a particular project structure (https://github.com/subzerocloud/subzero-cli) but this approach can be generalised. I have all my database code (including table definitions) in separate files/folders, split however i want (modules), work on them in any oder i need, when the time comes to deploy, apgdiff does the diffing between live and dev versions of the database, creates the new migrations DDLs automatically, and than those migration files are managed by sqitch and deployed.

Authorization is explained in the docs (done by PostgreSQL). All the bits together here https://github.com/subzerocloud/postgrest-starter-kit

Allowing at will joins is dangerous. It seems you are trying to replicate the functionality of PostgREST

I am [1] [2]. Infrastructure for subscriptions is 90% there (RabbitMQ + webstomp plugin)

1. https://subzero.cloud/

2. https://github.com/subzerocloud/subzero-starter-kit

(edit formatting)

is the list only for FOSS?