rafal.siepak   It's hard to troubleshoot without more information. But if I had to guess, the logs would probably look something like this.

Processing by CategoriesController#index as */*
  Parameters: {"query"=>"something"}
No template found for CategoriesController#index, rendering head :no_content

If that is the case, then the code for the format.json will not get picked up. You should update your URL in the view where you're passing in the URL into the stimulus controller with the json format. Something like this should work. 

'select-url-value': categories_url(format: :json)

By doing that, it should then respond with the proper format.

Processing by CategoriesController#index as JSON

On your ingress of receiving messages, you'd need to have something that parses their text and call on a different function. Having some sort of AI here could help improve the results, but that's definitely a beyond the scope of this content. 

In this particular case, you could change

case body.upcase.strip

to something like

case
  when body.upcase.strip.include?('MENU')

so, each switch in the case statement would need to have the conditional check.

With libraries like fullcalendar, I think importmaps often gets in the way more than it actually helps. The problem with fullcalendar, even once you get past this error, is that it internally references main.css which will then lead to the error

Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/css". 
Strict MIME type checking is enforced for module scripts per HTML spec.

If your project requires something like FullCalendar or any JS library that includes and references CSS files, it may be better to use esbuild via jsbundling-rails

Regardless, if you want to experiment with this, you can pin fullcalendar with something like

bin/importmap pin @fullcalendar/core

If you're going the route of AWS, App Runner or Elastic Beanstalk may be considerations. There are episodes on both of those. If you do go the route of Beanstalk, set up your own database instead of provisioning one through the Beanstalk wizard. This will provide some separation of Beanstalk and your database if you ever decide to switch to something like App Runner, ECS or EKS.

For Digital Ocean, I am not comfortable enough with their App Platform yet. The last time I tried it, there were several issues around my project using esbuild instead of webpacker and couldn't successfully deploy. I've been monitoring their release notes page and haven't seen anything to indicate that this issue is fixed. 

It also greatly depends on your application needs. Do you need to have multiple regions and load balancing between multiple web services? 

You can go that route for sure. Personally, I don't like the off chances that an answer could be updated for a different question by accident (if someone is changing the form values via inspect elements).