Rails as the stack and REST as the implementation. You can then spend most of your time on making sure you have a good understanding of the domain and then des

Rails as the stack and REST as the implementation. You can then spend most of your time on making sure you have a good understanding of the domain and then design the API to match that understanding. Rails because you asked what _I_ would reach for :) Once you figure out your domain model you could just generate the REST API. Rails has GraphQL gems so you could go down that path in the future if desired. Like anything though, GraphQL isn't a silver bullet. If you have a complex data model, that can be exposed and people unfamiliar with the data model will see performance issues. When I hear API, I usually infer that it means other people will be calling it. The above answers are in context of that. If you really mean a back-end to your web app that nobody external will be calling, ever, then it really doesn't matter what tech stack or methodology you use. In that case, there are other factors like time to deliver and if there is a team building it, then it helps to use a common methodology (e.g. REST).