Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure

hasura.io

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure

#61

Post by 0x777 »

ruslan_talpa wrote: post #56
tango12 wrote: post #54

Earlier quoted context omitted.

Hey there! Thanks for your comment. Well actually we do infer directly from the Postgres schema. Only for users not familiar with Postgres directly, we recommend going through the UI so that not only is the table created, but the Data API is also asked to track it and provide an API for it. There is other metadata that we do need the user to specify, via the UI or the API, and that's for stuff like permissions and re…

about metadata: in Postgrest - you tell it which schema to expose and that means that anything inside it needs "tracking" and exposing, want it exposed, put it in that schema. Relations between entities ... that can be queried from the database itself, no need to ask the user for it. timing out - it works up to a point, if you for example set a hard limit to 1s then to an attacker it just means he needs to do a few p…

I'm one of the engineers who work on the data service

> about metadata: in Postgrest ..

We don't want to restrict the data service to a particular schema. You can add a table from any schema to be tracked, say information_schema or pg_catalog. In fact, that is how introspection works (you can look at the queries made by the console). This means that the schema cache in memory would be quite large because of the number of tables in information_schema/pg_catalog if we were to auto load all these. There is also the issue that you may not want to expose some tables. We can definitely have a console button which will let you import all the tables in public schema.

Sure, you can infer relationships from the foreign key constraints. But, how would you come up with names that do not conflict with the existing columns? What if you add a new column with the same name as an inferred relationship? With the data service, you can also define relationships on/to views across schemas (1). Making metadata explicit goes with one of our core principles, 'no magic'.

> what postgrest does for protection: a - no fancy joins,

explicit joins are not allowed even with our data service. The joins that happen are the implicit ones because of the relationships. We do the same thing if we need any custom joins/aggregations. Define a view and expose it.

> b - you can't do anything other than selecting columns and relationships with the api.

> c - the permission layer can be used to prevent these to some extent (like not allowing an anonymous user to filter on a particular column).

1. https://hasura.io/_docs/platform/0.6/getting-started/5-data-...

Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure

#62

Post by ruslan_talpa »

0x777 wrote: post #61
ruslan_talpa wrote: post #56

Earlier quoted context omitted.

about metadata: in Postgrest - you tell it which schema to expose and that means that anything inside it needs "tracking" and exposing, want it exposed, put it in that schema. Relations between entities ... that can be queried from the database itself, no need to ask the user for it. timing out - it works up to a point, if you for example set a hard limit to 1s then to an attacker it just means he needs to do a few p…

I'm one of the engineers who work on the data service > about metadata: in Postgrest .. We don't want to restrict the data service to a particular schema. You can add a table from any schema to be tracked, say information_schema or pg_catalog. In fact, that is how introspection works (you can look at the queries made by the console). This means that the schema cache in memory would be quite large because of the numbe…

all the things i explained about metadata are implemented in postgrest and they work, and there is no loss of flexibility sinceyou can expose any table you want from any schema by explicitly creating a "mirror" view in the exposed schema. and relations are detected across tables and views and there is a way to deal with collisions. I am not saying that your way is bad (having a metadata file), just saying there is a way to automatically create it.

- b,c that's good that you don't expose the entire SQL

Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure

#63

Post by ruslan_talpa »

0x777 wrote: post #61
ruslan_talpa wrote: post #56

Earlier quoted context omitted.

about metadata: in Postgrest - you tell it which schema to expose and that means that anything inside it needs "tracking" and exposing, want it exposed, put it in that schema. Relations between entities ... that can be queried from the database itself, no need to ask the user for it. timing out - it works up to a point, if you for example set a hard limit to 1s then to an attacker it just means he needs to do a few p…

I'm one of the engineers who work on the data service > about metadata: in Postgrest .. We don't want to restrict the data service to a particular schema. You can add a table from any schema to be tracked, say information_schema or pg_catalog. In fact, that is how introspection works (you can look at the queries made by the console). This means that the schema cache in memory would be quite large because of the numbe…

anyway, good luck with your product. As i mentioned, it's the only thing out there close to the concept of postgrest, and that's a good thing :)

Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure

#64

Post by 0x777 »

ruslan_talpa wrote: post #57
ruslan_talpa wrote: post #56

Earlier quoted context omitted.

about metadata: in Postgrest - you tell it which schema to expose and that means that anything inside it needs "tracking" and exposing, want it exposed, put it in that schema. Relations between entities ... that can be queried from the database itself, no need to ask the user for it. timing out - it works up to a point, if you for example set a hard limit to 1s then to an attacker it just means he needs to do a few p…

and also permission, between views/stored procedures/roles/grants/rls postgresql has all the features needed to implement any ACL needed.

> and also permission, between

True. That would also mean creating a database user for every application user. The auth service needs to attach more metadata to the users and since postgres does not allow you to reference system catalogs, the two user systems have to be kept in sync. We were not quite certain how this idea of mapping users would pan out when we started building the auth service.

Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure

#65

Post by 0x777 »

ruslan_talpa wrote: post #62
0x777 wrote: post #61

Earlier quoted context omitted.

