5 ms·

> I think that Django is basically DDD/CQRS/SOA Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's mo

• camgunz 4y ago
  > Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's monolithic nature). Django has "apps", which--while they do run in the same process--aren't intended to use code from each other. They're supposed to have their own models/views/templates/migrations/etc. They're effectively different services, as long as you don't think a service has to be available at a different network address to be a different service (think of mounting different apps or microservices behind different URLs, for example). Also, I wouldn't say Django is CQRS--CQRS is more or less a different phrasing of "JSON-RPC", which "REST" has become. > Last Django app i saw sure had a lot of this boilerplate going. I saw this talk and thought: well this is finally a "framework" that allowes me to do away with serialization (as in: in this framework the amount of extra work you do for making the app an SPA is fairly minimal): Eh, some people are highly allergic to any boilerplate, but like, the DRF example [0] has practically none. That Elm video is interesting, but I'm skeptical of anything whose central claim is "I can easily turn front end data requests into SQL and back again in very few lines of code". There's just a lot of inherent complexity there, and my evidence is every mainstream ORM, plus all the "backend-as-a-service" products that are multi-1000s LOC. Then again I think SQL is a great (legendary, honestly) language and we should stop trying to replace it. [0]: https://www.django-rest-framework.org/#example https://www.django-rest-framework.org/#example
  • cies 4y ago
    > I'm skeptical of anything whose central claim is "I can easily turn front end data requests into SQL and back again in very few lines of code". Same for me. The Elm video is showing off a toy, an interesting toy, but a toy. The presenter also says it's for now only useful for fun projects. Something with a more mature backend in the same direction would Hasura (a GraphQL and authorization layer over Postgres) with a generated-from-the GraphQL-spec client library. A generator for Elm exists (which give you strong type-safety over the API barrier). It does lead to a situation where SQL barely used. The GraphQL used to query the db is very SQL-like though :)
    • camgunz 4y ago
      I absolutely love Hasura. I basically never want to write a backend API again after using it. But yeah it is a GraphQL to SQL compiler (and yeah all the attributes are like "where", "aggregate", it obviously is SQL-in-GraphQL), which... yeah let's just use SQL everyone, come on.