3 ms·

What was the handwaving "send it to the JS frontend"? Are you suggesting you allow the client-side JS app to call directly against the Postgres DB or is there

by zbuc 15y ago

What was the handwaving "send it to the JS frontend"? Are you suggesting you allow the client-side JS app to call directly against the Postgres DB or is there another approach you had in mind?

einhverfr 15y ago
I don't see how that differs from allowing a thick client written in wxPerl from directly connecting to the database. It seems quite useful in many cases. One thing to keep in mind about PostgreSQL is you can do a lot of traditional middleware tasks (including message queues) in the database back-end with transactional control. These can even be hooked into other applications Remember, you can put a lot of what would otherwise go in a middleware layer in the database itself, especially with features in PostgreSQL like LISTEN/NOTIFY. There are some limitations of this approach, but in general, I have found it ideal, but it requires thinking about your database differently. Instead of a data store on the bottom of the stack, you have an intelligent data storage and queuing system in the center of your environment.
- cbsmith 15y ago
  One of the interesting changes in our reality, is the case for increasing scalability by having a middleware layer that does all the work has become quite weak. It's much cleaner to partition your systems and work that way.
  - einhverfr 15y ago
    I don't think it's just that the performance case for middleware has become weak. It's also that traditionally you pay per connection some sort of license fee. So if you are running Oracle or SQL Server, and you want to add additional clients that, say, do additional process on notification, that means additional license fees. This isn't a problem on PostgreSQL. It means there are choices between the traditional ones of putting everything in the database or in the middleware.
y0ghur7_xxx 15y ago
Are you suggesting you allow the client-side JS app to call directly against the Postgres DB or is there another approach you had in mind? Almost directly. The JS frontend calls something like mod_libpq¹, or a very simple node.js "proxy". Something that just gets incoming http requests, executes stored procedures and sends back the response. A reverse proxy between the JS client and Postgres. That proxy can be very generic and reused between applications. All logic would live in the db. ¹http://asmith.id.au/mod_libpq.html http://asmith.id.au/mod_libpq.html

by zbuc 15y ago

What was the handwaving "send it to the JS frontend"? Are you suggesting you allow the client-side JS app to call directly against the Postgres DB or is there another approach you had in mind?

einhverfr 15y ago

I don't see how that differs from allowing a thick client written in wxPerl from directly connecting to the database. It seems quite useful in many cases. One thing to keep in mind about PostgreSQL is you can do a lot of traditional middleware tasks (including message queues) in the database back-end with transactional control. These can even be hooked into other applications Remember, you can put a lot of what would otherwise go in a middleware layer in the database itself, especially with features in PostgreSQL like LISTEN/NOTIFY. There are some limitations of this approach, but in general, I have found it ideal, but it requires thinking about your database differently. Instead of a data store on the bottom of the stack, you have an intelligent data storage and queuing system in the center of your environment.

cbsmith 15y ago
One of the interesting changes in our reality, is the case for increasing scalability by having a middleware layer that does all the work has become quite weak. It's much cleaner to partition your systems and work that way.
- einhverfr 15y ago
  I don't think it's just that the performance case for middleware has become weak. It's also that traditionally you pay per connection some sort of license fee. So if you are running Oracle or SQL Server, and you want to add additional clients that, say, do additional process on notification, that means additional license fees. This isn't a problem on PostgreSQL. It means there are choices between the traditional ones of putting everything in the database or in the middleware.

y0ghur7_xxx 15y ago

Are you suggesting you allow the client-side JS app to call directly against the Postgres DB or is there another approach you had in mind? Almost directly. The JS frontend calls something like mod_libpq¹, or a very simple node.js "proxy". Something that just gets incoming http requests, executes stored procedures and sends back the response. A reverse proxy between the JS client and Postgres. That proxy can be very generic and reused between applications. All logic would live in the db. ¹http://asmith.id.au/mod_libpq.html http://asmith.id.au/mod_libpq.html