I'm thinking of simply creating express routes (I'm using Node.js) and using JSON but it seems cumbersome. Or is that a common practice?
I'm wondering what the alternatives to REST and GraphQL are.
Curious to know what y'all use for simple web apps.
It's a data-driven full-stack application programming system centered around graph-based UI and data management implemented in Clojure [4].
While React lets you be declarative about your UI, Fulcro lets you be declarative about your entire system - both backend and frontend.
Check out this discussion too: https://news.ycombinator.com/item?id=21743720
[1] https://fulcro.fulcrologic.com/ [2] https://github.com/wilkerlucio/pathom [3] https://github.com/edn-query-language/eql [4] https://clojure.org/
Otherwise, writing your own backend using RPC-named express routes is more than sufficient. The reason why REST became common is that RPC routes can become messy.
Another poster gave the example of "SaveWidget" as an RPC endpoint. This can cause problems for some teams that have no conventions and they end up with "SaveFoo" and "BarSave" endpoints. REST solves this somewhat by relying on HTTP verbs so both endpoints are normalised to "POST /foo" and "POST /bar".
Finally, if your web app is truely simple with only a couple of backend endpoints needed, then whatever you choose is generally fine. Structural and architectural patterns exist to provide a framework around managing complexity.
If your app is not complex, most people - and it's important to consider this includes your future self that has forgotten your implementation details - can grok the codebase without too much trouble. If anything, as your question suggest, over-engineering a simple app can lead to greater confusion.
These are a no-go. Why should I use a proprietary solution when there are superior free open source offerings? Sure it's more effort to spin up an aws ec2 instance but that's very well worth it. I then have full control over my database and I don't have to deal with proprietary sh*t.
> RPC-named express routes is more than sufficient
Yes RPC is exactly what I was looking for. It's super simple. I don't need all that REST and GraphQL stuff.
> REST solves
Honestly, I don't understand what REST solves.
> over-engineering a simple app can lead to greater confusion.
Yes simplicity is key.
> RPC-named express routes is more than sufficient
Actually for Node.js there is Wildcard API[1] which I discovered yesterday. It's even simpler than express routes.
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.
Nothing evil about a monolith when you are starting out. I'd argue it is the correct way to start out in fact.
I could try think of why but in practice, it just seems to work out the best. Are there reasons? Sure. But coming up with a detailed rationale would take some days of thinking. It just works very well.
This means on my service side I expose SaveWidget(id, body) ReadWidget(id) PatchWidget(id, changes) QueryForWidgetsByFoo(foo) QueryForWidgetsByFooBarAndSomeOtherSTuff(foo, bar, otherstuff) and on the client side I just call them as if they were local (but rather slow performing) functions.
Lots of little ifs and buts but this has proven the superior approach in all scenarios where I control both client and server. I might go for REST for wide-audience APIs just for the recognizability.
For Node.js there is https://github.com/reframejs/wildcard-api
You can also post form data instead of json if you think json is overkill but getting data from the server is probably limited to something like json unless you want to decide on a custom format or your data is truly so simple that you can just return a single text blob.
What is the benefit of doing that? RPC seems much "better" than REST.
Look at any mature framework (Django, Laravel) and either use that or emulate it.
Why?
REST and GraphQL deal with discrete resources. yes, GraphQL can deal with many, but it's still an abstraction to group calls.
In my experience, I'm dealing with user input that does not map cleanly to resources. Ultimately, if you persist things, of course resources are affected. But the input is its own world.
The sign REST/GraphQL abstractions are breaking is when you create ad-hoc endpoints/entry-points to serve these resources.
Classic example would be a call to "copy 5 widgets from Y category to Z category".
In resource-oriented world, you could do:
1. PUT/POST for each widget, changing the category label sending the full resource.
2. Or you could write an ad-hoc endpoint that accepts more than 1 widget, repeat as above.
3. You still need to figure out the "proper" way to handle the category. If Z doesn't exist, do you make them PUT/POST to /categories/ to create one first? Or do you auto create it for them? How do you auto create it? Does the category field accept the primary key of a category and arbitrary text in case you're creating a new one? That's odd.
4. So on and so forth.
How would I do it in Django world, at least?
1. Create a view, it will have 2 forms on the view and process them together.
2. Form 1 is a formset with a row per widget you wan to copy. Any number of rows can be sent. Django will validate they are valid widgets.
3. Form 2 is a form with a "from_category" and a "to_category" as well as a "new_category_name".
4. Form 2 has a validation rule, if to_category is null, new_category_name must have a label for a new category.
5. In the view, process Form 1 and 2 together, if valid, handle a create everything.
The difference is subtle. But you're decoupling input from resources. I yearn for an API-centric way to do this.
Yes, it's common practice. As for being cumbersome, as cumbersome as creating conforming ReST or GraphQL endpoints? Keep it simple I'd say.