I'll keep it high level. Approach everything in a way that anything can be replayed. If you keep the data/messages immutable and replay-able, concurrency becomes a lot less complicated.

@sdecandelario AWS can do everything - the learning curve can be a bit steep, and the setup hoops to jump through can be a little daunting if you're just doing a proof of concept. That's why I usually start on Digital Ocean and then migrate from there. IMO, AWS can't be beat as far as value.

I currently use AWS for work and Digital Ocean for side projects (I migrate them to AWS when they're at a certain traffic/user level). I used to be on Linode, but moved away from them after they had a series of security breaches and handled the disclosure of that in a very shady way. Service is good for all 3 listed.

This is an excellent answer. In general, ENUM should be avoided unless you know the ENUM values will never ever change. In that case, I would still recommend putting what you would have put in the ENUM in your code (instead of the DB). Code is usually cheaper and easier to change than modifying an existing table.

There are a lot of good microframeworks available for Python. I would start with one of those (Flask, Bottle, CherryPy being some of the more widely used ones). From there, it's pretty easy to get started with writing what you're looking for.

Generally, anything that accesses specific pieces of hardware. GPS via JS is not nearly as reliable as native. Same with B4LE, accelerometers, etc. etc. In some cases, there isn't a JS hook into it yet - or it's just not done well.

Short answer: Go with what you know the best... unless you're looking to learn something new. Then go with what you know the least. Another view: If you aren't using any advanced native features, then circle back to the short answer above and make your choice. If you are using advanced native features, then you should probably go native.