[davismwfl]

If you are building a simple web app, do you really need to separate it into a different layer/call? Having a monolith isn't evil for simple apps, just have a library or function you call to get the data and populate it server side. My general rule is unless there are many separate types of clients (e.g. mobile app, web app, backend services etc) needing the same thing, then it can just be part of the primary application and returned server side. Lots of separate client based calls are not necessary for a basic app (but some frameworks kinda push you towards this). In fact, much of the time people would be better putting a caching layer in first and returning the data with the server render, at least initially until they have users and reasons to change.

Outside of that, yes, you can also just make it a route in the web app and call it if you really want, nothing says it has to conform to a specific standard. A simple HTTP get or post is good enough many times. GraphQL is also overkill if you simply need to run a basic query.

[palberg7]

Yes that's what I want to do. Although I don't need caching (yet?)

[davismwfl]

Yea, sorry, that was worded a little poorly. My point was just from a monolith you are smarter to add caching first before breaking it up anyway. So monolith will get you to point A on the map, adding caching will usually get your further to say point B, then finally you'll need to break the application apart to scale further. That was my point.

Nothing evil about a monolith when you are starting out. I'd argue it is the correct way to start out in fact.