3 ms·

There's definitely potential to go too far into monolith territory and misinterpret how simple your architecture actually is. An example: Django backed by Post

There's definitely potential to go too far into monolith territory and misinterpret how simple your architecture actually is. An example: Django backed by Postgres. I tend to view this as 1 architectural unit, i.e. Postgres is wholly embedded in Django. I am under no illusion that I have both a Django project and a PostgreSQL instance. I have a Django-backed-by-Postgres. I can have that PostgreSQL instance be a standalone interface, but that means increasing my architectural units from 1 to 2. Instead, if I want to integrate with Django's raw tables, I'm going to do it on Django's terms (via a custom HTTP API) rather than fighting the ORM over who gets to DBA the database. Bad for performance? No doubt. We'll worry about that when we get there. Yes, you can run a web app server directly out of Postgres without an additional "app layer" like Django (Crunchy has some cool tools for this). But should you? To be clear, I'm a big fan of KISS, just skeptical of false minimalism.

KwisaksHaderach 5y ago
What's the crunchy tool for this?
- craigkerstiens 5y ago
  I believe they're referring to some tools like pg_tileserv which gives you a turnkey tile server on top of PostGIS. As it stands today we don't have anything to automatically run that app from Postgres itself (but stay tuned we might be launching something around that in just a few weeks). Tileserv is in an interesting category like many other turn key APIs or services (like PostgREST or Postgraphile) on top of a database, but I don't view them as different than say running a Django app for example.
  - SahAssar 5y ago
    I haven't django'd much, but to me a postgrest interface is very much different than having a bespoke app. With postgrest I can think of my app as interfacing with sql over a http translation layer, and things like authorization, data models, etc. are actually in the database. I'm sure bespoke apps can be written to be as predictable and "database-like" as I found postgrest, but I haven't seen any.
justin_oaks 5y ago
Agreed. This quote seems relevant: "Everything should be made as simple as possible, but not simpler." The article talks about using rate limiting using Redis and dropping it in favor of handling it on each server node and assuming uniform distribution of requests. Doing that is a trade-off of precision rate-limiting for a simpler architecture. That may be a good trade-off, but only if you can get away with it. If they were required to have more precise rate-limiting then the simpler architecture would not have been possible. In my own work, I used Memcached instead of Redis for rate limiting data. The applications were coded to fall back to the per-node rate limiting if Memcached weren't reachable. Memcached may have been another dependency, but it was one of the less troublesome dependencies. I never experienced a problem with it in production. The fallback behavior meant that we didn't even need Memcached in a dev environment. I guess my point is this: Not all dependencies are as troublesome as others.

KwisaksHaderach 5y ago

What's the crunchy tool for this?

craigkerstiens 5y ago
I believe they're referring to some tools like pg_tileserv which gives you a turnkey tile server on top of PostGIS. As it stands today we don't have anything to automatically run that app from Postgres itself (but stay tuned we might be launching something around that in just a few weeks). Tileserv is in an interesting category like many other turn key APIs or services (like PostgREST or Postgraphile) on top of a database, but I don't view them as different than say running a Django app for example.
- SahAssar 5y ago
  I haven't django'd much, but to me a postgrest interface is very much different than having a bespoke app. With postgrest I can think of my app as interfacing with sql over a http translation layer, and things like authorization, data models, etc. are actually in the database. I'm sure bespoke apps can be written to be as predictable and "database-like" as I found postgrest, but I haven't seen any.

justin_oaks 5y ago

Agreed. This quote seems relevant: "Everything should be made as simple as possible, but not simpler." The article talks about using rate limiting using Redis and dropping it in favor of handling it on each server node and assuming uniform distribution of requests. Doing that is a trade-off of precision rate-limiting for a simpler architecture. That may be a good trade-off, but only if you can get away with it. If they were required to have more precise rate-limiting then the simpler architecture would not have been possible. In my own work, I used Memcached instead of Redis for rate limiting data. The applications were coded to fall back to the per-node rate limiting if Memcached weren't reachable. Memcached may have been another dependency, but it was one of the less troublesome dependencies. I never experienced a problem with it in production. The fallback behavior meant that we didn't even need Memcached in a dev environment. I guess my point is this: Not all dependencies are as troublesome as others.