4 ms·

I personally wouldn't start a new, greenfield web API project with an MVC framework. There are still too many choices present in how to handle concerns like que

I personally wouldn't start a new, greenfield web API project with an MVC framework. There are still too many choices present in how to handle concerns like querying, authn, authz, caching, migrations, etc, etc. I would use a system like PostgREST or Hasura and generate the API from the database directly. Business logic can be handled on the control plane with replication/subscriptions/whatever mechanism. Small, stateful services that react to the event stream and perform whatever actions needed based on your business policies: send notifications, insert new records, call external partner APIs, etc. For server-rendered UI I think there's still a strong case for these frameworks but they could probably take some lessons and generate their data-layer models from the database DDL, push business logic down to the control plane, and focus on rendering current state from read-only models/streams. I've been meaning to try something like this in Haskell (I've written some foundational libraries to enable this on Postgres [0]) but there are frameworks that do this like Phoenix in Elixir. [0]: https://hackage.haskell.org/package/postgresql-replicant-0.1.0.1 https://hackage.haskell.org/package/postgresql-replicant-0.1...

sparker72678 4y ago
Or you could just use Rails and actually ship a product within the first year of work.
- agentultra 4y ago
  Whatever floats your boat. I can stand up a REST API server with PostgREST and a database in a couple of hours. I can deploy new models with a SQL migration. Like I said, if you want to do server-side rendering it's still a place where Rails/Django/etc shine but I think they could learn a thing or two there to make them better. They could improve so that folks can write/maintain even less code.
DeathArrow 4y ago
>I personally wouldn't start a new, greenfield web API project with an MVC framework. There are still too many choices present in how to handle concerns like querying, authn, authz, caching, migrations, etc, etc. I would use a system like PostgREST or Hasura and generate the API from the database directly. It depends on the framework. In .NET the only difference between MVC and API is the base class of the controller. You either return JSON or you return a view. Database connections, migrations, routing, serialization, error handling, exception handling, authentication, authorization, Swagger specification, Docker file generation, can be handled by the framework if you so desire. Also, you can mix MVC controllers and API controllers in the same project if you so desire. >For server-rendered UI I think there's still a strong case for these frameworks but they could probably take some lessons and generate their data-layer models from the database DDL I find it better to just generate the database from the domain entities using code first approach. It's faster and the ORM will generate proper indexes and also provide optimized SQL queries.

sparker72678 4y ago

Or you could just use Rails and actually ship a product within the first year of work.

agentultra 4y ago
Whatever floats your boat. I can stand up a REST API server with PostgREST and a database in a couple of hours. I can deploy new models with a SQL migration. Like I said, if you want to do server-side rendering it's still a place where Rails/Django/etc shine but I think they could learn a thing or two there to make them better. They could improve so that folks can write/maintain even less code.

DeathArrow 4y ago

>I personally wouldn't start a new, greenfield web API project with an MVC framework. There are still too many choices present in how to handle concerns like querying, authn, authz, caching, migrations, etc, etc. I would use a system like PostgREST or Hasura and generate the API from the database directly. It depends on the framework. In .NET the only difference between MVC and API is the base class of the controller. You either return JSON or you return a view. Database connections, migrations, routing, serialization, error handling, exception handling, authentication, authorization, Swagger specification, Docker file generation, can be handled by the framework if you so desire. Also, you can mix MVC controllers and API controllers in the same project if you so desire. >For server-rendered UI I think there's still a strong case for these frameworks but they could probably take some lessons and generate their data-layer models from the database DDL I find it better to just generate the database from the domain entities using code first approach. It's faster and the ORM will generate proper indexes and also provide optimized SQL queries.