I'm one of the engineers who work on the data service > about metadata: in Postgrest .. We don't want to restrict the data service to a particular schema. You can add a table from any schema to be tracked, say information_schema or pg_catalog. In fact, that is how introspection works (you can look at the queries made by the console). This means that the schema cache in memory would be quite large because of the numbe…

all the things i explained about metadata are implemented in postgrest and they work, and there is no loss of flexibility sinceyou can expose any table you want from any schema by explicitly creating a "mirror" view in the exposed schema. and relations are detected across tables and views and there is a way to deal with collisions. I am not saying that your way is bad (having a metadata file), just saying there is a…

I guess we'll need to have 'auto generate relationships' tooling. Just curious, how do you infer the relationships between a table and a view?

Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure

#66

Post by 0x777 »

ruslan_talpa wrote: post #63
0x777 wrote: post #61

Earlier quoted context omitted.

I'm one of the engineers who work on the data service > about metadata: in Postgrest .. We don't want to restrict the data service to a particular schema. You can add a table from any schema to be tracked, say information_schema or pg_catalog. In fact, that is how introspection works (you can look at the queries made by the console). This means that the schema cache in memory would be quite large because of the numbe…

anyway, good luck with your product. As i mentioned, it's the only thing out there close to the concept of postgrest, and that's a good thing :)

Thanks ! If I remember correctly, postgrest was started about the same time we started work on the data service. In fact, both these projects were pushing the limits of the then hasql library with the whole dynamic query generation.

Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure

#67

Post by ruslan_talpa »

ruslan_talpa wrote: post #62
0x777 wrote: post #61

Earlier quoted context omitted.

I'm one of the engineers who work on the data service > about metadata: in Postgrest .. We don't want to restrict the data service to a particular schema. You can add a table from any schema to be tracked, say information_schema or pg_catalog. In fact, that is how introspection works (you can look at the queries made by the console). This means that the schema cache in memory would be quite large because of the numbe…

all the things i explained about metadata are implemented in postgrest and they work, and there is no loss of flexibility sinceyou can expose any table you want from any schema by explicitly creating a "mirror" view in the exposed schema. and relations are detected across tables and views and there is a way to deal with collisions. I am not saying that your way is bad (having a metadata file), just saying there is a…

can't reply to your question so doing it here. the code is OS so you can look it up :) the idea is this - detect table relations based on FK - for each view check where each column comes from (view column usage) based on the info above you know all the relations in the system, even view to view

also there is a way to do it in a single query but that is not yet implemented in postgrest

Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure

#68

Post by 0x777 »

webmaven wrote: post #58
ecthiender wrote: post #2

We built Hasura over the last few years to help us build products fast. We didn't know what it would look like when we started, but we've ended up with something like a Parse + Heroku but on your own infra so that you can mess around with the internals when required. Key features: 1. Data APIs on a Postgres database 2. Deploy with git-push, or any docker image 3. Expose HTTP services on the API gateway over subdomain…

Nice, and you've really polished that onboarding experience. Smooth and no head-scratching moments. One minor nit: It is quite nice that you provide links to jump to the right place for each step, but I would suggest adding images of the equivalent spot to click in the UI. So, what's the registration code?

> Nice, and you've really polished that onboarding experience.

Thanks ! Alas, Tanmai (our CTO) will quote this at us for the foreseeable future, this being his idea.

> So, what's the registration code?

This is just something that is used with the startups and incubators we partner with. You can ignore this.

Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure

#69

Post by 0x777 »

ruslan_talpa wrote: post #67
ruslan_talpa wrote: post #62

Earlier quoted context omitted.

all the things i explained about metadata are implemented in postgrest and they work, and there is no loss of flexibility sinceyou can expose any table you want from any schema by explicitly creating a "mirror" view in the exposed schema. and relations are detected across tables and views and there is a way to deal with collisions. I am not saying that your way is bad (having a metadata file), just saying there is a…

can't reply to your question so doing it here. the code is OS so you can look it up :) the idea is this - detect table relations based on FK - for each view check where each column comes from (view column usage) based on the info above you know all the relations in the system, even view to view also there is a way to do it in a single query but that is not yet implemented in postgrest

While we can get the information on the columns used in a view, we can't infer if the uniqueness properties propagate to the view which guarantee the semantics of relationships.

I guess it might be convenient to do this (determine relationships across views), but the users should be aware of the guarantees offered in this scenario.

Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure

#70

Post by ruslan_talpa »

0x777 wrote: post #69
ruslan_talpa wrote: post #67

Earlier quoted context omitted.

can't reply to your question so doing it here. the code is OS so you can look it up :) the idea is this - detect table relations based on FK - for each view check where each column comes from (view column usage) based on the info above you know all the relations in the system, even view to view also there is a way to do it in a single query but that is not yet implemented in postgrest

While we can get the information on the columns used in a view, we can't infer if the uniqueness properties propagate to the view which guarantee the semantics of relationships. I guess it might be convenient to do this (determine relationships across views), but the users should be aware of the guarantees offered in this scenario.

I am not sure i understand what you are saying about guarantees. If there is a FK, there is a relation. It's the user that is driving the relations by specifying what columns are FK, it's the same thing as defining relations in a GUI, only you do it at the database level
Post reply on HN